Re: [boost] [release] Tags are not being used correctly

Subject: Re: [boost] [release] Tags are not being used correctly
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-03-23 03:43:16

On 23 Mar 2016 at 0:58, Michael Witten wrote:

>   Annotated tags are meant for release while lightweight tags are meant
>   for private or temporary object labels. For this reason, some git
>   commands for naming objects (like `git describe') will ignore
>   lightweight tags by default.

Whether to sign releases or not came up during the svn to git 
migration.

It was decided it wasn't worth it then because it adds no useful 
value at the superproject level. Even if every single maintainer 
signs their tagged releases for their libraries, a Boost release 
isn't made up of tagged subrepos, it's made up of whatever happens to 
pass all the regression tests and is found to not have problems at 
the time. Subrepo tags play no part in an overall Boost release.

Therefore signing the superproject tag means only that "we think this 
seems to work" not that "we sign off on this collection of maintainer 
signed off tags".

And if one is merely signing "we think this seems to work", well 
that's also called a boost release ZIP archive.

I'm personally for supplying MD5's of boost release archives for 
integrity validation. I'm also for signing release archives (though 
you'll need something newer than ZIP ideally) so what leaves the 
release manager's computer is what users get.

But signed git tags, and *especially* signed git commits are quite 
useless outside an individual project where an individual maintainer 
has made 99% of the commits and has carefully reviewed the remaining 
1%. At the superproject level you can say very little about the 
combination of all subrepos except that "it appears to work".

(Commit validation is one of git's weakest areas, it's a very poor 
design and it really wouldn't kill them to sign commits using the SSH 
key you use to push to github and/or a S/MIME cert for your email, 
that way you have a perfect chain of validation with zero extra 
effort by developers such that injected malicious commits are 
impossible without being detected. But that's another story).

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/