vsftpd in the news

[Miloslav Trmač]

On Wed, Jul 6, 2011 at 9:19 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote:
>> > 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. :)
>>
>> 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?
It can protect Fedora against substituted upstream tarballs (i.e. if
the new upstream version has an incorrect signature, we would notice).

> Doesn't that make it easier to compromise the src.rpm by replacing
> tarball, sig, and key?
That's "protecting Fedora users against substituted Fedora RPMs",
which is quite orthogonal to protecting Fedora against upstream
tarballs.

> How does "the check" know whether an included key
> is the right one and can be trusted, too?
The package maintainer can decide who is trusted to publish upstream
releases, and list the trusted keys in a config file.

> 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...
Yes, we could require gpg-signed git commits; but note that this
wouldn't be a protection against hijacked Fedora accounts, IMHO the
most likely avenue of attack.  gpg-signed git commits would protect
the integrity/verifiability of the git history (e.g. against attacks
directly on the git repo storage, or against an attacker having root
on the Fedora servers) - but only as long as the Fedora account system
(housing the public keys of package maintainers) would not be
compromised as wel.
    Mirek