[gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

Hi,

As you may have read (and probably forgotten about it), OpenPGP has
diverged into two incompatible standards a while ago [1]. 
Unfortunately, it doesn't seem that time is going to heal wounds here,
and today we're still in this mess.  On top of that, it has been
recently pointed out [2] that GLEP 63 wording of "v4 or later" can
confuse people into believing we permit both incompatible v5 and v6
versions.  While we could just have changed that into "v4 only", it
seems more appropriate to discuss the wider issue.

Long story short, there are two standards now: LibrePGP [3], which is
pretty much the final version of Werner Koch's RFC4880bis, and RFC9580
[4].  They are both based on the old RFC4880 [5], which corresponds to
the v4 message format.  However, while RFC4880bis defined a v5 message
format, RFC9580 rejected it and defined a v6 format instead.

As you may have guessed, GnuPG is obstinately rejecting RFC9580.  Other
projects are split between either implementing RFC9580, or both.  There
is a FreePG patchset [6] that is used by a bunch of major distros to
improve GnuPG compatibility, but that's hardly a solution (we are
apparently considering adding it a separate package [7]).  At this
point, I don't think there's any production-ready, portable alternative
to GnuPG for us -- particularly with Sequoia being limited by Rust's
limited platform support.

What I think makes sense right now is to update GLEP 63 to require
RFC4880 compliant keys, with some explicitly permitted extensions (like
curve 25519 support).  However, I don't really consider myself an expert
here, and I still think we need a more general idea of how to go forward
from here.

[1] https://lwn.net/Articles/953797/
[2] https://bugs.gentoo.org/963069
[3] https://librepgp.org/
[4] https://www.rfc-editor.org/rfc/rfc9580.html
[5] https://www.rfc-editor.org/rfc/rfc4880.html
[6] https://freepg.org/
[7] https://bugs.gentoo.org/950668

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[James Cloos]

your conclusion is well reasoned.

as a user, +1.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]


On Sat, Oct  4, 2025, at 22:19 CDT, Michał Górny <mgorny@gentoo.org> wrote:

> Hi,
>
> As you may have read (and probably forgotten about it), OpenPGP has
> diverged into two incompatible standards a while ago [1]. 

> [...]

Yeah, this is a mess.

We could also ditch the whole PGP thing and simply use ssh keys for
signing [1, 2, 3].

Best,
Matthias


[1] git has support for this, and this can even be combined with an openssh CA infrastructure: .git/config:

    [user]
      signingkey = /home/tamiko/.ssh/signing_key.pub
    [gpg]
      format = ssh
    [gpg "ssh"]
      allowedSignersFile = /home/tamiko/.ssh/allowed_signers

    resulting in:

    commit ee33182848ea2f229fb7da53c3a241b62aaa8b06
    Good "git" signature for tamiko@43-1.org with ED25519-SK-CERT key SHA256:s0kUASVHakMZykRbyXBKYY8KKm7E3WIRGT94YXTRHTc
    Author: Matthias Maier <tamiko@43-1.org>
    Date: Fri Oct 3 22:13:18 2025 +0000

[2] We are already mainting quite an elaborate setup for ssh and pgp keys - we could simply reduce it to only ssh keys.

[3] No, this is not really a serious suggestion :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 269 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]

On 10/5/25 2:01 AM, Matthias Maier wrote:
> 
> On Sat, Oct  4, 2025, at 22:19 CDT, Michał Górny <mgorny@gentoo.org> wrote:
> 
>> Hi,
>>
>> As you may have read (and probably forgotten about it), OpenPGP has
>> diverged into two incompatible standards a while ago [1]. 
> 
>> [...]
> 
> Yeah, this is a mess.
> 
> We could also ditch the whole PGP thing and simply use ssh keys for
> signing [1, 2, 3].

> 
> [2] We are already mainting quite an elaborate setup for ssh and pgp keys - we could simply reduce it to only ssh keys.



> [3] No, this is not really a serious suggestion :-)


Thanks for acknowledging that, though I wonder what the point of
mentioning it at all, was. :)

Also, re footnote 2, it very much does not simplify things, quite the
opposite. Just saying. ;)



