Interest in other signature libs/tools?
Hello, I've been using pacman for a little while in Mere Linux (https://github.com/jhuntwork/merelinux). In trying to keep things simple, I sidestepped support for digital signatures for a while, but I'm now at a point where I'd like to include it. However, I'd prefer not to use gpgme and friends. I'd rather use a more modern and simpler library. I've been looking at things like minisign and signify. Recently I found https://github.com/vstakhov/asignify which snapped into pacman pretty easily and is pretty much exactly what I'm looking for. At the moment I only have a pretty hacky patch to make it work, so nothing that is ready to share here. But I wanted to gauge if there is any interest in supporting different libraries/tools, or if I would need to maintain my own patch downstream. Thanks much for your good work and any feedback you may have. JH
On 23/12/21 00:18, Jeremy Huntwork wrote:
Hello,
I've been using pacman for a little while in Mere Linux (https://github.com/jhuntwork/merelinux). In trying to keep things simple, I sidestepped support for digital signatures for a while, but I'm now at a point where I'd like to include it. However, I'd prefer not to use gpgme and friends. I'd rather use a more modern and simpler library. I've been looking at things like minisign and signify. Recently I found https://github.com/vstakhov/asignify which snapped into pacman pretty easily and is pretty much exactly what I'm looking for.
At the moment I only have a pretty hacky patch to make it work, so nothing that is ready to share here. But I wanted to gauge if there is any interest in supporting different libraries/tools, or if I would need to maintain my own patch downstream.
Thanks much for your good work and any feedback you may have.
Going into this blind having not looked at the other signing libraries... but if there is substantial benefits of moving to another library, we would likely consider it. Assuming there is rough feature parity. A skim of the asignify indicates you would need to trust every key that signs a package, and not use a web-of-trust approach? In fact, I don't see a way to assign trust to specific keys. I could be wrong here. Allan
On Thu, Dec 23, 2021 at 9:53 AM Allan McRae <allan@archlinux.org> wrote:
Going into this blind having not looked at the other signing libraries... but if there is substantial benefits of moving to another library, we would likely consider it. Assuming there is rough feature parity.
A skim of the asignify indicates you would need to trust every key that signs a package, and not use a web-of-trust approach? In fact, I don't see a way to assign trust to specific keys. I could be wrong here.
Yes, I believe with libraries in the pattern of minisign, signify/asignify there is no support for a web-of-trust. For me that isn't a problem for reasons I'll outline in a moment, but I think if Arch were to adopt any of those libraries as standard, that would involve a pretty fundamental shift in how you package and release, no doubt a much larger discussion. I'm saying this without a completely clear picture of your package release process, so I may be wrong. The reason I don't see it as being a problem for me is that my intent is to release authoritative packages from one source, a CI/CD pipeline that is triggered off of the main repository. Validation and trust of humans that are allowed to push to that repository and trigger official releases can be handled via other mechanisms. Community repositories might have slightly different requirements, but my expectation is that every repository used could have one official public key. Anyway, I'm not trying to sell you on that model or suggest that Arch adopt it. Just wondering if pacman itself is interested in supporting it as an alternative for projects like mine. Thanks again! JH
On Thu, Dec 23, 2021 at 10:14 AM Jeremy Huntwork <jeremy@merelinux.org> wrote:
The reason I don't see it as being a problem for me is that my intent is to release authoritative packages from one source, a CI/CD pipeline that is triggered off of the main repository. Validation and trust of humans that are allowed to push to that repository and trigger official releases can be handled via other mechanisms. Community repositories might have slightly different requirements, but my expectation is that every repository used could have one official public key.
I suppose if I did have a reason for supporting multiple keys, those would all have to be shipped/installed together and then pacman could loop through them until one of them validates the sig. asignify is fast enough though because of its methods and algorithms used (blake2) that I don't really see that as an issue either. JH
On 24/12/21 01:30, Jeremy Huntwork wrote:
On Thu, Dec 23, 2021 at 10:14 AM Jeremy Huntwork <jeremy@merelinux.org> wrote:
The reason I don't see it as being a problem for me is that my intent is to release authoritative packages from one source, a CI/CD pipeline that is triggered off of the main repository. Validation and trust of humans that are allowed to push to that repository and trigger official releases can be handled via other mechanisms. Community repositories might have slightly different requirements, but my expectation is that every repository used could have one official public key.
I suppose if I did have a reason for supporting multiple keys, those would all have to be shipped/installed together and then pacman could loop through them until one of them validates the sig. asignify is fast enough though because of its methods and algorithms used (blake2) that I don't really see that as an issue either.
I'm not a fan of the idea that if a user has a handful of non-distro repositories configured, that every package signature would need checked against multiple keys until one passed. Is there no way of identifying the correct signing key from the signature file? Allan
On Thu, Dec 23, 2021 at 11:34 PM Allan McRae <allan@archlinux.org> wrote:
I'm not a fan of the idea that if a user has a handful of non-distro repositories configured, that every package signature would need checked against multiple keys until one passed. Is there no way of identifying the correct signing key from the signature file?
Yeah, I believe there is. Here's the contents of a generated public key: asignify-pubkey:1:mtG16Izr+xQ=:FlDRmIlYxCG0QAm7Jjmf/im62EBfg2nCpwzGPpkq+30= And here's the contents of the sig file made using the corresponding private key: asignify-sig:1:mtG16Izr+xQ=:txEF3fQ/gaBAVCi8WpDICWn9i7gqgfJXp/viJDQeeETfbZTheIXHitmXv9Z+RQO9dYQDkJ6AMZt/xTU1/lWlDQ== BLAKE2 (test.c) = f8222a69bb9672b76ad7cc8776902a4b5bdde47b64040cd6febe798df3c7545a1f86e1ae94898f63fe94e3cabb91cda359be6b12edddcccd95ef5fd965349600 So it looks like third field on the first line is a fingerprint for the key. JH
Am Donnerstag, 23. Dezember 2021, 16:53:24 EET schrieb Allan McRae:
On 23/12/21 00:18, Jeremy Huntwork wrote:
Hello,
I've been using pacman for a little while in Mere Linux (https://github.com/jhuntwork/merelinux). In trying to keep things simple, I sidestepped support for digital signatures for a while, but I'm now at a point where I'd like to include it. However, I'd prefer not to use gpgme and friends. I'd rather use a more modern and simpler library. I've been looking at things like minisign and signify. Recently I found https://github.com/vstakhov/asignify which snapped into pacman pretty easily and is pretty much exactly what I'm looking for.
At the moment I only have a pretty hacky patch to make it work, so nothing that is ready to share here. But I wanted to gauge if there is any interest in supporting different libraries/tools, or if I would need to maintain my own patch downstream.
Thanks much for your good work and any feedback you may have.
Going into this blind having not looked at the other signing libraries... but if there is substantial benefits of moving to another library, we would likely consider it. Assuming there is rough feature parity. Or what are the problems with the existing solution, what should be changed? For example if are problems interfacing with gpgme e.g. compared mininsign?
On Sun, Dec 26, 2021 at 6:24 PM Bjoern Bidar <bjorn.bidar@thaodan.de> wrote:
Or what are the problems with the existing solution, what should be changed? For example if are problems interfacing with gpgme e.g. compared mininsign?
To be very clear, I'll just state again that I'm not proposing that Arch undertake a change, or that pacman should drop support for gpgme. My motivation is as a downstream user of pacman, and for my needs, I would like to use a simpler, and more modern signature solution. gpgme pulls in a lot of extra libraries and complexity that isn't required for just package signing. I think you can see the difference in complexity too by comparing pacman's current code for key verification with the sample code here: https://github.com/vstakhov/asignify#libasignify-api Of course a real world implementation would require a bit more, but I think it still illustrates the point. Beyond that, some have made arguments that PGP is just generally bad: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html But even without those arguments, the complexity alone makes it less than ideal for my use cases. Up to now, the design of my distro has been very light and simple. I can create a base Docker image with pacman and busybox at about 5MB. I have been compiling pacman statically, and if I add in gpgme, pacman's size doubles (IIRC). Besides that, when I last tested, it still required that the gpg executable itself (and its dependencies) be present on the machine. At this point, my plan is to use pacman with asignify. It would just be much nicer if I didn't need to maintain my own patch/fork. JH
participants (3)
-
Allan McRae
-
Bjoern Bidar
-
Jeremy Huntwork