> On May 27, 2026, at 10:30 PM, brian m. carlson <[email protected]>
> 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