-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Hoël Bézier]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Am So, Okt 05, 2025 am 02:21:05 -0400 schrieb Eli Schwartz:
>On 10/5/25 2:01 AM, Matthias Maier wrote:
>>
>> On Sat, Oct  4, 2025, at 22:19 CDT, Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> Hi,
>>>
>>> As you may have read (and probably forgotten about it), OpenPGP has
>>> diverged into two incompatible standards a while ago [1].
>>
>>> [...]
>>
>> Yeah, this is a mess.
>>
>> We could also ditch the whole PGP thing and simply use ssh keys for
>> signing [1, 2, 3].
>
>>
>> [2] We are already mainting quite an elaborate setup for ssh and pgp keys - we could simply reduce it to only ssh keys.
>
>
>
>> [3] No, this is not really a serious suggestion :-)
>
>
>Thanks for acknowledging that, though I wonder what the point of
>mentioning it at all, was. :)
>
>Also, re footnote 2, it very much does not simplify things, quite the
>opposite. Just saying. ;)

I thought this would indeed be feasible and that it would simplify things. I 
must be missing some informations. Could anyone expand on why using ssh for 
signing is not possible for us?

Hoël

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1787 bytes --]

On 10/5/25 2:48 AM, Hoël Bézier wrote:

> I thought this would indeed be feasible and that it would simplify
> things. I must be missing some informations. Could anyone expand on why
> using ssh for signing is not possible for us?



But I didn't say it's "not possible", I said it is the opposite of a
"simplification". A sufficiently determined person with infinite time
and development budget can be expected to generally produce anything not
contra-indicated by the laws of physics; doesn't mean it is a good idea.

...

Simplifying the cryptographic packeting format for private materials is
entirely unrelated to either the presence *OR* lack of presence of
simplicity or complexity in tooling consuming this.

So really, the first and biggest issue was "making assumptions".

Aside for that, actual CA deployments are significantly more complex
than implied. Gentoo has a CA infrastructure for developer PGP keys in
the form of

Gentoo Authority Key L1 <openpgp-auth+l1@gentoo.org>
Gentoo Authority Key L2 for Developers <openpgp-auth+l2-dev@gentoo.org>
Gentoo Authority Key L2 for Services <openpgp-auth+l2-srv@gentoo.org>

What is the *specific* proposal to replace this? I can think of some
potential answers, but I suspect most people have not thought about it
at all. And still, you need to manually track keys, but cannot because
"keyrings" are one of the things every PGP "replacement" decides to do
without. So better build even more infra for that.

There are other issues as well, once you've gotten that far. But of
course nobody does :) it is all memeing about "openpgp is terrible, what
if we just make an extremely simple replacement" with raw crypto
algorithms" and not too much real problem-solving.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]


This kind of branches out into three questions. 

1) What types of keys and standards to we require for Gentoo package
management and infrastructure (i.e. GLEP 63).

> What I think makes sense right now is to update GLEP 63 to require
> RFC4880 compliant keys, with some explicitly permitted extensions (like
> curve 25519 support). 

This makes sense here. The current v4 is not "badly broken" in any way that
I know of at the moment. So let's stick to it as much as possible for now
and allow some minimal functional extensions, which are ideally compatible
with all the software out there.

2) What software do we need / want to package in the Gentoo repo?

Obviously something that handles 1). Beyond that, we *want* to have as
much coverage as possible. I'm very reluctant to suggest patching GnuPG
with a custom patchset made by ourselves in Gentoo.

That said... According to the FreePG website, their patchset is by now
already used in GnuPG by (in order of impact)
 * Fedora
 * Debian & Ubuntu
 * Arch
 * NixOS

So, an obvious approach would be to start talking to these maintainers and
asking how they handle things. And if they have the hours and know-how
for a detailed review.
Once all (yes above list plus us would be close to that) Linux distros use
a patchset it's effectively a fork.

3) What else can we do to fix the mess?

Apply some not-so-subtle pressure to people to find a compromise. Not sure
how yet. Technical issues can be fixed. Egos not so much.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Sam James]

Eli Schwartz <eschwartz@gentoo.org> writes:

> On 10/5/25 2:48 AM, Hoël Bézier wrote:
> [...]
>
> What is the *specific* proposal to replace this? I can think of some
> potential answers, but I suspect most people have not thought about it
> at all. And still, you need to manually track keys, but cannot because
> "keyrings" are one of the things every PGP "replacement" decides to do
> without. So better build even more infra for that.

Yes. I only want to hear "SSH signing" mentioned alongside a proposal
which handles these issues.

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Sam James]

"Andreas K. Huettel" <dilfridge@gentoo.org> writes:

> This kind of branches out into three questions. 
>
> 1) What types of keys and standards to we require for Gentoo package
> management and infrastructure (i.e. GLEP 63).
>
>> What I think makes sense right now is to update GLEP 63 to require
>> RFC4880 compliant keys, with some explicitly permitted extensions (like
>> curve 25519 support). 
>
> This makes sense here. The current v4 is not "badly broken" in any way that
> I know of at the moment. So let's stick to it as much as possible for now
> and allow some minimal functional extensions, which are ideally compatible
> with all the software out there.

