Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gpg.fail

gpg.fail

Post reply on HN
Print view View original

211–220 of 376 posts

Re: Gpg.fail

#211

Post by palata »

computerfriend wrote: post #170
palata wrote: post #135

Earlier quoted context omitted.

> It survives only because nerds have a parasocial relationship with it. I really would like to replace PGP with the "better" tool, but: * Using my Yubikey for signing (e.g. for git) has a better UX with PGP instead of SSH * I have to use PGP to sign packages I send to Maven Maybe I am a nerd emotionally attached to PGP, but after a year signing with SSH, I went back to PGP and it was so much better...

> better UX with PGP instead of SSH This might be true of comparing GPG to SSH-via-PIV, but there's a better way with far superior UX: derive an SSH key from a FIDO2 slot on the YubiKey.

I do it with FIDO2. It's inconvenient when having multiple Yubikeys (I always end up adding the entry manually with ssh-agent), and I have to touch the Yubikey everytime it signs. That makes it very annoying when rebasing a few tens of commits, for instance.

With GPG it just works.

Re: Gpg.fail

#212

Post by sph »

ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

The vast majority of open-source software is written by people whose day job is building empires on top other open-source software, at zero cost and without releasing modifications, which is harder to do with the GPL.

Re: Gpg.fail

#213

Post by palata »

some_furry wrote: post #99
johnisgood wrote: post #91

Earlier quoted context omitted.

Now can you give us a list of all the features of PGP and a tool that does one specific thing really well?

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

> The only downside to Sigstore is it hasn’t been widely adopted yet.

Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. I can't replace PGP with Sigstore when publishing to Maven. It's nice to tell me I'm dumb because I use PGP, but really it's not my choice.

> Use SSH Signatures, not PGP signatures.

Here I guess it's just me being dumb on my own. Using SSH signatures with my Yubikeys (FIDO2) is very inconvenient. Using PGP signatures with my Yubikeys literally just works.

> Encrypted Email: Don’t encrypt email.

I like this one, I keep seeing it. Sounds like Apple's developer support: if I need to do something and ask for help, the answer is often: "Don't do it. We suggest you only use the stuff that just works and be happy about it".

Sometimes I have to use emails, and cryptographers say "in that case just send everything in plaintext because eventually some of your emails will be sent in plaintext anyway". Isn't it like saying "no need to use Signal, eventually the phone of one of your contacts will be compromised anyway"?

Re: Gpg.fail

#214

Post by upofadown »

josephg wrote: post #202
tptacek wrote: post #89

Earlier quoted context omitted.

Everything is better than PGP (not just GPG --- all PGP implementations). The problem with PGP is that it's a Swiss Army Knife. It does too many things. The scissors on a Swiss Army Knife are useful in a pinch if you don't have real scissors, but tailors use real scissors. Whatever it is you're trying to do with encryption, you should use the real tool designed for that task. Different tasks want altogether different…

The thing I can't get past with PGP / GPG is that it tries to work around MITM attacks by encouraging users to place their social network on the public record (via public key attestation). This is so insane to me. The whole point of using cryptography is to keep private information private. Its hard to think of ways PGP could fail more as a security / privacy tool.

Do you mean keyservers? Keyservers have nothing to do with the identity verification required to prevent MITM attacks. There is only one method available for PGP. Comparison of key fingerprints/IDs.

Keyservers are simply a convenient way to get a public key (identity). Most people don't have to use them.

Re: Gpg.fail

#215

Post by upofadown »

amluto wrote: post #159
johnisgood wrote: post #108

Earlier quoted context omitted.

No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.

> you have to supply people's public key each time Keyrings are awful. I want to supply people’s public keys each time. I have never, in my entire time using cryptography, wanted my tool to guess or infer what key to verify with. (Heck, JOSE has a long history of bugs because it infers the key type , which is also a mistake.) I have an actual commercial use case that receives messages (which are, awkwardly, files sen…

>And it wants to identify keys by 32-bit truncated hashes.

That's 64 bits these days.

