[Pkg-rust-maintainers] Bug#1137357: gpg-from-sq: provide a way to provide (or default to) deterministic signatures

[kpcyrd]

On 5/23/26 12:02 AM, brian m. carlson wrote:
> We'd need Sequoia to provide some way to provide deterministic
> signatures for at least v4 signatures, and probably v6 signatures as
> well.  I realize that v6 does not intend to allow this, but it is
> functionally required for testsuites as well as some cases with
> reproducible builds[0].
> 
> [...]
> 
> [0] While this might not be useful for _Debian_ reproducible builds, it
> is useful for _general_ reproducible builds where a trusted authority
> signs their builds in a reproducible way or includes a signature inside
> an archive which must be bit-for-bit identical.
The trend regarding signatures in Reproducible Builds is towards "signatures are 
build inputs", meaning:

- you build an unsigned artifact
- sign it with your private key out-of-band
- declare a 2nd build, with your signatures and unsigned artifact as build input
- the 2nd build merges them together, without private key access

This is necessary or the independent verifier would not be able to reproduce 
anything, unless you share your private key with them - either by permanently 
revealing the secret number, or letting them borrow your hardware signing key.

This two-step-build-sign-out-of-band is how Debian handles secure boot 
signatures and the story behind the linux-binary-unsigned-* packages.

You could attempt to do this in one build step, by building once with private 
key access, extract the signatures, add them to your declared build inputs, then 
build again with an oracle that hands out the corresponding pre-computed 
signatures when asked to sign a specific sha256 (without actually being able to 
issue any new signatures).

This approach is more fragile though.

Of course the most elegant solution is "avoid signing keys unless absolutely 
necessary", for example there's an ongoing effort to complement Linux kernel 
module signing with a merkle-tree based alternative that doesn't depend on 
secret numbers for security:

https://lwn.net/Articles/1012946/

Sincerely,
kpcyrd