llvm dev - Jan 2013 - [LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

Mark,
> Pawel,
> 	You don't know me but I'm one of the release engineers for
> BIND 9 and BIND 8 before that.  I have been doing release engineering
> for about 1.5 decades now.  One of the things you DO NOT do is
> replace a tarball.  Machines get compromised.  Good distributions
> get replaced with tainted versions.  One of the few ways the rest
> of the world has some assurance that they are getting a untainted
> version is that what you get now is what you got when the product
> was first released.  One of the way a site learns that it has been
> compromised is tarballs changing.
Seems like a sad situation that will only get worse.
> 
> Yes, the replaced tarball is signed with your signature but I don't
> know you from a bar of soap.  I don't know what your relationship
> is to UIUC.  There is NO information that I can see on the llvm.org
> web site that says that you are permitted to sign the distribution.
> 
This might be one of the lessons from this debacle that new
LLVMRM should somehow be brought into the "web of trust".
> What I do know is that the release announcement came out on the
> 20th of December and the tarball was replaced on the 12 of January
> and there has been nothing sent to the llvm announce list.
> 
> This makes me uneasy.
> 
> gpg -v /usr/ports/distfiles/llvm-3.2.src.tar.gz.sig
> gpg: assuming signed data in `/usr/ports/distfiles/llvm-3.2.src.tar.gz'
> gpg: Signature made Sat 12 Jan 02:30:04 2013 EST using DSA key ID 7CB2EFFB
> gpg: using PGP trust model
> gpg: Good signature from "Pawel Wodnicki (elektrknight) <root at
32bitmicro.com>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the
owner.
> Primary key fingerprint: 4D8F 3DD4 7CBD 5212 7155  AC65 09C4 E700 7CB2 EFFB
> gpg: binary signature, digest algorithm SHA1
> 
> As for downstreams being involved in the release process, they are. There
> is a implicit step that you should write down in your formal processes.
> 
> 	    Do NOT change a released tarball for any reason.
> 
> We have re-released tarballs over my and other developers objections.
> Everytime this has been do we have been 'tared and feathered' and
> quite rightly so.  Unfortunately each new manager needs to learn
> this lesson.
Perhaps not, but it seems that in the age of social coding and
IRC one can misconstrue the allowance to make other changes to
changing the tarball. For that reason I agree, it should be
spelled out in bold letters at the end of the document, once
we are done *do not change the tarballs!*.
> 
> Yes it would be nice to get feedback that something broke on some
> platform before you cut the final release.  I understand that
> feeling.  I don't know how many times I've cut a release to only
> find that BIND doesn't build in a particular build environment
> despite using build farm and doing release candidates.
Your situation is a bit different as you target a lot of
platforms out there. LLVM is released for a much smaller subset
so there should not be an issue to get the feedback.
And here I think lies a problem for any LLVMRM. It is an old
lesson re-learned yet again, do not try to wear too many hats
and get the community involved in the release.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE:	+61 2 9871 4742		         INTERNET: marka at isc.org
Thank you for taking time to write this message, reading it helped
restore some sanity in a way that winking smileys didn't seem to.

Paweł