Congratulations! Missing 3.0.0 tag?

[Randall S. Becker]

On September 9, 2021 4:34 PM, Steffen Nurpmeso wrote:
>Randall S. Becker wrote in
> <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com>:
> ...
>
>You are right in everything that you say.
>
> |Strictly speaking, the signature on a tag is considered immutable and \  |transitively applies the signature to the commit (it does not
>really, \  |but the effect is the same). The signature on a tag becomes invalid \
>
>The tag namespace is separate though.  Not that it matters in practice.  Just saying.
>
> |if the underlying commit, or parents of that commit in git's Merkel \  |Tree changes, so it is quite a strong signature. AFIAK, adding a
>signature \  |to the commit itself does not really improve the strength of the signing \  |(much), unless one implements a multi-signature
>structure - like the \  |commit and signatures on three tags on the same commit. You have then \  |implemented a three-signature
>authority, which basically is a Blockchain\  |-style authority (not quite - I used "-style"), providing that you \  |do trust the signers. I think
>the word for that is "over-kill" 😉, \  |but maybe not in the case of OpenSSL.
>
>Well.  The thing is, to me, that commits happen much more often than tags.  Tags are in a different namespace also.  "Sealing the
>branches" with a signed commit at times helps in case of trouble, even for a distributed version control system like git, with its "hardened
>SHA-1" checksums.  So of course all the core developers and a lot of other people have full repo clones and shall someone break in some
>infrastructure and mess around the OpenSSL team could simply talk and exchange hashes, and reinstantiate the master proper.  For
>people having local clones that came in via git:// protocol even a signed commit here and there would really be nice.  (For my tiny things i
>offer only https?, and "seal" all stable/ and release/ branches as well as master, only the development branches have no signature.)

The git signature structure is based on GPG signatures for one, not SHA-1. The tag namespace does not matter here. The signature becomes invalid if the combined tree of the commit the tag references changes. If the commit is replaced, the signature becomes invalid regardless of who does it. You can replace a signed commit with another signed commit but you would need to have the public side of the GPG key to validate it. A tag would not point to the new commit without breaking the signature. No one could replace Richard's signature, for example, except for Richard on the openssl-3.0.0 tag. The "breaking the infrastructure" would have to reconstruct the Merkel Tree, which, even in SHA-1 has a one in a billion chance of working, but that is unlikely to result in useful source code.

So there is a certain amount of trust of the signatures of the committers - they should probably publish their public keys so we can do the validation. It might be helpful if GitHub moved to SHA-256 repositories, though.