Malte Meiboom
5cf7357230
Previously when Husk encountered an email which it could not encrypt, because it couldn’t get an authenticated certificate for the recipient, it let the email pass without modifications. This was especially true for emails with several recipients – if just one of them was without a certificate, the email was not encrypted. With milestone 5, Husk now deals with the above situation. In that case, the email processing is split into two flows, producing a encrypted mail for all recipients with an authenticated certificate and sending the mail unencrypted for those recipients who don’t. The email headers are modified accordingly to avoid email loops and a footer is added so that a recipient still knows who else got this email. This milestone also includes fixing of minor bugs and code improvements, to mention a few: - Introducers where listed for each authentication path, now this list is deduplicated. - Detect ANSI control characters in User ID as they can be used for malicious proposes.
53 lines
2.8 KiB
Markdown
53 lines
2.8 KiB
Markdown
# Husk
|
||
|
||
Husk is a pass-through solution for automatic OpenPGP encryption.
|
||
|
||
Husk is an email filter (milter) for MTAs which encrypts emails while they pass through it. It facilitates Web-of-Trust technologies to use decentralized and federated certificate authorities as sources for authenticated OpenPGP certificates. It aims to reduce the amount of administrative effort of obtaining and keeping them up to date by establishing narrow, focused trust delegations. Husk can be used to encrypt emails for services which cannot encrypt on their own – like notification systems or issue trackers, or being used at the end of transport to implement zero-access encryption (for email at rest).
|
||
|
||
Husk is written in Rust and uses Sequoia PGP for encryption and certificate handling.
|
||
|
||
## Status
|
||
|
||
Milestone 5 is reached and Husk gains some new features:
|
||
|
||
Previously when Husk encountered an email which it could not encrypt, because it couldn’t get an authenticated certificate for the recipient, it let the email pass without modifications. This was especially true for emails with several recipients – if just one of them was without a certificate, the email was not encrypted.
|
||
|
||
With milestone 5, Husk now deals with the above situation. In that case, the email processing is split into two flows, producing a encrypted mail for all recipients with an authenticated certificate and sending the mail unencrypted for those recipients who don’t. The email headers are modified accordingly to avoid email loops and a footer is added so that a recipient still knows who else got this email.
|
||
|
||
This milestone also includes fixing of minor bugs and code improvements, to mention a few:
|
||
|
||
- Introducers where listed for each authentication path, now this list is deduplicated.
|
||
- Detect ANSI control characters in User ID as they can be used for malicious proposes.
|
||
|
||
|
||
Please refer to the [documentation](https://www.husk-project.org/documentation) for a full list of all
|
||
features and their usage.
|
||
|
||
## Documentation
|
||
|
||
The documentation (with install instructions) can be found [here](https://www.husk-project.org/documentation).
|
||
|
||
## Website
|
||
|
||
This project has a [website](https://www.husk-project.org/) with more background
|
||
information.
|
||
|
||
## Funding
|
||
|
||
This project is funded through the [NGI0 Commons Fund](https://nlnet.nl/core), a fund established by [NLnet](https://nlnet.nl/).
|
||
|
||
<table>
|
||
<tr>
|
||
<td>
|
||
<img src="https://nlnet.nl/logo/banner.svg" style="max-width: 250px;width: 75%" alt="NLnet">
|
||
</td>
|
||
<td>
|
||
<img src="https://nlnet.nl/image/logos/NGI0Core_tag.svg" style="max-width: 250px;width: 75%" alt="NLnet">
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
|
||
## License
|
||
|
||
Husk is licensed under AGPL 3.0 - for details read the included `license.txt` file or find it [online](https://www.gnu.org/licenses/agpl-3.0.html).
|