vsftpd in the news
mschwendt at gmail.com
Wed Jul 6 07:19:35 UTC 2011
On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote:
> > There's a few cavets that have been mentioned in this thread that would
> > make this functionality mostly pointless to try and implement.
> > 1) Not all packages include gpg signatures.
> > a) not everyone knows they can include them
> > b) SCM checkouts don't have signatures
> > c) some projects don't use them
> > 2) We don't have a system to validate a gpg signature in place. My
> > understanding of GPG is that we would need to house all the public keys
> > to validate against. Nothing like this exists. I'm lazy and don't feel
> > like creating such a system. :)
> > We're stuck with the lookaside cache checksum for now.
> 1) doesn't really matter. So we get some assurance for some packages,
> not all; it's still better than none. Don't make the perfect the enemy
> of the good.
> 2) ditto - we can 'house' them in so far as including them as package
> sources. If they aren't included then don't run the check. If they are,
> run the check...
If we include the whole show in the src.rpm, how does that add any safety?
Doesn't that make it easier to compromise the src.rpm by replacing
tarball, sig, and key? How does "the check" know whether an included key
is the right one and can be trusted, too?
Even included tarball sigs would need another layer, such as the package
creator signing off all files (large or compressed patches, too!) with either
a personal key or with a project signing-server. Just another layer, though...
More information about the devel