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

151–160 of 376 posts

Re: Gpg.fail

#151

Post by loop22 »

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…

I think that's a feature not a bug for upstream projects encouraging these rewrites.

Re: Gpg.fail

#152

Post by johnisgood »

akerl_ wrote: post #145
johnisgood wrote: post #132

Earlier quoted context omitted.

Yeah, well, I wish I could convince people to use 2-4 different tools when one does it "just fine".

I thought the whole unix philosophy was to have a bunch of tools that each do one thing well, and to compose them into the workflow you want.

And I thought most projects would be licensed as GNU by now but alas.

Re: Gpg.fail

#153

Post by johnisgood »

akerl_ wrote: post #144
jhgb wrote: post #143

Earlier quoted context omitted.

Nobody decided that it's a crime, and it's unlikely to happen. Question is, what do you do with mandatory snooping of centralized proprietary services that renders them functionally useless aside from "just live with it". I was hoping for actual advice rather than a snarky non-response, yet here we are.

I gave you the answer that exists: I'm not aware of any existing or likely-to-exist secure messaging solution that would be a viable recommendation. The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick…

> messaging security

> WhatsApp

Eh?

There are alternatives, try Ricochet (Refresh) or Cwtch.

Re: Gpg.fail

#154

Post by anonym29 »

akerl_ wrote: post #136
jhgb wrote: post #134

Earlier quoted context omitted.

> Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger. That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.

There's no future-proof suggestion that's immune to the government declaring it a crime. If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.

Could you please link the source code for the WhatsApp client, so that we can see the cryptographic keys aren't being stored and later uploaded to Meta's servers, completely defeating the entire point of Signal's E2EE implementation and ratchet protocol?

Re: Gpg.fail

#155

Post by sorz »

Lots of issues follow the pattern "ANSI escape code inside untrusted text". It feels like XSS but for terminal.

Re: Gpg.fail

#156

Post by brians »

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…

No. You can always take the MIT-licensed source. And GnuPG got used through a CLI “API” anyway.

Re: Gpg.fail

#157

Post by rockskon »

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…

Well then the software needs to have its bugs fixed if it wants to have a chance at longer term survival.

Re: Gpg.fail

#158

Post by rendaw »

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…

How would MIT make anyone lose control of it?

Re: Gpg.fail

#159

Post by amluto »

johnisgood wrote: post #108
some_furry wrote: post #102

Earlier quoted context omitted.

> I need an alternative to "gpg --encrypt --armor --recipient " That's literally age. https://github.com/FiloSottile/age

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 sent over various FTP-like protocols, sigh), decrypts and verifies them, and further processes them. This is fully automated and runs as a service. For horrible legacy reasons, the files are in PGP format. I know the public key with which they are signed (provisioned out of band) and I have the private key for decryption (again, provisioned out of band).

This would be approximately two lines of code using any sane crypto library [0], but there really isn’t an amazing GnuPG alternative that’s compatible enough.

But GnuPG has keyrings, and it really wants to use them and to find them in some home directory. And it wants to identify keys by 32-bit truncated hashes. And it wants to use Web of Trust. And it wants to support a zillion awful formats from the nineties using wildly insecure C code. All of this is actively counterproductive. Even ignoring potential implementation bugs, I have far more code to deal with key rings than actual gpg invocation for useful crypto.

[0] I should really not have to even think about the interaction between decryption and verification. Authenticated decryption should be one operation, or possibly two. But if it’s two, it’s one operation to decapsulate a session key and a second operation to perform authenticated decryption using that key.

Re: Gpg.fail

#160

Post by amluto »

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…

GnuPG should be extended (incrementally rewritten into something much better and turned into a library) and the original GnuPG should be extinguished.
Post reply on HN