Matias F�ciano wrote:
Le jeudi 28 octobre 2004 �5:39 -0300, Alexandre Oliva a �it :
(snip)
On Oct 26, 2004, Matias F�ciano <feliciano.matias@xxxxxxx> 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.
Personally, I do not beleive it is "better than nothing" a false sense
of security is MUCH worse then a true sense of insecurity. A subtle
difference but an incredibly important one.
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 ?
I don't think the server would have to be "a total disaster about
security" for RedHat to choose not to have the packages signed.
The impression I have got, is there is an "issue" with an automated
signing process. However, if they were to use a manual signing process
then this is a resource overhead that they are not prepaired to invest in.
If developers/"other people" within redhat have had problems getting
funding to employ some one to concentrate on bugzilla cleaning out old
bugs, assinging old bugs to relevant developers, etc. I sincearly doubt
they are going to invest the time in employing more "key signing bodies".
If it's the case, why should I even trust unsigned rpm ?
You shouldn't, beyond the "faith" in the fact that the rawhide system
and associated mirrors have been secure for the past "x" months/years
what ever.
The thing I do not fully understand, is the fact that all RPM's from
both "testing" and the proper releases ARE signed, it's just the
bleeding edge development that is not.
The bleeding edge development is just that, development, it is not aimed
at people to have on their desktop/workstation/servers, it is aimed at
testing environments, where things can happily go wrong, with out having
catastrophic consequences. I do not understand why it is of utmost
importance that in this situation you MUST have signed packages.
Even if you are running some rawhide apps on a main workstation/server.
You would have to personaly be VERY carefull with updates, due to the
nature of rawhide, your checks would have to FAR exceed any validation
that the GPG key could give you.
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.
This is true, but it is also up to Redhat (in this situation) to say
"Yes, I want to put our reputation on the line here, and say this is
some thing you can trust". You have no right to expect them to do that.
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?
Come on....
Stop turning around.
All you say is "if ..., if ..., if ...".
Should I continue to flame with other "if ..." ?
^^^^^
If this is what your doing "flaming" then your argument is lost, it's
one thing disagreeing with some one, and trying to sort things out, it's
another thing "just looking for an argument" which I always thought
"flaming" essentially was. That and general abuse, either way, not very
productive.
With unsigned rpm, no "if ..." is needed. I can definitely not trust rpm
package. Period.
Personally I would have said "I can definetely not trust rawhide
packages, signed or other wise". Not just from a security perspective,
but from a stability one as well. GPG signing would have no effect on
this, and personaly i would rather they invested their time and effort
in to the stability, and leave the GPG signing to the official "test"
and "release" packages.
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
Come on...
Right now people are "forced" to _always_ trust unsigned package. The
current situation is worse than "one day, some people wrongly trust a
key".
I am "forced" to add "gpgcheck=0" to yum.
With the latest release of yum (and previously releases) you can specify
GPG checks per repository, so you don't have a problem with all
repositories.
this mean i trust these
unsigned packages (even if the packages are already signed with an
revoked key:-)).
Do you think it's a good security practise ?
Yes, as it reminds you that the person providing you with these packages
are not prepaired to say "these are secure". We get back to false sense
of security v's true sense of insecurity.
And as mentioned before, Redhat is not prepaired to invest the
time/money in to saying "yes we are prepaired to say, you may trust
these if you wish". Personaly, keep the money, and invest it some where
else. But this is of course just my most humblest of opienions :)
<snip>
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.
Don't be obtuse, he was not saying it was a hassle for THEM to create a
new sig, he was refering to the time/effort on the users part to
re-import the new trusted certificate. I remember the hassle it was for
me when their RHN ssl certificate ran out, I would NOT want that hassle
on any regular basis (not that I beleive it would be regular mind).
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.
Erm, no, I don't see what a single person, with quite probably
considerably less "dependants" has to do with this argument.
Unless your honestly trying to compare the importance of your GPG to
that of Redhats?
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?
if, if...
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
signed.
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
the security.
It is the decision of Red Hat (btw, Slashdot will be happy to know
this). All these "pseudo technical" arguments are not relevant.
All this mentioning about Slashdot, it seems almost like a threat, which
I find it VERY hard to beleive, as I don't beleive your that silly.
Mind telling me why you do constantly seem to refer to Slashdot in an
almost threatening manner, along the lines of "if you don't do it, I'm
going to tell slashdot on you, then you'll be sorry".