This is the natural thing we should do to avoid making the problem
worse, agreed.

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[David Sardari]

[-- Attachment #1.1: Type: text/plain, Size: 526 bytes --]

For completeness' sake, I want to mention that there is also x509 ([1]) for commit signing.
In contrast to SSH, CA management tools are more likely to be found.
I can't endorse any of the signature formats, because I don't know all the requirements of the Gentoo project ([2]).

[1] https://git-scm.com/docs/gitformat-signature.html
[2] https://fedifreu.de/@duxsco/115321926170890562

-- 
Info on my OpenPGP public key:
https://codeberg.org/duxsco/

My accounts:
https://keyoxide.org/noreply.keyoxide@duxsco.de


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 244 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

On Sun, Oct  5, 2025, at 01:21 CDT, Eli Schwartz <eschwartz@gentoo.org> wrote:

> Thanks for acknowledging that, though I wonder what the point of
> mentioning it at all, was. :)

Because sometimes it's good to acknowledge that there is an opportunity
cost in our choices (in this case a technically better / cleaner
solution compared to gnupg exists). But in our case we have a reasonably
well functioning solution already in place - so the benefits absolutely
do not outweigh the costs. So a pragmatic response to mgorny's e-mail is
to simply make "whatever gnupg as packaged in Gentoo" does the technical
requirement. If things deteriorate we have to reconsider [1].



> Also, re footnote 2, it very much does not simplify things, quite the
> opposite. Just saying. ;)

I don't quite agree with this statement - but I also think discussing it
is a moot point.

But I want to point out - as was already mentioned in this thread - git
already supports pgp, ssh, and x509 based signatures.

So considering our Gentoo infrastructure (with ldap, key management, our
custom gitolite and signature verification [2]), the fact that we are using
pgp signatures is really a minor detail. 



On Sun, Oct  5, 2025, at 08:47 CDT, Sam James <sam@gentoo.org> wrote:

> Yes. I only want to hear "SSH signing" mentioned alongside a proposal
> which handles these issues.

I apologize that I upset you with my mentioning of "SSH signing".

We could simply takes our current procedure as codified in various
proposals and replace the signing parts by a generic (and unspecified)
signing procedure. This would give you "signing agility" so to speak
without changing any of our procedures.

But I suggest we look into this when and if the need arises.

Currently, gnupg is functioning just fine - *heck* I can even sign this
e-mail with it [3].

Best,
Matthias

[1] To a degree gnupg without patches is already incompatible with
    alternative implementations following the other standard, so this
    isn't a pure hypothetical.

[2] We, in particular, do not use a "web of trust" with gnupg, but
    rather simple password based authentication when it comes to key 
    management.

[3] After removing the token2, resinserting the yubikey and stopping
the pcscd daemon *grrr* ...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 269 bytes --]

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Sam James]

Matthias Maier <tamiko@gentoo.org> writes:

> On Sun, Oct  5, 2025, at 01:21 CDT, Eli Schwartz <eschwartz@gentoo.org> wrote:
>
>> Thanks for acknowledging that, though I wonder what the point of
>> mentioning it at all, was. :)
>
> Because sometimes it's good to acknowledge that there is an opportunity
> cost in our choices (in this case a technically better / cleaner
> solution compared to gnupg exists). But in our case we have a reasonably
> well functioning solution already in place - so the benefits absolutely
> do not outweigh the costs. So a pragmatic response to mgorny's e-mail is
> to simply make "whatever gnupg as packaged in Gentoo" does the technical
> requirement. If things deteriorate we have to reconsider [1].

Yes, that is true.

>
>
>
>> Also, re footnote 2, it very much does not simplify things, quite the
>> opposite. Just saying. ;)
>
> I don't quite agree with this statement - but I also think discussing it
> is a moot point.
>
> But I want to point out - as was already mentioned in this thread - git
> already supports pgp, ssh, and x509 based signatures.
>
> So considering our Gentoo infrastructure (with ldap, key management, our
> custom gitolite and signature verification [2]), the fact that we are using
> pgp signatures is really a minor detail. 
>
>
>
> On Sun, Oct  5, 2025, at 08:47 CDT, Sam James <sam@gentoo.org> wrote:
>
>> Yes. I only want to hear "SSH signing" mentioned alongside a proposal
>> which handles these issues.
>
> I apologize that I upset you with my mentioning of "SSH signing".

