Re: Secrecy and user trust
- From: Ed Greshko <Ed.Greshko@xxxxxxxxxxx>
- Date: Mon, 08 Sep 2008 10:04:41 +0800
Bill Davidsen wrote:
Ed Greshko wrote:Which may simply be good practice to keep people from asking "what if"
Bill Davidsen wrote:
??? It has? So, what was done? Was the signing key of FedoraIf the public/private key methods employed today are as easy toIt has already been proved to be possible, so discussion of how easy
penetrate and subvert as some seem to be claiming then one has to
question why it hasn't already been done.
it is or way is irrelevant, at least to me.
compromised? Was a replacement key public key generated and
distributed? Were packages signed by the replacement key distributed?
What was "proven".
What was done was to breach security to the extent that new keys are
prudent, and in a way that may not be quantifyable. The action on the
RHEL side indicates that a bogus ssh package may have been
distributed. I encourage you to read the announcements and see if my
interpretation is not correct. A new ssh package was released "just in
case," which is good procedure.
and to satisfy the masses.
If RH/Fedora was to determine that nothing was compromised and that new
keys were not necessary they would have a similar problem in that some
contingent would claim RH/Fedora was lying to them. It could be (note I
am as well informed as you are as to what actually occurred) they are
picking their poison, choosing between 2 bad choices. Damned if they
do, damned if they don't.
You have given zero details (and it has to be detailed and plausible) as
The new public key could be distributed from the master Red Hat"Could"...how?
servers, not from mirrors, which would allow validation of the content
by the validity of the SSL certificate. Once a trusted signature is
available, all other packages, from mirror or torrent, could be
properly validated.
Sorry, I thought you understood how signing works. Once a user has a
trusted "new" public key, it can be used to check the signing on any
new packages. The current distribution has the ability to do this,
limited by the correctness of the public key.
to how you go about distributing and having the key installed. You
don't say how this "fake-trusted" key will interact with previously
signed packages. Along those lines, you've not indicated if this
"fake-trusted" key will replace or coexist with the current public key.
Note that if your system is compromised, this isn't going to be safe,
many things could be faking correct operation. You can go back to the
original install media and start over depending on your evaluation of
exposure. Since Fedora hasn't provided a date before which packages
were known to be trusted, I can't say if any updates past the install
media are safe, but since they are still available I assume that's the
case.
I personally am losing "zero" sleep over this non issue. I personally
While this is inconvenient, it is also as secure as the original, andA whole bunch of people are wringing their hands over nothing. I
not readily vulnerable to attacks in the distribution, since middlemen
are not involved. And once the key is out for a few days, and many
users have it and can quickly compare it to any other key distributed
by other means, then it can be sent out in a more convenient manner if
people really feel the need to trade some security for ease of use.
suppose if you want to continue doing that that is your choice.
Do you personally warrant that there is no problem, and that you will
make good any damage if you're wrong, and that you have the resources
to do so? Didn't think so, so it isn't nothing, it's a low probability
risk which can be reduced by securely distributing the new public key.
don't give a darn if RH/Fedora releases a new public key or not.
--
Why does New Jersey have more toxic waste dumps and California have more
lawyers? New Jersey had first choice.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
- References:
- Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Bill Crawford
- Re: Secrecy and user trust
- From: Les Mikesell
- Re: Secrecy and user trust
- From: Bill Crawford
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: John Aldrich
- Re: Secrecy and user trust
- From: Travis Arnold
- Re: Secrecy and user trust
- From: Anders Karlsson
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Les Mikesell
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Secrecy and user trust
- Prev by Date: Re: Secrecy and user trust
- Next by Date: Re: When the floodgates open ...
- Previous by thread: Re: Secrecy and user trust
- Next by thread: Re: Secrecy and user trust
- Index(es):
Relevant Pages
|