Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Apr 2013 00:55:22 -0600
From: Kurt Seifried <>
To: Alistair Crooks <>
CC:, Josh Bressers <>
Subject: Re: upstream source code authenticity checking

Hash: SHA1

On 04/25/2013 11:57 PM, Alistair Crooks wrote:
> On Thu, Apr 25, 2013 at 01:30:23AM -0600, Kurt Seifried wrote:
>> On 04/24/2013 11:55 PM, Alistair Crooks wrote:
>>> I'm not sure what using PGP gains us?
>>> Regards, Alistair
>> So some possible outcomes are:
>> 1) They do PGP/GPG and don't get compromised. Long term outcome:
>> we come out way ahead.
>> 2) They do PGP/GPG and do get compromised. Long term outcome: we
>> trust bad things and lose, hopefully this gets spotted quickly
>> and dealt with.
> Sure.  I actually agree with you.  But I'd also like it if we
> could bear in mind that, with PGP, trust is earned, trust
> signatures are snapshots in time, and trust levels are private,
> best guessses by people.  All people can see from a key listing is
> who trusted them and when, not how much, or whether the trust was
> warranted.

This makes no sense. So you don't trust their signature because they
have to "earn trust", but you do trust their software and you compile
and run it? That's literally insane.

Unless you actually audit every bit of source code you download and
audit before compiling/usage then by definition you are already
blindly trusting a lot of people (the software project, the host
serving it, every intermediate network, etc.).

I a seriously confused that a lot of people seem to think unsigned
code is somehow ok, but if we sign the code we have to do it perfectly
to have any value. This simply isn't true. Right now unsigned code is
wide open, and detecting changes is expensive (you need a full copy to
compare against, and if you have a copy why would you care? =).
SIgning releases with PGP/GPG makes this problem a lot easier to
handle and even if it fails, by definition the attacker would have
been able to pull the attack off any ways.

Can we please get over this "security must be done perfect or not at
all" and maybe actually get on with making things better? We have to
start somewhere. Sitting here going "well we won't do it unless we can
do it completely correctly" is just stupid and pointless. Seriously.
We need to start raising the bar and teaching people, this is far
better than refusing to do anything since it won't be perfect.

A perfect example of this is CVE assignments. Most projects do not do
them well or at all. Should I give up? Or should I try to educate them
and hand hold as needed so that they learn how to do it and start
doing it properly? This is what I have been doing and you may notice
that XEN, OwnCloud, OpenStack and a few others are now shipping
advisories with CVE's already assigned. And most of them are doing CVE
requests in a way that is efficient and scalable.

And next month (hopefully) you'll be getting even more CVEs (due to
more vendors doing CVE requests properly and easily for me), and then
at some point we'll bring OSVDB into the fold (once Steven figures out
how =) and it'll get even better.

Got to start somewhere. And if you want to go build some perfect
system I wish you luck, but I suspect like most attempts at perfection
it won't get very far.

> Regards, Alistair

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.13 (GNU/Linux)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.