Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Thu, Sep 08, 2005 at 01:57:57PM -0700, Andrew wrote:
> Furthermore, hashes are no holy grail by any stretch (gpg is a wrapper
> around hashes btw), history tells us that when the upstream vendor
> changes their code un-announced, we do a cursory check to see if we're
> getting what we're supposed to, then change the hash/sig/whatever to
> match. Hows that for hashes preventing upstream compromises? The problem
> has nothing to do with the underlying verification technology.

I've done this twice in the last week already, for what it's worth 
(directfb and libbonoboui IIRC).

If we can verify that a vendor uses a good signing policy, I'd rather we 
let them sign and keep signatures on their server, so I can reduce the 
amount I have to manually inspect stuff.  But as is also true, if we 
don't trust their signing policy, we can easily, as Andrew points out, 
keep the signature in the spell.

The last one was a 50 thousand line diff, so large, I went to the 
vendors and traced the "re-release" announcement back to them to 
validate the change.

Sometimes the only thing that has actually changed is the dates and/or 
users/modes in the tarball file metadata -- those are simple to 
validate, but sometimes it's not so simple.

Every now and then, I'm not in the knowledge loop that a source has 
changed md5 sums, and I'm not sure how well we revalidate those, but 
afterwards, if I see it in the perforce review, I tend to take a look at 
it myself since I know I have to go update the copy on my mirror, and 
anything "changing" on my mirror, I take a diff of.

==

But back to the main point.  I've been in contact with an e-50 company 
(top 50 internet/electronics companies) regarding how they handle this 
very issue.  They debated it internally like we did, and they have come 
to a similar implementation as emrys has proposed to resolve the issue.

Now I realize some people still may not be comfortable with that.  We've 
had enough feedback and found enough real world misunderstanding that 
we've chosen to keep hashes around in the codebase and to be improved.  
Regarding the transparency of the poll, the poll was initiated by us, 
influenced against our desires, and I'm sure will be published soon.  I 
think it's a bit premature to inject sarcasm about its transparency (if 
that's not what was intended, i apologize).

Regarding the suggestion that we should ban signatures altogether, guru 
and vendor, is PGP inherently flawed in some way that we can discuss?  
The example given is the case that the passphrase gets compromised -- 
when PGP is designed around that as the major point of failure, I don't 
see this as a valid argument.  It's much easier to exploit hashes at 
some point in the supply chain than it is to compromise a passphrase, 
including social engineering, especially if security policies are public 
and followed.  The number of attack vectors are dramatically more in 
number and more in severity.  Remember, we're only trusting the vendor 
for a specific source file, that's why the key is given for not the 
spell as a whole, but associated to each source file.  Mutt has a number 
of optional patches, for example.  If you enable a patch with gpg vendor 
signing, you are in effect choosing your trust at that moment for that 
specific source file -- not when you cast mutt.

Seth

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454  E082 99F0 69DC FDCE E733

Attachment: pgpc9wsazPW01.pgp
Description: PGP signature