this post was submitted on 20 Aug 2024
523 points (99.4% liked)

Technology

58115 readers
3920 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. 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
[–] [email protected] 7 points 4 weeks ago* (last edited 4 weeks ago) (2 children)

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.

[–] [email protected] 2 points 4 weeks ago (1 children)

The email plugins for various clients make it easy to mistakenly think you’re sending an encrypted email.

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

[–] [email protected] 1 points 3 weeks ago

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.

[–] [email protected] 1 points 3 weeks ago* (last edited 3 weeks ago)

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/