warning to list

[Alexandre Oliva]

On Oct 28, 2004, Matias Féliciano <feliciano.matias at free.fr> wrote:

> As often as the server is insecure.
> Do you mean the build server is a total disaster about security ?

It means lots of people have build access to it.  If having build-user
access to it implies being able to attach a signature to the package,
it means anyone with build access is able to obtain the signing key.

> If it's the case, why should I even trust unsigned rpm ?

Oh, so we're getting somewhere here.  Maybe you shouldn't?

> Just curious, How many time the build system have been cracked ?

None that I'm aware of.  And this wouldn't have affected the key
anyway, because they key is not part of the build system.  But in
order to have automated signatures stapled to packages, it would have
to be, and the key could easily leak.

> All you say is "if ..., if ..., if ...".
> Should I continue to flame with other "if ..." ?

If you like :-)

But if we decide to do so, what if both of us become closely familiar
with good security principles?

You see, it's about analyzing risks and determining how to minimize
risks without excessive costs.  Without considering theoretical
scenarios (to avoid the word), it's very hard to do any such analysis.

> With unsigned rpm, no "if ..." is needed. I can definitely not trust rpm
> package. Period.

Exactly!

But with a signed rpm, you get a false sense of security because you
may think you can trust it.  But you can only trust it, to whatever
extent you choose to trust it, if the key is known to be safely
guarded.  If it isn't, you're just fooling yourself.  The signature is
actually working against you.

>> > What append if the build server is cracked ?
>> > Nothing. It's like having none signed rpm (like the current practise).

>> Not quite.  People would still trust the old key

> Come on...
> Right now people are "forced" to _always_ trust unsigned package.

Err...  Come again?

Who's forcing anyone to trust unsigned packages?

I haven't signed this message.  Am I forcing anyone to read it?  I
don't think so.

If you read it or not, and if you choose to believe I wrote it or not,
is up to you.  I'm not forcing you anything.  I'm not even compelling
you to write a reply (quite the contrary ;-), but you will anyway :-)

> The current situation is worse than "one day, some people wrongly
> trust a key".

You got a very twisted view of good/bad IMHO.

> Do you think it's a good security practise ?

Certainly not.  Personally, I'd much rather have all packages in
rawhide signed.  But with a properly-created signature.

Failing that, I'd write a script to repeatedly attempt to update,
progressively adding exclude arguments to up2date or yum, until it
installs a complete set of signed packages, and wait to get the
unsigned packages in the next rawhide push.

Failing that, I'd be more than willing to live with a signed-rawhide
repository, that we could build the way I described in a previous
posting.

Failing that, well...  Maybe we could create a community of volunteers
who would keep monitoring the mirror sites looking for corrupted
packages, and maybe even offering rawhide mirror-like sites with
additional signatures attached to the packages.

>> until they find out

> A new argument. The "if ... until ...".

/me is happy you're finding patterns in my arguments.  Now maybe you
could focus on the content instead of the form :-)

>> about the revocation and, by then, it might be too late.

> With unsigned rpm, if any single mirror is corrupted it's already too
> late to do whatever.

If any single mirror is corrupted, it's too late for people who got a
package from there and didn't check it before installing.  Yes,
checking is a pain.

> Sorry for this "if" argument.

Don't be.  It's a perfectly legitimate way to consider dangerous
situations and assess their risk.

>> Not to
>> mention again the need for obtaining new keys whenever this happens.
>> 

> gpg --gen-key 
> gpg --export --armor key > PUBKEY
> ftp ... "put PUBKEY".
> Anyway. we will be back temporally to unsigned rpm. No more.

You're missing the point.  Why would I trust a random key I obtained
from an ftp site?

Such a key would have to be signed by another Red Hat key to be of any
value.  No big deal for those who understand the issue, but how many
people you think would check the signature in the key, to verify that
it's legitimate?

How many people would fall for a fake e-mail from Sopwith announcing
the new Fedora Rawhide automated-build signing key, with instructions
on how to install it such that up2date will use it.  Instructions that
could also get up2date or yum to use a mirror known to have been
broken into.

>> > What damage this will cause the Red Hat business ?
>> 
>> Having keys revoked and new ones issued would definitely look bad.

> I have a revocation certificate for my key. Should I stop using gpg
> because *perhaps* I will need to use it ?

Certainly not.  But if you don't protect your key and actually need to
revoke it, it shows that your security practices could use some
improvement, and people would decrease the amount of trust on your key
(not to mention your stock)

> This doesn't make any sense.

It does to me.

> Suppose my mirror (or http://mirrors.kernel.org/) is cracked then
> Slashdot will be happy to point that Red Hat don't sign their package
> even if the build system is not cracked.
> The reputation of Red Hat rely on _all_ mirrors if packages are not
> signed.

And if it becomes so difficult to explain to people at Slashdot why it
is so as it is to explain to you, that appears to be way more
competent in the subject than the average Slashdot reader, we're bound
to lose no matter what.

> If the build system is cracked and Red Hat don't use signed rpm do you
> think it's better for the reputation of Red Hat ?

Definitely not.  Getting the build system broken into would be a
terrible thing.

Getting a random mirror site broken into is, well, a problem, but it's
not Red Hat's fault.

Getting people to trust such mirror site isn't Red Hat's fault either,
but it's something Red Hat could help avoid by signing all packages,
yes.  Unfortunately such signing is not practical, and gets in the way
of the real goal of rawhide (which, as you know by now, is to get a
backdoor into everybody's machines: any Red Hat developer can build a
package that makes to rawhide and, next day, he'll have an army of
zombies ready to launch his DoS attack against www.mycrosoft.com.  Too
bad there's a typo in the site name ;-)

Yeah, getting fast turn-around for people to test packages is a
secondary point. ;-)

>> The trick here is: how to get the signatures automated without
>> further exposing the key?

> Do what you can.

I thought we were already doing it.

> If the key is cracked in 2 mouths I'll enjoy using signed package during
> 2 mouths. Still better than nothing.

And next day you'll get a malicious package installed on your box and
you'll be left with, well, nothing.  Ok, that's not worse than
nothing, but it's worse than *your* nothing above :-)

> Here is the point. Currently Red Hat does not *want* to do any thing for
> the security.

Red Hat is doing what it can, and pretty well.  Doing what you want
would open a huge hole in the system, and would cause a lot of
damage, although you can't see that.  I've already exposed my
arguments, and I intend to step out of this debate now.  I've already
spent far too long exposing good security practices to someone who
doesn't seem to want to listen.  I hope at least others have benefited
from the discussion.

> It is the decision of Red Hat (btw, Slashdot will be happy to know
> this). All these "pseudo technical" arguments are not relevant.

Oh, wow!  pseudo technical arguments.  I didn't even know I could make
those.  Cool!  I'm *so* happy.

Just to make it clear, I don't speak for Red Hat, and I'm totally
unfamiliar with the procedure Red Hat uses to sign packages.  I'm just
working on assumptions driven from some knowledge on good security
practices, and a bit of common sense.  I thought it would be important
to make this clear, before it hits Slashdot.  Not that the average
Slashdot reader would pay attention to this fine point :-)

Thanks for your attention,

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}