[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources



On Aug 4, 2008, at 3:23 PM, michael@stroeder.com wrote:

> Kurt Zeilenga wrote:
>> For instance, web_ldap says it provides a signature for a digital
>> release, but clicking on the link provides a page which says "Not
>> found".
>
> I knew this (transition during a major OS update on my local machine).
> It's fixed.

My point was not wether you knew it or not, but whether any verifier  
would care.

>
>> But, as I noted with hashes, the fact that release messages are  
>> widely
>> published may make it more likely that such problems will be  
>> detected.
>
> Hashes have to be validated out-of-band each time a new release is
> published.  The trusted keys be have to be validated out-of-band only
> each time a new trust anchor key is generated.

The point here that an attacker can create the same level of trust for  
any new signing key they might use (or trust in that no signing was  
done) for the rouge release as the trust tends to be just publication  
of the signing key on the web site.

And, as I noted, an attacker could just change stable from 2.m.y to  
2.n.x, where 2.n.x was some crackable release.

Personally, I place a less trust on a signing key I fetch off a  
website than a hash I get both by email, on a moderated list, that I  
can verify in the list archives, and on the FTP site.  The former is  
actually seems more subject to MITM attack than the latter.   Now,  
with https:, I would say they have fairly comparable security  
considerations.  Basically, if an attacker owns the website/ftp host,  
the attacker can fool most everyone.

>
>> For instance, one does need to consider that
>> the host to sign the releases might itself been taken over and the
>> implications of such a takeover.
>
> There is no 100% security. I already know this. But raising security
> level is always an desirable goal.

You haven't clearly stated how the security level is actually getting  
raised through the signing you suggest.

>
>> Anyways, for this to go anywhere, I think you or others advocating it
>> need to more precisely state which attacks you concerned about, how  
>> you
>> think digital signatures will help, and detail requirements on that
>> signing (in particular, requirements on signing key so trust can be
>> established and maintained).
>
> I have no objections against a single release manager using his  
> personal
> key or a dedicated key for OpenLDAP tar.gz signing stored in your  
> local
> file system reasonably protected by a passphrase.  As I see it  
> you're the

> only one packaging the tar.gz. So this should not be too difficult for
> you.

What about a purely self-signed signing key with finger print  
published on the website, and possible release announcements.  (The  
latter arguable would be better, as it's more widely published.)    
[This appears to be the appraoch you've taken with web2ldap.]  But, as  
I've noted, this really doesn't offer significant better security than  
widely published hashes.

However, if what you want is a signing key in which members of the  
public can personally verify is in the control of the project, that  
would be more difficult to provide.

Or, if what you want is a signing key which is in a wide web of trust,  
the difficultly depends on the scale of the web of trust desired (to  
the point of approaching the general public problem).

> Well, if you don't want to do that then just leave it...
>
>> Note that these are human-factor attacks, not attacks based upon any
>> weakness in the PGP signing standards or implementations.
>
> I already know that.

This comment was for the peanut gallery.

-- Kurt