this post was submitted on 20 Aug 2024
523 points (99.4% liked)
Technology
59653 readers
2807 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, they still can't underfund gnu privacy guard :-) It's pretty much already finished product and working pretty well.
Eh? I tried it about a year ago, and I found all the same clunky problems that were there 20 years ago.
Thunderbird + kleopatra? K-9 + OpenKeyChain ( android )? Where did you have issues?
I went through an exercise with a few other developers to see if we could use it for transferring sensitive information. I was using Windows w/WSL2 at the time (now I'm full Linux for my work machine), and I believe the other two were on Macs.
Our conclusions were that while it might be useful alongside other ways, it was too clunky to use in general. One of the more useful things we could do is have developers sign git commits.
The email plugins for various clients make it easy to mistakenly think you're sending an encrypted email. When even technical people are making this mistake, then it's a big issue for widespread adoption. The plugins also don't always send it in a format that works for every client out there. We found the most consistent way was to encrypt the message in a file and attach it to the email.
The plugins don't work with modern webmail, anyway.
Public key servers are unreliable. They're largely maintained by volunteers, so this is understandable, but we couldn't recommend that the company use them. If we wanted reliability, we'd need to run our own internal keysever.
Then there's the key signing meetings we'd need to have. Even technical people find these a bother. These are, unfortunately, inherent to the web of trust model.
I really wanted to make it work. The decentralized nature of the web of trust--as opposed to the hierarchical model of TLS--is appealing to me personally. But this shit hasn't gotten better in 20 years, and at least some of it is unfixable.
Ok. Now I know what's the issue but this is not the problem with gpg. Nah, gpg integration with thunderbird is so flawless that it clearly says when it's encrypting when not. Also you can see the raw email content and then you see whether it's plaintext or ciphertext. I'm using thunderbird with gpg very often so I know how it works nicely with gpg
It's a problem with the gpg ecosystem. No matter what code is actually responsible, it prevents us from using it in practice. We're not going to switch our whole email system and clients just for this.
We implemented this at work using Hashicorp Vault for PKIs and a dovecote smtp server to pass IMAP from whatever client our endusers were using. The only problem was clients using the O365 webportal in unsupported or outdated browsers, but we took care of that with SCCM.
https://developer.hashicorp.com/vault/tutorials/secrets-management/pki-engine
https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
https://doc.dovecot.org/configuration_manual/forwarding_parameters/