>I should really not have to even think about the interaction between decryption and verification.

Messaging involves two verifications. One to insure that you are sending the message to who you think you are sending the message. The other to insure that you know who you received a message from. That is an inherent problem. Yes, you can use a shared key for this but then you end up doing both verifications manually.

Re: Gpg.fail

#216

Post by p2detar »

tptacek wrote: post #79
p2detar wrote: post #68

Earlier quoted context omitted.

> Encrypting email > Don't. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#en... I’m not sure I completely agree here. For private use, this seems fine. However, this isn’t how email encryption is typically implemented in an enterprise environment. It’s usually handled at the mail gateway rather than on a per-user basis. Enterprises also ensure that the receiving side supports email encryption as well. edi…

Your mail either needs to be encrypted reliably against real adversaries or it doesn't. A private emailing circle doesn't change that. If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies, I'll just say I ran just such a private circle at Matasano, where we used encrypted mail to communicate about security assessment projec…

> Your mail either needs to be encrypted reliably against real adversaries or it doesn't.

It is, GPG take care of that.

> If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies

That’s not what I’m talking about. It’s an enterprise - you cannot send non-encrypted emails from your work mail account, the gateway takes care of it. It has many rules, including such based on the sender and recipient.

Surely, someone can print the mail and carry it out of the company’s premises, but at this point it’s intentional and the cat’s already out of the bag.

Re: Gpg.fail

#217

Post by tomhow »

bfkwlfkjf wrote: post #183
MobiusHorizons wrote: post #182

Earlier quoted context omitted.

Seems like the users are voting with their feet, right? Maybe respect the users wishes and stop preaching what users should be wanting?

[flagged]

Hey, this is a completely unacceptable comment on HN. Please read the guidelines and make an effort to observe them if you want to participate here. We have to ban accounts that do this repeatedly. https://news.ycombinator.com/newsguidelines.html

Re: Gpg.fail

#218

Post by upofadown »

Valodim wrote: post #193

For anyone relatedly wondering about the "schism", i.e. GnuPG abandoning the OpenPGP standard and doing their own self-governed thing, I found this email particularly insightful on the matter: https://lists.gnupg.org/pipermail/gnupg-devel/2025-September... > As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and…

Here is my take on the OpenPGP standards schism:

* https://articles.59.ca/doku.php?id=pgpfan:schism

Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war.

>Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG.

Traditionally the OpenPGP process has been based on minimalism and rejected everything without a strong justification. RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard. It contains a lot of poorly justified stuff and some straight up pointless stuff. So just supporting RFC-9580 is not the answer here. It would require significant cleaning up. But again, just supporting LibrePGP is not the answer either. The process has failed yet again and we need to recognize that.

Re: Gpg.fail

#219

Post by mkesper »

amluto wrote: post #159
johnisgood wrote: post #108

Earlier quoted context omitted.

No, because there is no keyring and you have to supply people's public key each time. It is not suitable for large-scale public key management (with unknown recipients), and it does not support automatic discovery, trust management. Age does NOT SUPPORT signing at all either.

> you have to supply people's public key each time Keyrings are awful. I want to supply people’s public keys each time. I have never, in my entire time using cryptography, wanted my tool to guess or infer what key to verify with. (Heck, JOSE has a long history of bugs because it infers the key type , which is also a mistake.) I have an actual commercial use case that receives messages (which are, awkwardly, files sen…

Some years ago I wrote "just a little script" to handle encrypting password-store secrets for multiple recipients. It got quite ugly and much more verbose than planned, switching gpg output parsing to Python for sanity. I think I used a combination of --keyring --no-default-keyring. Never would encourage anyone to do this again.

Re: Gpg.fail

#220

Post by user3939382 »

If mass use of GPG benefited Microsoft, Amazon, Google and all the other assholes it would be polished, slick, and part of 9th grade curriculum. They call it “Face ID” that’s the Orwellian shit that makes money so that’s what we get instead. These things take resources, don’t blame the projects.
Post reply on HN