vsftpd in the news

[Miloslav Trmač]

On Wed, Jul 6, 2011 at 10:43 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote:
>> > 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).
>
> The packager should have noticed already. If the sig file is added
> to the src.rpm and the public key has been added to it [a long time] before,
> all AutoQA would add is to detect the case when the packager added
> a new tarball+sig without verifying it beforehand. Right?
Exactly.

> If it's possible to hack a web page and replace a tarball, it would also
> be possible to replace a detached sig file (or even add a faked one for
> the first time and pretend that it's a new feature of the release process).
> It wouldn't be the first project where the signer and/or the signing key
> has changed, and where the downloader needs to decide on whether to trust
> the key that has been used. That is, not just use --recv-keys to fetch it
> from a key server.
That's an interesting subproblem, especially if the signing key were
lost.  In practice, handling a key change can probably be done
reasonably securely even in such cases, e.g. by announcing the key
change on the project's mailing list where the holder of the previous
key and the project's governing body would have to notice the
announcement, and waiting long enough to allow for the project members
to contradict the announcement.

>From the Fedora point of view, we don't need to do anything special -
the package maintainer would or would not update the list of trusted
tarball signers depending on the packager's view of the situation.
    Mirek