warning to list
feliciano.matias at free.fr
Thu Oct 28 20:04:06 UTC 2004
Le jeudi 28 octobre 2004 à 15:39 -0300, Alexandre Oliva a écrit :
> On Oct 26, 2004, Matias Féliciano <feliciano.matias at free.fr> wrote:
> > 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.
Still better than nothing.
> 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.
As often as the server is insecure.
Do you mean the build server is a total disaster about security ?
If it's the case, why should I even trust unsigned rpm ?
Your point don't make any sense.
It's up to me to set the owner trust value of the key. And "Marginally
trusted" still better than nothing.
Just curious, How many time the build system have been cracked ?
Once per week, once per year, or once per decade ?
> > 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?
Stop turning around.
All you say is "if ..., if ..., if ...".
Should I continue to flame with other "if ..." ?
With unsigned rpm, no "if ..." is needed. I can definitely not trust rpm
> > 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 :-)
Well, I do my best :-)
> 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
Right now people are "forced" to _always_ trust unsigned package. The
current situation is worse than "one day, some people wrongly trust a
I am "forced" to add "gpgcheck=0" to yum. this mean i trust these
unsigned packages (even if the packages are already signed with an
Do you think it's a good security practise ?
> until they find out
A new argument. The "if ... until ...".
> 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.
Sorry for this "if" argument.
> Not to
> mention again the need for obtaining new keys whenever this happens.
gpg --export --armor key > PUBKEY
ftp ... "put PUBKEY".
Anyway. we will be back temporally to unsigned rpm. No more.
> > 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 ?
This doesn't make any sense.
> 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?
Right now I can *not* trust rawhide rpm.
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
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 ?
> > 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?
Do what you can.
If the key is cracked in 2 mouths I'll enjoy using signed package during
2 mouths. Still better than nothing.
Here is the point. Currently Red Hat does not *want* to do any thing for
It is the decision of Red Hat (btw, Slashdot will be happy to know
this). All these "pseudo technical" arguments are not relevant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20041028/d8b8012b/attachment.bin
More information about the test