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.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
