Supporting openssh-signing of packages and databases
Would pacman be interested in supporting signature verification of packages (and databases) using the (relatively new) signing protocol introduced and implemented by Openssh [1], alongside GPG signatures ? The intended benefits are be easier packagers setup and workflows (compared to GPG), as well as more out of the box support for signing with FIDO2 tokens (as openssh has sk-* keys to natively support those). The ALLOWED_SIGNERS (documented in man ssh-keygen) file and thus the signing namespace or namespaces would be up to the distribution using pacman (presumably, different distributions should not use the same namespace(s)). If there is interest in this, I'm interested in trying my hands at an implementation; in that case, I'd welcome any advice or things to avoid in doing so. Thanks, [1]: https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.s... -- Max Gautier
On 21/7/23 16:19, Max Gautier wrote:
The intended benefits are be easier packagers setup and workflows (compared to GPG), as well as more out of the box support for signing with FIDO2 tokens (as openssh has sk-* keys to natively support those). The ALLOWED_SIGNERS (documented in man ssh-keygen) file and thus the signing namespace or namespaces would be up to the distribution using pacman (presumably, different distributions should not use the same namespace(s)).
The answer is a solid maybe... Even leaning towards yes here! Questions to answer first: 1) would we allow mixed signature verification. e.g. some repos use GPG and others use openssh? Or some repos using both? 2) What do we need to add to package entries in repos so that pacman knows the signature file to download. Our current assumptions are very GPG based... 3) What will be our criteria for including additional signature verification methods? openssh seems a good option for me, but we have had people request one of the other new signing variants. Allan
On Sun, Aug 20, 2023 at 03:31:41PM +1000, Allan McRae wrote:
The answer is a solid maybe... Even leaning towards yes here! Questions to answer first:
1) would we allow mixed signature verification. e.g. some repos use GPG and others use openssh? Or some repos using both?
I think pacman should have the capability to check repos using both ; I don't see how else we could support a distribution migrating from one signature scheme to another (re-signing all packages at once seems unpractical). I think the decision of which scheme to allow should be left to configuration, either as a global setting in pacman.conf or as a per repo one.
2) What do we need to add to package entries in repos so that pacman knows the signature file to download.
I would not differentiate signature files depending on the scheme used, and just reuse the same structure (a .sig file). I see two possible ways if we do that: - detect the scheme used then verify signature (probably better error messages) - try to verify the signature with all allowed scheme (simpler)
Our current assumptions are very GPG based...
Do you mean just the filename of the signature or also other things ?
3) What will be our criteria for including additional signature verification methods? openssh seems a good option for me, but we have had people request one of the other new signing variants.
I would say the criteria should be that a new method bring something more or better compared to those already existing in pacman. That's a bit vague though ; it would probably be on a case-by-case basis. You're talking of minisign and signify, I suppose ? -- Max Gautier
On 22/8/23 23:22, Max Gautier wrote:
On Sun, Aug 20, 2023 at 03:31:41PM +1000, Allan McRae wrote:
The answer is a solid maybe... Even leaning towards yes here! Questions to answer first:
1) would we allow mixed signature verification. e.g. some repos use GPG and others use openssh? Or some repos using both?
I think pacman should have the capability to check repos using both ; I don't see how else we could support a distribution migrating from one signature scheme to another (re-signing all packages at once seems unpractical). I think the decision of which scheme to allow should be left to configuration, either as a global setting in pacman.conf or as a per repo one.
I have been thinking on this... I think pacman needs to be able to be configured to support zero/either/both signature methods (just considering GPG and openssh at this time). We currently allow enabling/disabling GPG support. A global/repo level pacman.conf setting fits our current set-up with signature level verification. However, I am not convinced that repos using a mixture of GPG and openssh signatures should not be supported. See below.
2) What do we need to add to package entries in repos so that pacman knows the signature file to download.
I would not differentiate signature files depending on the scheme used, and just reuse the same structure (a .sig file). I see two possible ways if we do that: - detect the scheme used then verify signature (probably better error messages) - try to verify the signature with all allowed scheme (simpler)
We really need better error messages anyway! The simple version is probably a no-go. GPG checks are fairly costly, and given current signature usage, it would make sense to check these first. This problem becomes worse if additional signing methods become supported. Signature type detection would be interesting, but I see it being brittle/complex if/when alternative signing methods get added. Having a single configurable signing method per repo removes the need to even deal with this.
Our current assumptions are very GPG based...
Do you mean just the filename of the signature or also other things ?
I was thinking filename, but I see openssh uses .sig too. So that logic does not need updated.
3) What will be our criteria for including additional signature verification methods? openssh seems a good option for me, but we have had people request one of the other new signing variants.
I would say the criteria should be that a new method bring something more or better compared to those already existing in pacman. That's a bit vague though ; it would probably be on a case-by-case basis.
You're talking of minisign and signify, I suppose ?
Exactly. Overall, I am happy for this idea to move forward. My suspicion is that some initial refactoring may be needed to ease the addition of new signature formats. Without looking in detail, I suspect doing that would be a good place to start. Allan
On Tue, Aug 29, 2023 at 12:15:10AM +1000, Allan McRae wrote:
However, I am not convinced that repos using a mixture of GPG and openssh signatures should not be supported. See below.
I assume the last not was extraneous right ? Given the rest.
Signature type detection would be interesting, but I see it being brittle/complex if/when alternative signing methods get added.
As far as I can tell, the signature formats of minisign and signify are quite close (signify can verify minisign signatures, but not the other way around[1]) and include the following header: untrusted comment: <arbitrary text> Which could be used to distinguish types. Both SSH and GPG also have a header. Of course that header is necessarily untrusted, so every signature verification method should independently verify the signature structure without ever relying on the detected type.
Having a single configurable signing method per repo removes the need to even deal with this.
[...]
Overall, I am happy for this idea to move forward. My suspicion is that some initial refactoring may be needed to ease the addition of new signature formats. Without looking in detail, I suspect doing that would be a good place to start.
Allan
Great ! I'm going to take a look at the codebase and see what I can come up with. Given the discussion, I'll first focus on implementing support for configuring the signature method globally/per repo + the openssh signature format (and refactoring, if indeed needed). Signature type detection and "mixed signature method" repos if we eventually go that way can be added later on. Thanks [1]: https://github.com/jedisct1/minisign/issues/59#issuecomment-654809237 -- Max Gautier
On 29/8/23 22:20, Max Gautier wrote:
On Tue, Aug 29, 2023 at 12:15:10AM +1000, Allan McRae wrote:
However, I am not convinced that repos using a mixture of GPG and openssh signatures should not be supported. See below.
I assume the last not was extraneous right ? Given the rest.
Signature type detection would be interesting, but I see it being brittle/complex if/when alternative signing methods get added.
As far as I can tell, the signature formats of minisign and signify are quite close (signify can verify minisign signatures, but not the other way around[1]) and include the following header:
untrusted comment: <arbitrary text>
Which could be used to distinguish types. Both SSH and GPG also have a header.
Of course that header is necessarily untrusted, so every signature verification method should independently verify the signature structure without ever relying on the detected type.
Having a single configurable signing method per repo removes the need to even deal with this.
[...]
Overall, I am happy for this idea to move forward. My suspicion is that some initial refactoring may be needed to ease the addition of new signature formats. Without looking in detail, I suspect doing that would be a good place to start.
Allan
Great !
I'm going to take a look at the codebase and see what I can come up with. Given the discussion, I'll first focus on implementing support for configuring the signature method globally/per repo + the openssh signature format (and refactoring, if indeed needed).
Signature type detection and "mixed signature method" repos if we eventually go that way can be added later on.
Thanks
[1]: https://github.com/jedisct1/minisign/issues/59#issuecomment-654809237
It has been a while, but I have opened an issue in our gitlab to track this: https://gitlab.archlinux.org/pacman/pacman/-/issues/67
Thanks. This is still on my radar, but I've been quite busy ^. I've read the code, and it's indeed quite entangled with gpg semantics. I was trying to figure out and propose some new interface, but I got a bit stuck and put that at rest for awhile. My current idea is to take a more thorough look at pacman code itself to see how it could/would use that interface, which hopefully will give me some ideas. No idea when I'll work on that though. Cheers, -- Max Gautier
participants (2)
-
Allan McRae
-
Max Gautier