FS#69843 - Allow multiple pgp signatures to validate the same file
Attached to Project:
Pacman
Opened by Setpill (setpill) - Monday, 01 March 2021, 10:16 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 17 June 2021, 22:38 GMT
Opened by Setpill (setpill) - Monday, 01 March 2021, 10:16 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 17 June 2021, 22:38 GMT
|
Details
Summary and Info:
Currently makepkg's verify_signature.sh script makes certain assumptions about the naming scheme of file signatures that make it impossible for the same source file to be signed by multiple signature files. Since the advent of reproducible builds, it is becoming more common for multiple maintainers/developers of a piece of software to provide signatures of a binary release. It would be nice to be able to efficiently support this. I have implemented *some* way of doing this in the lnd-bin PKGBUILD in the AUR, however it is easy to see this is not efficient; I am downloading the same source file multiple times, once for each signature. In this case, upstream provides signed manifests rather than signing the source files themselves. That has its own downsides, but at least downloading the manifest file multiple times is relatively painless. If it were possible to tell makepkg that a signature belongs to a specific file, this could be significantly optimized and becomes viable when upstreams sign their release binaries directly rather than through manifests. |
This task depends upon
A signature on a release artifact itself also doesn't really say "i made this" but more like "i vouch for this", which _can_ mean that you made it yourself.
And quite frankly the value is pretty low. The point of Reproducible Builds is that anyone can recreate the binary, delegating that right back to the lead developers to attest that it's reproducible doesn't really tell you much as their collaboration relationship is a significant source of of the lack of trust that Reproducible Builds seeks to solve.
This bug talks about verifying multiple signatures for source files in makepkg.
I don't think having multiple input source signatures would add really much value tho. theoretically the value is >0 if multiple entities look at all the history to vouch it... but well it indeed doesn't have to do with reproducible builds.
I know this, because I'm the one who opened it.
There is much more value add, IMO, to binary package artifacts than to sources. Most specifically, because I envisioned that pacman binary repositories could automatically merge trust attestations by appending to the signature file and rehosting the repo. Whereas that doesn't quite make sense for makepkg, nor for source code.
The point of reproducible builds is that the output of your build process is bit for bit identical to mine. If you make a file, and sign it, and I make the exact same file and sign it too, then someone can verify my signature against your file without knowing the difference.
The lnd-bin package came to be when the lnd package could not be built from source due to Arch packaging an incompatible version of Go, this package is in part a hedge against that happening again. Reproducible builds are also a defence against backdoored build machines. Malicious upstream developers are not something I include in my threat model for lnd-bin. Maybe I will in the future, but then I'll still want this feature :)
This is indeed about binary package artifacts, my bad for conflating terminology (in the lnd-bin PKGBUILD, the binary artifact is in the source array).
But if someone were to propose a patch, then I'd be in a much better position to judge its fitness and maintainability...