warning to list

[Alexandre Oliva]

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

> Interesting. It's better to be a RHEL tester than a Fedora tester.
> Bad to learn this because RHEL is _based_ on FC.
> Better is FC, better will be RHEL.

But still, if RHEL is not tested by lots of people, including Red Hat
QA dept, odds are that problems might be introduced in the RHEL code
base only, after it forks off the base FC release.

> Explain me these two points from Red Hat : 
> - test Fedora release are not for mission-critical so there is no need of signed rpm
> and 
> - beta RHEL release are not for mission-critical but we only provide signed rpm

> Why ?

The only explanation I can think of is that testing RHEL is also a way
of testing the update delivery mechanism, namely RHN/up2date, so you
get to use RHN.  Since I suppose Red Hat's RHN server won't ever
accept unsigned packages, it becomes a requirement for updates for
RHEL beta to be signed.  But I don't even know whether such updates
are signed in the first place, I'm just coming up with theories, from
the little I know about that process.

>> This signature is actually manual.  One of the few people who control
>> the keys has to be there to put it there.

> OK. And what they do ?
> They enter the passphrase and go take a coffee. This is not valuable.

As long as the key is protected, it is valuable in that you can
assume that it was signed by the key holder.

The more exposure the key gets (which would be necessary for automated
signing as part of the build process), the less valuable the signature
is.

> This can be done with expect.

If the key is permanently available and the passphrase that protects
it is permanently in memory.

> If the build system (or whatever it is) is cracked, the passphrase can
> be snipped. In all case signing require a secure system !

Yup.  That's why the less widely available the signing key is, the
better.  If all machines in the build system had access to it, the
signature would be worth very little.  If only one single, very secure
machine does, the signature is far more reliable, and hopefully you
won't have to revoke the key as often as in the previous case.

> Yes. But automated signing is better than nothing.

Not necessarily.  If the key is compromised as often as it could with
a badly-implemented fully-automated signing process, you'd get to
update your key ring daily.  How convenient would that be?

> Manual signing or not, I don't care. Seems Red Hat try to push
> people to RHEL BETA (ok, sound like FUD).

It definitely is FUD :-)

You're sure welcome to test both :-)

> 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 until they find out
about the revocation and, by then, it might be too late.  Not to
mention again the need for obtaining new keys whenever this happens.

> What damage this will cause the Red Hat business ?

Having keys revoked and new ones issued would definitely look bad.  If
one can't trust the automated build key, why would any of the others
be trusted?  Even if there's a web page explaining why you shouldn't
trust the automated build key, how many people would jump to incorrect
conclusions on Slashdot before getting the facts?

> Why Red Hat are afraid about signing Rawhide packages ?

We're not.  They're signed quite often.  Whenever one of the key
holders happens to feel like signing packages.

> As long as the secret key is ... secret, automated (or not) signed rpm
> is better than nothing.

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

-- 
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}