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

[David A. Wheeler]

> On May 27, 2026, at 10:30 PM, brian m. carlson <sandals at crustytoothpaste.net> wrote:
> 
> On 2026-05-27 at 17:40:56, David A. Wheeler wrote:
> Signatures should *not* be considered part of the item you're
>> reproducing. Signatures attest something about an artifact; added
>> signatures of attestation do not change the artifact being attested.
> 
> Unfortunately, you're at least a decade too late to hold that position
> when it comes to Git objects.  Git includes the signature as part of the
> object ID and there is no plan to change that.  In fact, I agree with
> that decision since it makes the signature functionally impossible to
> modify or remove.

Sorry, I must not have made my intended context clear.
I was talking about this in the context of building packages/containers; I was
*not* including the context of signing source code (which is used as an *input*
to a build process for creating packages/containers).

The mere *presence* of executable built artifacts in a source git repo
is often considered a serious security concern. OpenSSF Scorecard's
"Binary-Artifacts" identifies executable built artifacts in a git repo as a high risk:
https://github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts
It lists these "Problems with generated executable (binary) artifacts":
    • Binary artifacts cannot be reviewed, allowing possible obsolete or maliciously subverted executables. Reviews generally review source code, not executables, since it's difficult to audit executables to ensure that they correspond to the source code. Over time the included executables might not correspond to the source code.
    • Generated executables allow the executable generation process to atrophy, which can lead to an inability to create working executables. These problems can be countered with verified reproducible builds, but it's easier to implement verified reproducible builds when executables are not included in the source repository (since the executable generation process is less likely to have atrophied).

If we can't reproduce a commit object in the *source* repo, but we can verify it,
that's not a problem. When reading source, we just want to know "can we verify
that it's signed by a key I find acceptable", not "can I recreate the signature?".
In fact, being able to indpendently reproduce arbitrary signatures in a source repo
would be a serious vulnerability, that's forging with extra steps :-).

I wish my best to all working on the SHA-256 implementation in git!!

--- David A. Wheeler