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
