[SM-Discuss] Threat profile analysis for spackages not signed by authors
Seth Alan Woolley
seth at positivism.org
Thu Sep 8 18:13:25 EDT 2005
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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050908/2aa4b148/attachment.bin
More information about the SM-Discuss