;)

It's just that it's the obvious retort. What I'm interested in hearing
is how can emulate our existing setup with alternatives, or adjust it in
hopefully small ways that would fit w/ ssh.

(For example, I am not sure how well - if at all - the CA infra works
for SSH.)

>
> We could simply takes our current procedure as codified in various
> proposals and replace the signing parts by a generic (and unspecified)
> signing procedure. This would give you "signing agility" so to speak
> without changing any of our procedures.
>
> But I suggest we look into this when and if the need arises.
>
> Currently, gnupg is functioning just fine - *heck* I can even sign this
> e-mail with it [3].
>
> Best,
> Matthias
>
> [1] To a degree gnupg without patches is already incompatible with
>     alternative implementations following the other standard, so this
>     isn't a pure hypothetical.
>
> [2] We, in particular, do not use a "web of trust" with gnupg, but
>     rather simple password based authentication when it comes to key 
>     management.
>

But we do use a web of trust, we have the L[n] keys and we make use of
that for e.g. signing developer keys (as well as for infra managing
access to devboxes). That could be replaced by LDAP at least for the
latter part though, not so much for the former AFAIK (not sure if 'ssh
keyrings' exist in some exportable forat).

> [3] After removing the token2, resinserting the yubikey and stopping
> the pcscd daemon *grrr* ...

Re: [gentoo-dev] The OpenPGP mess, interoperability and Gentoo

[Matthias Maier]

> [...]

> (For example, I am not sure how well - if at all - the CA infra works
> for SSH.)

> But we do use a web of trust, we have the L[n] keys and we make use of
> that for e.g. signing developer keys (as well as for infra managing
> access to devboxes). That could be replaced by LDAP at least for the
> latter part though, not so much for the former AFAIK (not sure if 'ssh
> keyrings' exist in some exportable forat).


There is no concept of keyrings for ssh, so we would have to come up
with a distribution channel for developer keys (but I mean, a long file
listing all valid ssh keys isn't much different from a key chain...).


An intriguing alternative would be certificates [1].


So let's say you have a developer pubkey id_developer.pub and a gentoo
infrastructure key id_gentoo_ca.pub then you can issue a certificate for
the developer with something like:

    ssh-keygen -s id_gentoo_ca \
      -I key_id -z serial_number -V validity_interval -n principal \
      id_developer.pub
        
Here,

 - key_id and serial_number allow you to use a naming scheme (and
   serial number) of your choosing to distinguish certificates

 - validity_interval allows you to restrict the validity of the
   certificate
   
 - and the "principal" should be the username "developer@gentoo.org".

 - Furthermore, the -O flag allows you to add a number of ssh-specific,
   but also arbitrary options into the certificate. This could be used
   to selectively allowing (or disallowing) certain actions (such as
   signing a git commit, or pushing to the server).


The developer now ends up with the following triplet of a pubkey:

  id_developer
  id_developer.pub
  id_developer-cert.pub

and openssh uses the certificate transparently when connecting to a
server or (when id_developer-cert.pub is specified) when signing.


openssh, consciously, does not provide any tooling how to distribute or
maintain certificates. So figuring this out would be our
task. Concretely, what we would have to design is an infrastructure that
allows a developer to request the certificate [1, 2]. 

The nice advantage of this approach is that for validation you only need
to distribute the id_gentoo_ca pubkey along with a description that it
is used as a CA:

  *.gentoo.org cert-authority,namespaces="gentoo" <id_gentoo_ca.pub string>


The one big advantage of this approach (as already mentioned in [1]) is
the fact that certificates allow you to validate whether a developer is
allowed to perform a certain action (at a particular instance in time)
without the need of having an up-to-date keychain.


I like this approach for its elegance, but I doubt that we benefit
terribly much from its benefits. So I'll leave my way too elaborate
blabla at that :-)

Best,
Matthias


[1] Support for certificates in openssh exists because it solves a real
    problem for large companies where the number of employees who should
    be allowed to access a resource might vary wildly, and (a) the
    constant redistribution of keychains is painful, and (b) if a server
    fails to receive an updated keychain then the failure mode might be
    catastrophical.


[2] A number of commercial solutions for this exist, that tie some
    enterprisey authentication to retrieving a short-lived purpose-bound
    ssh certificate (think "developer is allowed to log into server type
    bla for the next 4h".)


[3] We could, for example, provide a command line tool that essentially
    ssh'es into dev.gentoo.org, requests the certificate and puts it
    into place.