Jesus Michał "Le Sigh" 🏔 (he)Oct 4, 2025

Let's be honest. I've been a strong supporter of #OpenPGP (or #PGP in general) for a long time. And I still can't think of any real alternative that exists right now. And I kept believing it's not "that hard" — but it doesn't seem like it's getting any easier. The big problem with standards like that are tools.

#WebOfTrust is hard, and impractical for a lot of people. It doesn't really help how many tools implement trust. I mean, I sometimes receive encrypted mail via #EvolutionMail — and Evolution makes it really hard for me to reply encrypted without permanently trusting the sender!

The whole SKS keyserver mess doesn't help PGP at all. Nowadays finding someone's key is often hard. If you're lucky, WKD will work. If you're not, you're up for searching a bunch of keyservers, GitHub, or perhaps random websites. And it definitely doesn't help that some of these may hold expired keys, with people uploading their new key only to a subset of them or forgetting to do it.

On top of that, we have interoperability issues. Definitely doesn't speak well when GnuPG can't import keys from popular keyservers over lack of UIDs. And that's just the tip of the iceberg.

Now with diverging OpenPGP standards around the corner, we're a step ahead from true interoperability problems. Just imagine convincing someone to use OpenPGP, only to tell them afterwards that they've used non-portable tool / settings, and their key doesn't work for you.

That's really not how you advocate for #encryption.

Show threadDavid Sardari
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
963069 – OpenPGP v5 (LibrePGP) and OpenPGP v6 (RFC 9580) formats are incompatible, GLEP63 should mention and handle this

Oct 5, 2025 at 2:02pmWeb
Show threadsamOct 6, 2025

@duxsco @mgorny It's all public and in the GLEP you filed a bug to amend ;)

Signing commits, signing stages, signing Manifests in rsync mirrors. We also have some machinery on the infra side using OpenPGP to control access to machines (devboxes).

Show threadDavid SardariOct 6, 2025
@thesamesam @mgorny thx for the clarification :) I'd like to see the use of OpenPGP for SSH connections, because the [A] subkey is bound to an identity and more likely to be stored on the Nitrokey. I doubt Gentoo devs getting two Nitrokeys for the purpose of managing OpenPGP on one and SSH on the other.
Show threadsamOct 6, 2025
@duxsco @mgorny I think a bunch of developers use SSH keys via OpenPGP (myself included) but it's indeed not mandatory.
Show threadJesus Michał "Le Sigh" 🏔 (he)Oct 6, 2025
@thesamesam @duxsco, but also enabling encrypted mail when desirable.
Show threadDavid SardariOct 6, 2025

@mgorny @thesamesam

but also enabling encrypted mail when desirable.

yeah, I bet encrypted mail exchange is more common amongst Gentoo developers due to, for example, discussions on CVEs. For others, the exchange of, for example, app-crypt/age public keys via OpenPGP signed mails would be an option on those "rare" occations.

Show threadWiktor KwapisiewiczOct 6, 2025

In that case, users are free to choose the tool of their choice for Git commit signing.

Technically, they already can via the gpg.program (notabene it’s funny how Git calls everything related to signatures “gpg”, even internally the header for signatures is called gpgsig and in the SHA-256 extension they decided to call it… gpgsig-sha256 :) ).

hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool.

Currently the switching logic is based on armor header, which differs between OpenPGP, X.509 and SSH. Switching on v5/v6 would be far more complex (it'd require de-base64'ing and checking packet versions). Seems quite unlikely that'd be the path chosen, but I don’t have any insights on git development (besides checking it and writing gpg-compatible alternative: https://codeberg.org/openpgp-card/oct-git).

I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use.

Sadly it seems the conflict has deep roots in some long unresolved social matters and I don’t see it improving even in the long-term. 😢

I’ve personally migrated to signing commits with SSH (with TPM-backed keys, https://github.com/wiktor-k/ssh-signing/) and like the allowed signers format but I understand you’ve got different constraints.

oct-git

A simple tool for Git signing and verification with a focus on OpenPGP cards

Codeberg.org