Re: Secrecy and user trust
On 09/09/2008, David Shaw [EMAIL PROTECTED] wrote: I'm one of the GnuPG developers, and as such, a copy of my key is in /usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has gnupg-1.4 installed. It's a key that many (most?) Fedora users already have, and had before this current problem even started. This doesn't mean people should necessarily trust my key, of course, but it does serve as a pretty effective pre-distributed key that can be leveraged for this as its very wide distribution would make it difficult to replace out from under someone without the mischief being very visible (much the same argument that also holds for the new package signing key, of course, except that my key is already widely distributed). As luck has it, I work around half an hour away from the Red Hat Massachusetts office. Now that, seems like a really good idea :o) How about you sign, e.g. Jesse's key (if he's willing)? David Bill -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, Sep 09, 2008 at 12:07:36PM +0100, Bill Crawford wrote: On 09/09/2008, David Shaw [EMAIL PROTECTED] wrote: I'm one of the GnuPG developers, and as such, a copy of my key is in /usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has gnupg-1.4 installed. It's a key that many (most?) Fedora users already have, and had before this current problem even started. This doesn't mean people should necessarily trust my key, of course, but it does serve as a pretty effective pre-distributed key that can be leveraged for this as its very wide distribution would make it difficult to replace out from under someone without the mischief being very visible (much the same argument that also holds for the new package signing key, of course, except that my key is already widely distributed). As luck has it, I work around half an hour away from the Red Hat Massachusetts office. Now that, seems like a really good idea :o) How about you sign, e.g. Jesse's key (if he's willing)? I'm happy to exchange signatures with Jesse or anyone else in the Boston area. To be clear, though: I don't want to give the impression that I think the release plan is not sufficient. I think it's about as good as it can be given the facts of how RPM does key management. Any additional signatures on the package signing key are just a nice bonus for those who want to do additional checks. David -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, Sep 9, 2008 at 7:08 AM, David Shaw [EMAIL PROTECTED] wrote: I'm happy to exchange signatures with Jesse or anyone else in the Boston area. Who said Jesse was in the Boston area? https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00228.html -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On 09/09/2008, Jeff Spaleta [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 7:08 AM, David Shaw [EMAIL PROTECTED] wrote: I'm happy to exchange signatures with Jesse or anyone else in the Boston area. Who said Jesse was in the Boston area? https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00228.html Probably my fault, I merely suggested that if he were able to sign keys, signing Jesse's would provide a short path from there to the new signing keys. Sorry :o) -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Davidsen wrote:
Mike McCarty wrote:
jdow wrote:
If this can be done once in an initial install situation it can be done
again in an update situation using the same mechanism.
One way is to download the stuff from Red Hat's site itself,
and trust that no one has managed to intercept your communications.
Actually you don't need the stuff other than the new key, do you? And
I used a generic noun because I don't know what the stuff is going
to be. It might be a RPM with the new key in it, or just some text,
or I don't know what. Your comment is correct, but perhaps slightly
misdirected because I was vague.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 05, 2008 at 08:17:48PM -0800, Jeff Spaleta wrote: On Fri, Sep 5, 2008 at 5:09 PM, Todd Zullinger [EMAIL PROTECTED] wrote: 1) I don't know where you get the idea that one person that everyone trusts must sign the key for any signatures to be valid. That's not what the web of trust if about. Yes of course.. a chain of trust... i mispoke. Let me be more deliberate. A single signature that everyone ends up trusting through their own personal chains of trust. I don't really think one signature is going to suffice for everyone who cares about this to the point of requesting detected signatures be included with the key in the package. If Jesse signs it and posts that signature to the key server is that going to suffice for everyone who needs signature assurance? Is Jesse really in everyone's web of trust? I don't normally read this list, so pardon the late comment. I feel that posting the new package signing key information far and wide is a fine method to distribute it, and additional signatures on it are not strictly necessary. However, if it would help smooth adoption, I'd be happy to trade signatures with anyone who is in a position to sign the new package signing key (for obvious reasons, I cannot sign it myself). I'm one of the GnuPG developers, and as such, a copy of my key is in /usr/share/doc/gnupg-1.4.x/samplekeys.asc on any system that has gnupg-1.4 installed. It's a key that many (most?) Fedora users already have, and had before this current problem even started. This doesn't mean people should necessarily trust my key, of course, but it does serve as a pretty effective pre-distributed key that can be leveraged for this as its very wide distribution would make it difficult to replace out from under someone without the mischief being very visible (much the same argument that also holds for the new package signing key, of course, except that my key is already widely distributed). As luck has it, I work around half an hour away from the Red Hat Massachusetts office. David pgpZVCDBC9hPA.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: I think you have no concept of public/private encryption or signing. My concept is that if I can fool you into accepting a false public key, I can sign packages with the matching false private key, and when you install the first such package it may (probably will) include evil things of some nature. Do you disagree? Or feel that if I can get you to run one evil package I can't put in a root kit, or rend personal information from your systems, or otherwise attack your system? If you feel that line of attack is not possible do tell me how your concept of encryption and signing prevents it. I thought you were talking real world as opposed to purely hypothetical. I think it is a reasonable real world assumption that some users could have their DNS compromised in a way that would make them pull packages from somewhere other than the official repositories. Can any key trust scenario where they have to obtain a new key protect against installing modified packages? (i.e. assume that the fake key and packages come from the same place(s) pretending to be the official repositories and mirrors). -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Les Mikesell wrote: Ed Greshko wrote: I think you have no concept of public/private encryption or signing. My concept is that if I can fool you into accepting a false public key, I can sign packages with the matching false private key, and when you install the first such package it may (probably will) include evil things of some nature. Do you disagree? Or feel that if I can get you to run one evil package I can't put in a root kit, or rend personal information from your systems, or otherwise attack your system? If you feel that line of attack is not possible do tell me how your concept of encryption and signing prevents it. I thought you were talking real world as opposed to purely hypothetical. I think it is a reasonable real world assumption that some users could have their DNS compromised in a way that would make them pull packages from somewhere other than the official repositories. Can any key trust scenario where they have to obtain a new key protect against installing modified packages? (i.e. assume that the fake key and packages come from the same place(s) pretending to be the official repositories and mirrors). It would be very nice if someone would fully define what they mean by the very vague term fake key. -- It is now 10 p.m. Do you know where Henry Kissinger is? -- Elizabeth Carpenter -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: Ed Greshko wrote: It would be very nice if someone would fully define what they mean by the very vague term fake key. In this context it would one that a user would install that was not the one officially created for the packages in the fedora repository. And along with that, define the method used to distribute said key in a manner that would be oblivious to the all end users. It doesn't have to fool all the end users, just you. Or someone with content worth stealing, or on a network worth penetrating. It has to be oblivious to all end users such that nobody would be able to raise an alarm in a reasonable amount of time. What's a reasonable amount of time? A victim would notice if/when they manage to get an official RPM that the key doesn't match (unless their subverted packages remove the check) and might or might not do something besides import the correct key. If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It's not easy to fool everyone. The question is whether there is a way to start from scratch so you can't fool anyone. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Les Mikesell wrote: Ed Greshko wrote: Ed Greshko wrote: It would be very nice if someone would fully define what they mean by the very vague term fake key. In this context it would one that a user would install that was not the one officially created for the packages in the fedora repository. In other words, you don't know how to define what a fake key isso just avoid it and pretend. And along with that, define the method used to distribute said key in a manner that would be oblivious to the all end users. It doesn't have to fool all the end users, just you. Or someone with content worth stealing, or on a network worth penetrating. So, the target is one system. It has to be oblivious to all end users such that nobody would be able to raise an alarm in a reasonable amount of time. What's a reasonable amount of time? A victim would notice if/when they manage to get an official RPM that the key doesn't match (unless their subverted packages remove the check) and might or might not do something besides import the correct key. More ifs. If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It's not easy to fool everyone. The question is whether there is a way to start from scratch so you can't fool anyone. And, it is even less easy to fool the people whose networks have something worth stealing Why go through the laughingly improbably scenario of attempting to subvert the public/private key infrastructure with the potential need need to simultaneously subvert DNS infrastructure on a single target when there are already other much more simple attack vectors? Oh, and to answer your questionIs there a way to design a system so you can't fool anyone? Absolutely not. -- Do YOU have redeeming social value? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: Ed Greshko wrote: It would be very nice if someone would fully define what they mean by the very vague term fake key. I think most of us would mean a key created by someone not part of the Fedora project, and which is intended to convince users that it is, in fact, a key created and distributed by the Fedora project and used to sign official releases. I speak only for me, of course. And along with that, define the method used to distribute said key in a manner that would be oblivious to the all end users. It has to be oblivious to all end users such that nobody would be able to raise an alarm in a reasonable amount of time. Here we disagree. That's like saying that spam has to fool all readers to be worth doing. If an unauthorized key is used to cause users to install unauthorized software, then it has achieved its purpose. Note that the purpose is yet unclear, and may not exist, but once such an install takes place it could fo any or all of the following: - steal information from a user system - use the user system to run untrusted executables (or any kind) - damage the reputation of Fedora and Red Hat - damage the reputation and user trust of Linux in general for the purpose of reducing use of Linux vs. other operating systems I rate the first two as likely, the third as a possible effect even if unintended, and the last as another possible effect, which might be intended. If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It has already been proved to be possible, so discussion of how easy it is or way is irrelevant, at least to me. The new public key could be distributed from the master Red Hat 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. While this is inconvenient, it is also as secure as the original, and 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. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Davidsen wrote: If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It has already been proved to be possible, so discussion of how easy it is or way is irrelevant, at least to me. ??? It has? So, what was done? Was the signing key of Fedora compromised? Was a replacement key public key generated and distributed? Were packages signed by the replacement key distributed? What was proven. The new public key could be distributed from the master Red Hat 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. Could...how? While this is inconvenient, it is also as secure as the original, and 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. A whole bunch of people are wringing their hands over nothing. I suppose if you want to continue doing that that is your choice. The strange things is that none of this would have come up if the servers of Fedora hadn't been penetrated by some method which nobody on this list is privy to...but can spend endless hours on idle speculation and fear mongering. [WOT comment] I suspect that those fear peddlers, if located in the US, will also be voting for the Republican candidate. :-) -- Some people's mouths work faster than their brains. They say things they haven't even thought of yet. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: It's not easy to fool everyone. The question is whether there is a way to start from scratch so you can't fool anyone. And, it is even less easy to fool the people whose networks have something worth stealing And yet it happens regularly. Why go through the laughingly improbably scenario of attempting to subvert the public/private key infrastructure with the potential need need to simultaneously subvert DNS infrastructure on a single target when there are already other much more simple attack vectors? What's the point of having the key at all if you implicitly trust the delivery mechanism of the RPM packages? -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Les Mikesell wrote: Ed Greshko wrote: It's not easy to fool everyone. The question is whether there is a way to start from scratch so you can't fool anyone. And, it is even less easy to fool the people whose networks have something worth stealing And yet it happens regularly. By a much much more simple approach. Why go through the laughingly improbably scenario of attempting to subvert the public/private key infrastructure with the potential need need to simultaneously subvert DNS infrastructure on a single target when there are already other much more simple attack vectors? What's the point of having the key at all if you implicitly trust the delivery mechanism of the RPM packages? Good approach, answer a question with another question. -- Within a computer, natural language is unnatural. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: What's the point of having the key at all if you implicitly trust the delivery mechanism of the RPM packages? Good approach, answer a question with another question. If you can't say why you need the key in the first place, there isn't much hope of seeing why you need a different reason to trust the key than the content it verifies. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Les Mikesell wrote: Ed Greshko wrote: What's the point of having the key at all if you implicitly trust the delivery mechanism of the RPM packages? Good approach, answer a question with another question. If you can't say why you need the key in the first place, there isn't much hope of seeing why you need a different reason to trust the key than the content it verifies. Bttt... Wong! You are attacking the current system and it is incumbent on you to prove your points. I can't help but to see the irony in that those clamoring for explicit details from the Fedora folks as to the nature, methods, damage inflicted on the Fedora infrastructure are so devoid of details on how their attack vector would work. Their scenario amounts to...generate a fake key pair, fool people in accepting it, sign compromised packages, fool people into downloading and installing them...take over their systems. comic aside There is a much easier way to achieve the above. Trick people into installing Microsoft products. /comic aside. -- The onset and the waning of love make themselves felt in the uneasiness experienced at being alone together. -- Jean de la Bruyere -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: Bill Davidsen wrote: If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It has already been proved to be possible, so discussion of how easy it is or way is irrelevant, at least to me. ??? It has? So, what was done? Was the signing key of Fedora 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. The new public key could be distributed from the master Red Hat 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. Could...how? 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. 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. While this is inconvenient, it is also as secure as the original, and 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. A whole bunch of people are wringing their hands over nothing. I 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. The strange things is that none of this would have come up if the servers of Fedora hadn't been penetrated by some method which nobody on this list is privy to...but can spend endless hours on idle speculation and fear mongering. [WOT comment] I suspect that those fear peddlers, if located in the US, will also be voting for the Republican candidate. :-) -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Davidsen wrote: Ed Greshko wrote: Bill Davidsen wrote: If the public/private key methods employed today are as easy to penetrate and subvert as some seem to be claiming then one has to question why it hasn't already been done. It has already been proved to be possible, so discussion of how easy it is or way is irrelevant, at least to me. ??? It has? So, what was done? Was the signing key of Fedora 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. Which may simply be good practice to keep people from asking what if 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. The new public key could be distributed from the master Red Hat 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. Could...how? 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. You have given zero details (and it has to be detailed and plausible) as 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. While this is inconvenient, it is also as secure as the original, and 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. A whole bunch of people are wringing their hands over nothing. I 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. I personally am losing zero sleep over this non issue. I personally 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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: What's the point of having the key at all if you implicitly trust the delivery mechanism of the RPM packages? Good approach, answer a question with another question. If you can't say why you need the key in the first place, there isn't much hope of seeing why you need a different reason to trust the key than the content it verifies. Bttt... Wong! You are attacking the current system and it is incumbent on you to prove your points. I'm not sure there is a 'current system', but if you mean the plan to use the old key validation for the installation of a package containing the new one and the new repo locations, I don't have a better suggestion. I can't help but to see the irony in that those clamoring for explicit details from the Fedora folks as to the nature, methods, damage inflicted on the Fedora infrastructure are so devoid of details on how their attack vector would work. Their scenario amounts to...generate a fake key pair, fool people in accepting it, sign compromised packages, fool people into downloading and installing them...take over their systems. I'm sure there are people capable of that - but in the planned scenario the same person has to also possess the old signing key. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
From: Anders Karlsson [EMAIL PROTECTED] Sent: Friday, 2008, September 05 13:12 * jdow [EMAIL PROTECTED] [20080905 20:52]: From: Anders Karlsson [EMAIL PROTECTED] Sent: Friday, 2008, September 05 00:50 * jdow [EMAIL PROTECTED] [20080905 08:56]: Suppose I have NO RedHat installed. I have no working computer near me. I want to install Fedora 9. How do I establish the ability to subject the packages to tests for being properly signed, that the key used in the test is correct, and that I am reading and updating from a legitimate mirror? In this event you are likely installing from physical media, which will have the public key on it already. If you do not trust that media - why are you installing from it? Where did I get the media? How do I establish the chain of trust? Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying around. If trust can be established from zero then it can happen again. You had no OS installed - so where did you get the media from? The only thing that matters at this point is whether you do, or not, trust the media you are installing from? If you do - then you will have a good key on the media that will validate updates later. I probably should have said no OS new enough to have been signed. That is why I amplified it to the old copy of RH4 or maybe a really antique Slackware. The idea is that I had something via which I could initialize the bootstrap process - barely. Basically I had to trust that when I logged into download.fedora... that I went to the right place and nobody in the middle was in a position to futz the results. If I was paranoid I could then go to several of the other mirror sites and perform downloads of at least the signatures to see if they were bit copies of each other. I could, with enough work, establish trust. I can, if needed, do that again. Poof - much discussion about nothing new. It's all old well covered territory. Once you have installed the system - the updates you are pulling down will be verified with the key that was on the media - unless you actively go and switch off the gpg checking. If I am actually going to the right mirrors and not a setup of fast flux servers full of malware that will be true. Mu. The Fedora installation media installs repo configs that point to the Fedora projects servers. Your comment indicates that you believe your ISP and the DNS servers you use are compromised. At this point - all bets are off. As others have already pointed out - it's a question of trust. At some point or other - you have to decide what you trust. If you do not trust something, do not use it (and then live with the consequences of that choice). Exactly. This is the point. If I can proceed from zero and establish trust once I can do it again. So I am unclear over what the problem in that regard can be such that it would stall the process of getting rolling again. I can see other items causing a hitch in the gitalong. But I cannot see any means other than trusting my DNS server and the routers between download.fedora.redhat.com and me. If I could trust them once I can trust them again. So the focus of this thread is wrong. It should be more along the lines of How can a company that uses RPM and signed packages arrange to have the packages multiply signed so that both an old obsolete key works and a new key works? THAT is probably not a simple problem. I also suspect it is not something considered in designing rpm itself or the distribution system. This is what the infrastructure team have been working on, and reading the fedora-devel list should give answers to the plans that they have. It would appear that you can only sign a package with a single key at a time. I just tested it. Of course, if you think about it an RPM that will accept multiple signatures would also have to have a proper signature revocation protocol involved. But how does that prevent someone who has compromised the key from issueing a revoke and a new key that is next used to sign a full set of forged RPMs? I imagine the Fedora and Red Hat fellows have their hands seriously full figuring out how they are going to handle the whole process. [snip] If trust can be established once, it can be establised again the same way as many times as needed. So the discussion needs to move to what may be the REAL problem. Can an rpm be signed with multiple keys in any meaningful way so that people pre-update can still grab the key updates and compare files prior to a specific date against the old key while new files compare against the new key. It appears the answer is no. Only one signature at a time. This is one of the problems the infrastructure team have been wrestling with. If THAT can be done it seems like both this discussion and the delay are somewhat spurious, right? It would appear the discussion is not entirely spurious. ;-) Large chunks of the discussion have bypassed the main problems in flights of trust fantasy. They established
Re: Secrecy and user trust
Mike McCarty wrote: jdow wrote: If this can be done once in an initial install situation it can be done again in an update situation using the same mechanism. One way is to download the stuff from Red Hat's site itself, and trust that no one has managed to intercept your communications. Actually you don't need the stuff other than the new key, do you? And the sha1sum (or even sha256sum) of the key and the ISO install image. Once you have that you can trust the mirrors, because even if someone can corrupt a mirror it will be detected. And a list of checksums for all packages released against FC[89] so I can check my archived RPMs against it. That should restore the level of trust present for any previous Fedora release. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: Bill Davidsen wrote: Ed Greshko wrote: Patrick O'Callaghan wrote: The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That is an extremely unlikely possibility as you have to generate a key with the same key id (fingerprint)as the original. Also, you have to determine how to trick all users in to replacing the original. All users? This is like spam email, you only need to succeed in a few cases to get benefit. And distributing the fingerprint assumes you can do that securely as well. I think you have no concept of public/private encryption or signing. My concept is that if I can fool you into accepting a false public key, I can sign packages with the matching false private key, and when you install the first such package it may (probably will) include evil things of some nature. Do you disagree? Or feel that if I can get you to run one evil package I can't put in a root kit, or rend personal information from your systems, or otherwise attack your system? If you feel that line of attack is not possible do tell me how your concept of encryption and signing prevents it. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Sat, Sep 6, 2008 at 1:38 AM, jdow [EMAIL PROTECTED] wrote: From: Anders Karlsson [EMAIL PROTECTED] Sent: Friday, 2008, September 05 13:12 Some 5 posts later . Where are the other critical open source players in all this? Moving forward... At this point a critical missing component is the framework to re-key/ sign the top of a distribution tree/mesh.All vendors might face this same problem and so all vendors have skin in this game. It seems that a collection of face to face credential exchanges and FedX packages containing CDROMs with the public half of key pairs to and from the likes of RH, Fedora, Sun, Cray, Cisco, Dell, Debian, Ubuntu, Scientific Linux, Cern, CentOS, and some.edu sites on multiple continents could go a long way to establish a foundation for a web of trust. Each site can then use their 'top' level keys to sign a set of critical site and individual keys then place the master key in an off line vault. Once the foundation is in place ... more can be done (designed). -- NiftyFedora T o m M i t c h e l l -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
From: Patrick O'Callaghan [EMAIL PROTECTED]
Sent: Thursday, 2008, September 04 06:24
On Wed, 2008-09-03 at 23:42 -0400, Bill Davidsen wrote:
Patrick O'Callaghan wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
hardest of all find a secure way to provide the public part of the
signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some
fake
public key gets distributed, which won't match the private key and
hence
will be instantly detectable.
NAK - if a fake public key were distributed then packages signed with
the fake key would be matched, allowing full access to install crap in
your machine.
True.
And packages signed with any valid redhat key would be
rejected.
Which is what I said. Thus it would be noticed immediately.
The public key really must be distributed in a secure manner.
The standard way is to use certificates, but the update process isn't
set up for this AFAIK, and in any case certificates have to be
signed ... I'm sure suggestions are welcome as to how to accomplish
this.
poc
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
If this can be done once in an initial install situation it can be done
again in an update situation using the same mechanism.
{^_^}
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Jeff Spaleta wrote: If you want to be security paranoid concerning the validity of the new key when it becomes available.. go right ahead.. be paranoid about it. But if you need 3rd parties to sign off on the key before you use it, then you should already have been talking to 3rd parties about doing it for the last Fedora key. Talk to the 3rd parties.. get them to agree to sign the new key and put the detached signatures somewhere public. This is a (hopefully) one-time problem, and therefore it probably doesn't need a perfect, automated, runs-by-itelf solution. And my assumption has been that some people at other repositories do personally know and interact with official people in the Fedora project, and that there is an out-of-band way to pass information to the people at some other repository. Given the nature of the problem, that could mean carrying a CD a hundred miles to meet with someone who is personally known to you from a presentation, etc, etc. It need not be pretty, let's assume that this is a one-time problem. The the other repository creates an RPM, containing not the key, but the RPM created by Fedora, signed appropriately, which in turn contains the new key, and distributes an RPM which installs an RPM, which rpm (the program) now knows how to handle. So instead of signing a key, they create and sign an RPM which itself contains an RPM, which can be manually installed by the cautious. Does that satisfy the technical issues you raised? It's what I had in mind initially, when I proposed a secure means of distributing the information. I know it's ugly, but it's a one night stand. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ed Greshko wrote: Patrick O'Callaghan wrote: The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That is an extremely unlikely possibility as you have to generate a key with the same key id (fingerprint)as the original. Also, you have to determine how to trick all users in to replacing the original. All users? This is like spam email, you only need to succeed in a few cases to get benefit. And distributing the fingerprint assumes you can do that securely as well. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Anders Karlsson wrote:
* jdow [EMAIL PROTECTED] [20080905 08:56]:
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
And here you bring out a good point, most users probably download an
image and create the media themselves. Assuming that you get the sha1sum
from a trusted source *and use it*, you are probably as safe doing that
as buying from a DVD house and using that, or going to an install-a-thon
and having a perfect stranger install software on your system. Having
been the installer a few times, perhaps people could question me,
although no one has.
Once you have installed the system - the updates you are pulling down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
The part about how to distribute the new public key - that is the
thing that the infrastructure team is debating how to best do now.
Nitpicking - it is spelled Red Hat.
If this can be done once in an initial install situation it can be done
again in an update situation using the same mechanism.
{^_^}
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
If you decide not to trust passports, you will simply find it a bit
hard to travel from country to country. If you don't trust the Fedora
key, you'll find it a bit hard to use Fedora.
My view of the Fedora public key is that it is a means to verify the
integrity of the packages coming from the Fedora repo's. That the
package is originating from Fedora, and not from untrusted 3rd
party and that the packages have not been tampered with in
mid-flight. If you don't trust the method by which packages are
downloaded, verified and installed by yum - maybe you'd trust going to
the Fedora download site and grabbing the packages, one by one, and
installing them by hand?
This is a potential solution actually. If you don't trust https:// to
the download section of Fedora - you don't trust Fedora full stop. So
providing a page with the new key, and instruction for what to change
and how, on your system to point at the new repo's should satisfy even
the most paranoid people on this list. As the packages are signed with
the new key, and if you remove the old key - you should be OK. Right?
Actually, I would think that just distributing a single RPM package that
way, containing the new key, would be preferable to getting it through
the yum distribution channel, at least from my point of view. Then the
yum channel would become trusted again.
Yes - it requires manual interaction, it'll be a PITA etc etc ad
nauseum. You have a better, more trustworthy idea? Let's hear it.
Actually I assumed that distribution directly from the Fedora servers
had been impractical or even insecure for some reason, which is why I
have proposed alternative ideas. It crossed my mind that the SSL certs
might have been compromised as well.
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 05, 2008 at 09:59:26 -0400, Bill Davidsen [EMAIL PROTECTED] wrote: This is a (hopefully) one-time problem, and therefore it probably Considering that this has happened twice to large distributions (Debian and Red Hat / Fedora), I think the best we can hope for is rare. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Davidsen wrote: Ed Greshko wrote: Patrick O'Callaghan wrote: The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That is an extremely unlikely possibility as you have to generate a key with the same key id (fingerprint)as the original. Also, you have to determine how to trick all users in to replacing the original. All users? This is like spam email, you only need to succeed in a few cases to get benefit. And distributing the fingerprint assumes you can do that securely as well. I think you have no concept of public/private encryption or signing. -- Behind every great computer sits a skinny little geek. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 5, 2008 at 5:59 AM, Bill Davidsen [EMAIL PROTECTED] wrote: This is a (hopefully) one-time problem, and therefore it probably doesn't need a perfect, automated, runs-by-itelf solution. And my assumption has been that some people at other repositories do personally know and interact with official people in the Fedora project, and that there is an out-of-band way to pass information to the people at some other repository. Your assumption absolutely breaks the trust metric. Assume your wrong. Assume that 3rd party repositories are treated just like any other end-user to Fedora...because they are just other end-users with absolutely no special relationship. Assume that.. because that's how it stands. Given the nature of the problem, that could mean carrying a CD a hundred miles to meet with someone who is personally known to you from a presentation, etc, etc. It need not be pretty, let's assume that this is a one-time problem. Are seriously telling us to wait to distribute keys to people so we can get updates flowing again until someone has flown several hundred miles and done the GPG key signing dance with a 3rd party repo signatory and then flown back? Right now for this one time problem.. that is absolutely not worth it. Nor with that ever be worth it. Especially since every single one of our users were already using a key that didn't rely on a physical face-to-face 3rd party key signing up to this point. -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
From: Anders Karlsson [EMAIL PROTECTED]
Sent: Friday, 2008, September 05 00:50
* jdow [EMAIL PROTECTED] [20080905 08:56]:
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
Where did I get the media? How do I establish the chain of trust?
Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
around. If trust can be established from zero then it can happen
again.
Once you have installed the system - the updates you are pulling down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
If I am actually going to the right mirrors and not a setup of fast
flux servers full of malware that will be true.
The part about how to distribute the new public key - that is the
thing that the infrastructure team is debating how to best do now.
Nitpicking - it is spelled Red Hat.
And I'd be likely installing Fedora these days.
If this can be done once in an initial install situation it can be done
again in an update situation using the same mechanism.
{^_^}
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
Exactly. This is the point. If I can proceed from zero and establish
trust once I can do it again. So I am unclear over what the problem
in that regard can be such that it would stall the process of getting
rolling again.
I can see other items causing a hitch in the gitalong. But I cannot
see any means other than trusting my DNS server and the routers
between download.fedora.redhat.com and me. If I could trust them once
I can trust them again. So the focus of this thread is wrong. It
should be more along the lines of How can a company that uses RPM
and signed packages arrange to have the packages multiply signed so
that both an old obsolete key works and a new key works?
THAT is probably not a simple problem. I also suspect it is not something
considered in designing rpm itself or the distribution system.
If you decide not to trust passports, you will simply find it a bit
hard to travel from country to country. If you don't trust the Fedora
key, you'll find it a bit hard to use Fedora.
My view of the Fedora public key is that it is a means to verify the
integrity of the packages coming from the Fedora repo's. That the
package is originating from Fedora, and not from untrusted 3rd
party and that the packages have not been tampered with in
mid-flight. If you don't trust the method by which packages are
downloaded, verified and installed by yum - maybe you'd trust going to
the Fedora download site and grabbing the packages, one by one, and
installing them by hand?
This is a potential solution actually. If you don't trust https:// to
the download section of Fedora - you don't trust Fedora full stop. So
providing a page with the new key, and instruction for what to change
and how, on your system to point at the new repo's should satisfy even
the most paranoid people on this list. As the packages are signed with
the new key, and if you remove the old key - you should be OK. Right?
Personally I trust the connection between me and Red Hat or me and
Fedora - effectively the same thing. Tampering would have to be quite
comprehensive to keep me fooled for long enough to make it worth the
cracker's efforts. DNS is the easiest hole in the picture. And that
means the main root name servers would have to be changed. (I am being
a bad girl at the moment and am using them directly. I switched pending
hearing that DSLExtreme had completed their update. I've had other things
more pressing to do than change it back.) The second level hole is the
man in the middle attacking me specifically. They ARE out to get me. But
it is nothing personal. It's not me specifically they are targeting. It's
people who present themselves as targets of opportunity. The attack in
this case would have to be so comprehensive that it beggars the imagination
for it to hold up past the first attempted update cycle.
If trust can be established once, it can be establised again the same way
as many times as needed. So the discussion needs to move to what may be
the REAL problem. Can an rpm be signed with multiple keys in any
meaningful way so that people pre-update can still grab the key updates
and compare files prior to a specific date against the old key while new
files compare against the new key.
If THAT can be done it seems like both this discussion and the delay
are somewhat
Re: Secrecy and user trust
Jeff Spaleta wrote, On 09/04/2008 07:22 PM: A really long email, read it here: https://www.redhat.com/archives/fedora-list/2008-September/msg00523.html 0) Although it has been stated that the old fedora key's pass phrase was not used during the exposure, it is intimated that the soft version of the private key was available on the machine and could have been copied by the 'agent'. I, and I believe Bill Bruno, see this as Someone other than authorized Fedora representatives have opportunity to have the pass phrase protected private key, and time to beat on the pass phrase, which means to us the key IS compromised. You and a few others, give the appearance that this means nothing. 1) we agree that the best web of trust is generated when ALL of the parties have physically met and verified each other, i.e., 1 meeting for every public key I have, granted that's not a web. 2) we apparently do not agree that (Assuming I like the way A and C verify the folks they sign for.) if I met A and C and exchanged keys with them, and I get a public key for B that was signed by A and C in an email from B, then I can trust the key to be from B, and after some getting to know B, I might even be sane in accepting a key for D that was signed by B who I have still never met in person. 3) you apparently believe that RPM must be able to directly use these signatures. I believe The extra signatures are for USERS to VERIFY _before_ feeding the DATA of the KEY to RPM. Do I believe in our current climate (crypto education level) that a large percentage of Fedora users will take advantage of this out of band data? NO. Will a reasonable percentage of those who need to use fedora (think support for new hardware or and algorithms not yet in RHEL), and are supposed to use due care|diligence in their job, take advantage of this out of band data? I believe the answer to be YES. 4) So far the only signature on 0X4F2A6FD2 (the old key) that I have _some_ trust in is from 0xDB42A60E. 5) we both agree that a key that is JUST signed by random internet users who were not given the key data securely from the physical machine to be of little to no value. However I may be under the mistaken idea that a few of the folks who are community members, actually work and live very near Red Hat's brick and mortar location. And I could be under the further mistaken idea that a subset of those might actually be willing to make the trip to get the key and begin the web. BTW, I consider many of the Red Hat employees to be part of the Fedora community. 6) you and apparently disagree that OUT OF BAND conformation of data has value. Where in band would be a signature RPM could use. 7) I believe communicating on this list and suggesting that I would like to see out of band data created, counts as 'talking' to some of the 3rd parties I would like to see sign the data. It appears in your message that you do not. 8) to answer the question of Who should be the first to sign the key?: SOME ENTITY IS USING THE NEW KEY TO SIGN NEW PACKAGES... CORRECT? https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html That entity would be the logical choice for _one_ of the first signatures placed on the public key, even if _I_ don't have them as an ultimately trusted source. 9) RE: At best we could maybe get the release engineering people who have direct access to the key to create detached signatures, SNIP Are those people in your web of trust? Not sure, funny thing about a web of trust, a person knows a couple of other folks and they intern know a few folks... Oh and there the, very near the signing machine, persona of [EMAIL PROTECTED] and [EMAIL PROTECTED] which are probably already fairly protected by the policies of the company standing behind them. 10) RE: We don't have a compelling reason to distribute those detached signatures as part of the fedora-release package which will contain the key. Note that the only detached signatures which I ever suggest should be distributed with the fedora-release package were of a Fedora master key persona that does not YET exist. Think about PKI a little bit, is GTE CyberTrust Global Root Serial Number 01:A5 a person? is Akamai Subordinate CA 3 Serial Number 04:00:04:03 a person? is www.redhat.com Serial Number 01:00:00:00:00:01:17:6B:14:92:65 a person? we both know the answer is NO to all the above, and we both know that for the persona Akamai Subordinate CA 3 and the persona GTE CyberTrust Global Root ultimately a (probably trust-able) person enters appropriate data under appropriate rules to make the key available for the encryption system to sign other data. And we both trust it every time we go to https://www.redhat.com/archives/fedora-* I am asking that the fedora project create a 'root' that will be protected appropriately so it can be ultimately trusted into the future, so the PROJECT can vouch for any other NEW keys they HAVE to distribute, so that the
Re: Secrecy and user trust
jdow wrote:
Suppose Fedora generates a new key. They can get it out there by putting
it on their website, in an update RPM, and in plain textual format in
the primary download sites. Then I as a user either trust that or find
I have to take a trip to somebody's office I know is authoritative for
Fedora and get the key on some portable media.
Now, I can also check the key if it is uploaded to all the mirrors the
same way. If I download from a large collection of sites and they all
are bit copies of each other then either the web of deceit is so large
we're all lost anyway or I have a good key.
Judy, you make too much sense. This thread has long outlived any
useful function, I think. What you just suggested is the automatic,
normal, natural thing anyone would have, and probably nearly everyone
here already has, think of. I'd also publish MD5 and/or SHA1 hashes
of the files, but that' a minor tweak.
So the focus of the discussion is silly. Trust is established once, in
some way. Use the same way again that satisfied you in the first place
and get on with life.
{^_^}- betting the real problem is infrastructure.
The only point I saw to the discussion was the first question
posed, which was:
Since Fedora got compromised, we'd like to know
what they run on their servers, and whether we
might ourselves be vulnerable to the same kind of
attack which compromised Fedora in the first place.
If so, we'd like to know what the attack was,
how it succeeded, and how to protect against it.
Recovery seems to me to be obvious and simple. I never saw
(perhaps I missed) an answer to the first question.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 5, 2008 at 11:24 AM, Todd Denniston [EMAIL PROTECTED] wrote: 3) you apparently believe that RPM must be able to directly use these signatures. I believe The extra signatures are for USERS to VERIFY _before_ feeding the DATA of the KEY to RPM. If we are going to wait to distribute the key only after the detached signatures are available for inclusion with the key... yes..i think holding off on the distribution should in fact only be done if we can make use of those signatures client side. if we cant.. there's no point in holding off on distribution. You as an individual are free to hold off on making use of that key until there are a reasonable number of signatures associated with the key as it sits on a public keyserver. 5) we both agree that a key that is JUST signed by random internet users who were not given the key data securely from the physical machine to be of little to no value. However I may be under the mistaken idea that a few of the folks who are community members, actually work and live very near Red Hat's brick and mortar location. And I could be under the further mistaken idea that a subset of those might actually be willing to make the trip to get the key and begin the web. BTW, I consider many of the Red Hat employees to be part of the Fedora community. How many of those people went ahead and signed the previous key as seen on pgp.mit.edu? Which ones of those people are the people you think have physical access to the key as Red Hat employees? All of them? None of them? particular people on that list of signatories? But since you can't reasonably verify that the physically had access to the key.. you still have to trust those individuals that they did. If you want specific individuals that you trust to sign the key... lobby those individuals to sign the key. 6) you and apparently disagree that OUT OF BAND conformation of data has value. Where in band would be a signature RPM could use. At no point have a said that out of band verification doesn't have value. I am saying that delaying the distribution of the key makes no sense if we must rely on the vast majority of users to use out of band verification. If you personally need to wait for out of band verification.. then wait.. don't use the key until you feel comfortable with its validity. If that comfort level never comes for you personally, then so be it. But we aren't going to be flying Release Engineering members all over the world with cdroms in hand to build the web of trust. Well not unless you want to pay for the tickets and their perdiems. 7) I believe communicating on this list and suggesting that I would like to see out of band data created, counts as 'talking' to some of the 3rd parties I would like to see sign the data. It appears in your message that you do not. pgp.mit.edu exists... use it for the out-of-band data all you want. It doesn't really matter whether or not I need that data to exist. What matters is that can we realisticly build a viable web of trust around the key, If you think we can, then go ahead...do it. But if you plan involves flying release engineering people to your doorstep.. I'll make sure I get your the correct addresses to send the plane tickets and the perdiem expense money. 8) to answer the question of Who should be the first to sign the key?: SOME ENTITY IS USING THE NEW KEY TO SIGN NEW PACKAGES... CORRECT? https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html That entity would be the logical choice for _one_ of the first signatures placed on the public key, even if _I_ don't have them as an ultimately trusted source. 9) RE: At best we could maybe get the release engineering people who have direct access to the key to create detached signatures, SNIP Are those people in your web of trust? Not sure, funny thing about a web of trust, a person knows a couple of other folks and they intern know a few folks... Oh and there the, very near the signing machine, persona of [EMAIL PROTECTED] and [EMAIL PROTECTED] which are probably already fairly protected by the policies of the company standing behind them. You'll note that [EMAIL PROTECTED] already signed the previous key as it sits on pgp.mit.edu. Is that entities signature enough for you personally? Then wait for that signature to show up on pgp.mit.edu for the new key after the new key shows up there. Just as Jesse could sign it and place that signature at pgp.mit.edu for you to verify. Is Jesse's personal signature enough for you? is it enough for everyone else who wants to see detached signatures? If you remember the started with a discussion about having livna sign the key...not Fedora release engineering. Why exactly can't you and others wait for which ever signatures you trust to show up on the key as it sits on pgp.mit.edu before you make use of the key? -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe:
Re: Secrecy and user trust
* jdow [EMAIL PROTECTED] [20080905 20:52]: From: Anders Karlsson [EMAIL PROTECTED] Sent: Friday, 2008, September 05 00:50 * jdow [EMAIL PROTECTED] [20080905 08:56]: Suppose I have NO RedHat installed. I have no working computer near me. I want to install Fedora 9. How do I establish the ability to subject the packages to tests for being properly signed, that the key used in the test is correct, and that I am reading and updating from a legitimate mirror? In this event you are likely installing from physical media, which will have the public key on it already. If you do not trust that media - why are you installing from it? Where did I get the media? How do I establish the chain of trust? Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying around. If trust can be established from zero then it can happen again. You had no OS installed - so where did you get the media from? The only thing that matters at this point is whether you do, or not, trust the media you are installing from? If you do - then you will have a good key on the media that will validate updates later. Once you have installed the system - the updates you are pulling down will be verified with the key that was on the media - unless you actively go and switch off the gpg checking. If I am actually going to the right mirrors and not a setup of fast flux servers full of malware that will be true. Mu. The Fedora installation media installs repo configs that point to the Fedora projects servers. Your comment indicates that you believe your ISP and the DNS servers you use are compromised. At this point - all bets are off. As others have already pointed out - it's a question of trust. At some point or other - you have to decide what you trust. If you do not trust something, do not use it (and then live with the consequences of that choice). Exactly. This is the point. If I can proceed from zero and establish trust once I can do it again. So I am unclear over what the problem in that regard can be such that it would stall the process of getting rolling again. I can see other items causing a hitch in the gitalong. But I cannot see any means other than trusting my DNS server and the routers between download.fedora.redhat.com and me. If I could trust them once I can trust them again. So the focus of this thread is wrong. It should be more along the lines of How can a company that uses RPM and signed packages arrange to have the packages multiply signed so that both an old obsolete key works and a new key works? THAT is probably not a simple problem. I also suspect it is not something considered in designing rpm itself or the distribution system. This is what the infrastructure team have been working on, and reading the fedora-devel list should give answers to the plans that they have. It would appear that you can only sign a package with a single key at a time. I just tested it. [snip] If trust can be established once, it can be establised again the same way as many times as needed. So the discussion needs to move to what may be the REAL problem. Can an rpm be signed with multiple keys in any meaningful way so that people pre-update can still grab the key updates and compare files prior to a specific date against the old key while new files compare against the new key. It appears the answer is no. Only one signature at a time. This is one of the problems the infrastructure team have been wrestling with. If THAT can be done it seems like both this discussion and the delay are somewhat spurious, right? It would appear the discussion is not entirely spurious. ;-) /Anders -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Jeff, please excuse me if I'm taking too much out of context from your mail. Jeff Spaleta wrote: GPG keysigning events typically involve face-to-face meetings with some form of official documentation (drivers licenses AND passports typically) which people agree to trust. Those identification documents are crucial elements of GPG signing events... they form a baseline expectation that you are who you say you are. You can't do that sort of thing with the fedora signing key. You can't meet face-to-face to verify its identity, you can't get government issued ID which form the baseline for trust (assuming the ID is of course not falsified). It is quite true that the Fedora key cannot be verified by most of us in the same way that we could verify the key of an individual. But... At best we could maybe get the release engineering people who have direct access to the key to create detached signatures, because they perhaps the only people who do not have to be transmitted the key in order to sign it. This would be excellent. (Though I would hate to ask Jesse to do any more work at this time. :) But now you are left with the problem of trusting their personal keys. Are those people in your web of trust? Yes. From FUDCon Raleigh, I'm a hop away from Jesse's key, as it is signed by Matt Domsch, whom I traded signatures with. That wasn't very hard, and I don't even consider myself to be all that well connected. :) Are you going to meet face to face with them and exchange key signatures? Where possible, definitely. It's a nice excuse to meet some new people and chat a little about geekery. If rpm's key management doesn't handle signed keys..how do you know to trust their keys which signed the signature. Very simple: by using gpg to look at the signatures on a key before importing it. This is precisely how https://fedoraproject.org/keys explains how to verify a key. And on and onall of it outside of the band of rpm. And that's perfectly fine. Yes, it means that it isn't the sole method that all users will use to establish trust in the new keys, but it also isn't a method that takes much time at all (I refer only to having Jesse and other rel-eng folks that were involved in generating the key signing it, not having some other repository's key sign it). You can take a look at the existing Fedora Project key at pgp.mit.edu's search. It's been signed by 3rd parties. So some individuals have signed the key. Do you trust them? Most of them, no. In fact, those that have signed this key are folks whose signatures now hold less weight with me since they were willing to sign a key that they could not possibly have done much meaningful verification on. -jefI should go ahead and sign the old key now, just because it doesn't matterspaleta Hopefully you understand gpg a little better than that and know that signing a key you can't have verified just devalues the weight of your signatures. ;) And, just so it doesn't seem like I'm suggesting we require this as part of the new key release plan, I must say that I do find publishing the key's fingerprint at https://fedoraproject.org/keys to be enough for me to establish trust in it. Adding a sig on the public key servers from Jesse (and/or other rel-eng folks with access to it) would simply be a nice bonus. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ I expected times like this -- but never thought they'd be so bad, so long, and so frequent. -- Demotivators (www.despair.com) pgpbaRljBl7Hz.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 5, 2008 at 2:08 PM, Todd Zullinger [EMAIL PROTECTED] wrote: This would be excellent. (Though I would hate to ask Jesse to do any more work at this time. :) Ah there's the rub. You want him to sign it..but you don't want to ask him to sign it. You want someone like me to order him to sign it. Check that list of signatories again for the old key at pgp.mit.edu. Did Jesse ever sign the old key? If the answer was no... and you trusted that key before...did you really need Jesse to sign the new one to trust it now? Tell me the name of the one person everyone is going to trust when they sign the key. Is everyone going to trust Jesse? Really? Everyone? If that were so, I think Jesse would have been the first suggestionnot livna. Most of them, no. In fact, those that have signed this key are folks whose signatures now hold less weight with me since they were willing to sign a key that they could not possibly have done much meaningful verification on. How do you KNOW they didn't do any meaningful verification on it? How do you KNOW that anyone does meaningful verification on any key before they sign it? In the case of the original fedora signing key did you call up each of those individuals and ask them? You have no idea if they did or did not verify the key adequately. In fact you will have a very hard time getting people to agree on what adequately means for a signing key that is not attached to a human identity. Until you ask them why they were comfortable signing the key you don't know if those individuals are less trustworthy or not..and even then you have to trust their answers. To trust any signature on any key you must make assumptions on the actions of others. What's even funnier is that you just admitted that the case of the Fedora signing key your assumptions concerning other people's actions decrease overall trust. Which is the exact opposite of what you want! You want people to sign the key to increase trust..but you just stated that having lots of people sign the previous key..means you assume they didn't do it right and that you decrease trust in them instead of increasing trust in the key. MADNESS. You just admitted that the signing key is treated differently than a normal gpg key because its not attached to an identity. And that's sort of the point. The web-of-trust concept does not equally apply to keys which are not strongly attached to a verifiable human identity. The web-of-trust is illusionary for keys that are not strongly attached to human identities. -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Jeff Spaleta wrote: Ah there's the rub. You want him to sign it..but you don't want to ask him to sign it. You want someone like me to order him to sign it. Not at all. I did not ever ask you to ask Jesse. In fact, I did ask him about it via IRC shortly after I sent my message. We'll see what he says if he notices the message and has a moment. I'm not terribly worried about it either way. Check that list of signatories again for the old key at pgp.mit.edu. Did Jesse ever sign the old key? If the answer was no... and you trusted that key before...did you really need Jesse to sign the new one to trust it now? As I said in my previous message: And, just so it doesn't seem like I'm suggesting we require this as part of the new key release plan, I must say that I do find publishing the key's fingerprint at https://fedoraproject.org/keys to be enough for me to establish trust in it. Adding a sig on the public key servers from Jesse (and/or other rel-eng folks with access to it) would simply be a nice bonus. Tell me the name of the one person everyone is going to trust when they sign the key. Is everyone going to trust Jesse? Really? Everyone? If that were so, I think Jesse would have been the first suggestionnot livna. 1) I don't know where you get the idea that one person that everyone trusts must sign the key for any signatures to be valid. That's not what the web of trust if about. 2) I never suggested Livna sign the key because I don't believe anyone at Livna has close enough access to the new key to provide any decent verification of the key. In the case of a key that represents an entity, the best place to start is with the individual(s) that have access to the private key. How do you KNOW they didn't do any meaningful verification on it? How do you KNOW that anyone does meaningful verification on any key before they sign it? IMO, the only people that can do meaningful verification of a key such as the fedora signing key are those people that control the secret key. Anyone else is simply taking their word for it (or piling on with an this is the same key I got elsewhere sort of verification, which means nothing to me). To trust any signature on any key you must make assumptions on the actions of others. Right, and I use the past actions of those people as my guide. When someone signs a key that I know they could not have properly verified (since it isn't a human and could not have shown them an sort of ID), then I choose not to trust those people's signatures. What's even funnier is that you just admitted that the case of the Fedora signing key your assumptions concerning other people's actions decrease overall trust. Which is the exact opposite of what you want! You lost me there Jeff. I think you may be reading things into my words that I have not intended. If Jesse Keating or other rel-eng folks with access to the private key sign the key, it holds some weight as they are the folks that can properly verify the key. You want people to sign the key to increase trust..but you just stated that having lots of people sign the previous key..means you assume they didn't do it right and that you decrease trust in them instead of increasing trust in the key. MADNESS. Not madness at all. It's the basics of the OpenPGP trust model. People that sign things without proper verification lose their reputation as good signatories. You just admitted that the signing key is treated differently than a normal gpg key because its not attached to an identity. And that's sort of the point. The web-of-trust concept does not equally apply to keys which are not strongly attached to a verifiable human identity. The web-of-trust is illusionary for keys that are not strongly attached to human identities. And the goal of having one of the humans that generated the key sign it is to bring some level of the traditional web of trust back. Again, with the key fingerprints being published on fedoraproject.org and the keys available in public cvs, I think there are plenty of ways to establish trust in the new keys. If they get signed by Jesse, that's one more way that some of us can use. If they don't, I'm not going to lose any sleep. But no worry, I'm not asking you to do anything, so relax and have a home brew. :) -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ If age imparted wisdom, there wouldn't be any old fools. -- Claudia Young pgp6HgFn3Jzqn.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, Sep 5, 2008 at 5:09 PM, Todd Zullinger [EMAIL PROTECTED] wrote: 1) I don't know where you get the idea that one person that everyone trusts must sign the key for any signatures to be valid. That's not what the web of trust if about. Yes of course.. a chain of trust... i mispoke. Let me be more deliberate. A single signature that everyone ends up trusting through their own personal chains of trust. I don't really think one signature is going to suffice for everyone who cares about this to the point of requesting detected signatures be included with the key in the package. If Jesse signs it and posts that signature to the key server is that going to suffice for everyone who needs signature assurance? Is Jesse really in everyone's web of trust? If Jesse Keating or other rel-eng folks with access to the private key sign the key, it holds some weight as they are the folks that can properly verify the key. It only holds weight if those with signing authority with the key also cross-sign their personal keys using the package signing key. The only way to verify access to the key is to sign with the key. So for this to mean anything at all, we'll need to get the people with signing authority to sign their personal gpg key with the signing key as well as sign the signing key with their personal key then submit both signatures to a public keyserver for verification or you'll not have any verifiable evidence that these people have access to the signing key at all. God forbid you take my word for it that Jesse or anyone else actually has signing authority. Without the cross-signing, you are just taking our collective word for who has access to the key. And there's no point in included the detached sigs unless we also include the personal signing keys and the associated cross-signatures. Again its just all more effectively done via public keyserver operations. If you can wait for it, I can try to make sure that the people with signing authority do the cross-signing with their personal keys and public keyserver publishing. But its not going to happen before the key is pushed out in the fedora-release package. This is probably a good topic for the next scheduled rel-eng meeting or FESCo meeting if it doesn't happen by then. -jef -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Wed, 2008-09-03 at 23:42 -0400, Bill Davidsen wrote: Patrick O'Callaghan wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. True. And packages signed with any valid redhat key would be rejected. Which is what I said. Thus it would be noticed immediately. The public key really must be distributed in a secure manner. The standard way is to use certificates, but the update process isn't set up for this AFAIK, and in any case certificates have to be signed ... I'm sure suggestions are welcome as to how to accomplish this. poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Patrick O'Callaghan wrote: NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. True. Actually I don't understand the paragraph above. It seems to be saying that packages would be signed with a public key which can't be done. So, the person making that statement needs to clarify. And packages signed with any valid redhat key would be rejected. Which is what I said. Thus it would be noticed immediately. No, they would not be rejected as long as you still have Red Hat's public key installed on your system. You can determine what public keys are on your system by rpm -qa gpg-pubkey*. When an rpm is signed it is signed with a private key and information about the corresponding public key is placed in the rpm file. That information is used to retrieve the correct public key for verification. So, as long as you've not deleted it, they will verify. -- You have had a long-term stimulation relative to business. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, 2008-09-04 at 23:12 +0800, Ed Greshko wrote: Patrick O'Callaghan wrote: NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. True. Actually I don't understand the paragraph above. It seems to be saying that packages would be signed with a public key which can't be done. So, the person making that statement needs to clarify. Which is the point I made earlier. And packages signed with any valid redhat key would be rejected. Which is what I said. Thus it would be noticed immediately. No, they would not be rejected as long as you still have Red Hat's public key installed on your system. You can determine what public keys are on your system by rpm -qa gpg-pubkey*. When an rpm is signed it is signed with a private key and information about the corresponding public key is placed in the rpm file. That information is used to retrieve the correct public key for verification. So, as long as you've not deleted it, they will verify. The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 4, 2008 at 8:29 AM, Patrick O'Callaghan [EMAIL PROTECTED] wrote: On Thu, 2008-09-04 at 23:12 +0800, Ed Greshko wrote: Patrick O'Callaghan wrote: NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. True. Actually I don't understand the paragraph above. It seems to be saying that packages would be signed with a public key which can't be done. So, the person making that statement needs to clarify. Which is the point I made earlier. And packages signed with any valid redhat key would be rejected. Which is what I said. Thus it would be noticed immediately. No, they would not be rejected as long as you still have Red Hat's public key installed on your system. You can determine what public keys are on your system by rpm -qa gpg-pubkey*. When an rpm is signed it is signed with a private key and information about the corresponding public key is placed in the rpm file. That information is used to retrieve the correct public key for verification. So, as long as you've not deleted it, they will verify. The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). poc That's what logic says. Things should work If a new private key is created and the corresponding public key distribuited. Doesn't matter how many fake keys I may have. I'll know something is wrong with my updates if I have a pirate public key. ~af -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen [EMAIL PROTECTED] wrote: Patrick O'Callaghan wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. And packages signed with any valid redhat key would be rejected. The public key really must be distributed in a secure manner. Isn't the point of a Public Key to be publicly distributed? The Private Key is what you closely guard against all tampering. ~af -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 04, 2008 at 09:10:14 -0700, Aldo Foot [EMAIL PROTECTED] wrote: On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen [EMAIL PROTECTED] wrote: Patrick O'Callaghan wrote: The public key really must be distributed in a secure manner. Isn't the point of a Public Key to be publicly distributed? Yes, but you need to know that you have the correct public key. So while it doesn't need to be secret, it does need integrity protection. The Private Key is what you closely guard against all tampering. The private key needs to be kept secret. Tampering isn't normally going to be that big of a deal, since you'll notice and then realize it most likely isn't secret any more and change the key pair. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On 04/09/2008, Todd Zullinger [EMAIL PROTECTED] wrote: Since rpm/yum don't have any method to handle a key revocation, this process is harder than it might otherwise be. rpm -e --allmatches gpg-pubkey-$fingerprint not enough? ;o) -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, 2008-09-04 at 17:16 +0100, Bill Crawford wrote: On 04/09/2008, Todd Zullinger [EMAIL PROTECTED] wrote: Since rpm/yum don't have any method to handle a key revocation, this process is harder than it might otherwise be. rpm -e --allmatches gpg-pubkey-$fingerprint not enough? ;o) Revocation doesn't just mean removing a key, it means declaring it to be invalid so it won't be used in the future. poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Aldo Foot wrote, On 09/04/2008 12:10 PM:
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen [EMAIL PROTECTED] wrote:
Patrick O'Callaghan wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
hardest of all find a secure way to provide the public part of the
signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.
NAK - if a fake public key were distributed then packages signed with the
fake key would be matched, allowing full access to install crap in your
machine. And packages signed with any valid redhat key would be rejected.
The public key really must be distributed in a secure manner.
Isn't the point of a Public Key to be publicly distributed?
Only part of the point.
Yes, you can give your Public Key to me, and I can give it to Jim, and Jim can
give it to Jane, and it is still good for it's purpose, which is to validate
that the packet of data sent on the net has not been messed with between being
signed with the private key and arriving at the destination.
But, should Jane be trusting a key given to her by that shady guy Jim to
install random bits of software?
Now if some time earlier Jane and I had met, and exchanged public keys and she
felt that my signature was worthy of trust[1], and I had signed your key
before giving it to Jim, then Jane would have SOME reason to trust that the
key came from _WHO_ it claims to come from instead of some key that Jim
generated to do a MITM attack[2].
The underlying thing Bill was getting at with The public key really must be
distributed in a secure manner is security from an INTEGRITY perspective[3].
Unfortunately, currently most of us only have a very tenuous web of trust back
to any key that that could vouch for the fact that any new key is actually
from the Fedora crew. Many folks will trust the key because the old key
(which has a shadow of doubt over it) will sign it, i.e., they will get it
with yum and because the old key's sig passes what is on their system it will
be installed. Some may trust it because they have a substantial web of trust
to Paul Frields or other Fedora community members who may sign a version of
the public key. Others may trust it because they trust a person who gives it
to them and know that person got it physically from a person at the red hat
building who the second person trusts.
See the suggestion I made a while back[4] for further information about our
current use of cobwebs of trust. My suggestion then was not to take care of
the current situation, it is too late for using it for the current situation,
but it would make any later situations easier to deal with. I still think
Fedora needs a master key made (soon after the current situation is resolved)
so that we can start building at least a cobweb for it.
The Private Key is what you closely guard against all tampering.
~af
[1] http://en.wikipedia.org/wiki/Web_of_trust
[2]
http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Example_of_a_successful_MITM_attack_against_public-key_encryption
[3] http://en.wikipedia.org/wiki/Data_integrity
[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
{something seems bonkers with the way the html is showing the foot notes at
the end of the message, as it looks like foot note 2 is referencing 3-7, but
those seem to have been concatenated onto the same line with foot note 2.}
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Anders Karlsson wrote, On 09/04/2008 01:37 AM:
* Bill Davidsen [EMAIL PROTECTED] [20080904 05:29]:
Patrick O'Callaghan wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
hardest of all find a secure way to provide the public part of the
signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.
NAK - if a fake public key were distributed then packages signed with
the fake key would be matched, allowing full access to install crap in
your machine. And packages signed with any valid redhat key would be
rejected.
The public key really must be distributed in a secure manner.
I am sure the infrastructure team is all ears for a detailed
suggestion on how you believe this should be achieved. And with your
extensive experience in the field - you ought to be able to provide a
detailed plan of action.
It's very easy sitting at the side-line criticising, but actually
*doing* it is much harder.
IMHO - we're at the put up or shut up point with the criticism now.
/Anders
See the suggestion I made a while back[4] for further information about our
current use of cobwebs of trust. My suggestion then was not to take care of
the current situation, it is too late for using it for the current situation,
but it would make any later situations easier to deal with. I still think
Fedora needs a master key made (soon after the current situation is resolved)
so that we can start building at least a cobweb for it.
suggestions for now:
1) sign the new key with the old key... it is the infrastructure team's plan
to do so any way, and many folks will be happy with it.
2) distribute [email | website posting | mass CD mailing] a version of the new
key signed by SEVERAL prominent Fedora and OSS/Free software community
members. (So any conceived conspiracy has to be larger, and more likely found
out :)
[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
{something seems bonkers with the way the html is showing the footnotes at
the end of the message, as it looks like footnote 2 is referencing 3-7, but
those seem to have been concatenated onto the same line with footnote 2.}
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Tim wrote: I'm not sure whether *also* having the keys on other sites is so bad. If you take it like the GPG model - countersigning and cross-checking through other sources that you also trust. If Livna, ATRPMs, and a few other usual repos had the same Fedora public key, you'd be more confident that the key you got from what you think is a real Fedora mirror, is the right one. There certainly isn't anything stopping others from singing the Fedora key (as can be seen by the number of signatures already¹. I do wonder how many of those folks have met with the holder of the secret part of the Fedora key for verifying the fingerprint. Another issue with adding signatures to the key is that rpm has no ability to check those signatures (I'm not even sure if it imports a key with multiple signatures properly). Now that rpm is being more actively developed and the lack of a key revocation feature has been felt, maybe someone will submit some patches to add such features². ¹ http://subkeys.pgp.net:11371/pks/lookup?search=0x4F2A6FD2fingerprint=onop=vindex ² http://wiki.rpm.org/Contribute -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ So its hurry! Hurry! Step right up, it's a matter of life or death The sun is going down and the moon is just holding its breath. pgpr8o7M9r4ra.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Tim wrote: Bill Davidsen: Suggestion: since the livna key is still secure (AFAIK) let them distribute the new Fedora key and sign the RPM. Kevin Fenzi: That was suggested before, but it's not a great solution for several reasons: Not everyone has livna enabled. Having one repo publish keys for another seems wrong, especially when they are not officially connected. I'm not sure whether *also* having the keys on other sites is so bad. I give up, politics as usual. If a proposed solution isn't perfect it isn't good enough, so trust us. If you take it like the GPG model - countersigning and cross-checking through other sources that you also trust. If Livna, ATRPMs, and a few other usual repos had the same Fedora public key, you'd be more confident that the key you got from what you think is a real Fedora mirror, is the right one. Well said. Common sense. The political answer is wait until new improved RPM comes out. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Anders Karlsson wrote: * Bill Davidsen [EMAIL PROTECTED] [20080904 05:29]: Patrick O'Callaghan wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. And packages signed with any valid redhat key would be rejected. The public key really must be distributed in a secure manner. I am sure the infrastructure team is all ears for a detailed suggestion on how you believe this should be achieved. And with your extensive experience in the field - you ought to be able to provide a detailed plan of action. It's very easy sitting at the side-line criticising, but actually *doing* it is much harder. Which is why I made a concrete and readily implemented suggestion that the new key be distributed by livna (and/or atrpm, etc) signed with a key which is believed to be secure, preferably several of them. No one claimed that it couldn't be done, or even that it wouldn't work, just that it was bad politics to have another repo sign. IMHO - we're at the put up or shut up point with the criticism now. I offered a technically viable solution for new key signing and distribution, it was rejected for political reasons. Sorry you feel that's criticism. /Anders -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Patrick O'Callaghan wrote: On Thu, 2008-09-04 at 23:12 +0800, Ed Greshko wrote: Patrick O'Callaghan wrote: NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. True. Actually I don't understand the paragraph above. It seems to be saying that packages would be signed with a public key which can't be done. So, the person making that statement needs to clarify. Which is the point I made earlier. And packages signed with any valid redhat key would be rejected. Which is what I said. Thus it would be noticed immediately. No, they would not be rejected as long as you still have Red Hat's public key installed on your system. You can determine what public keys are on your system by rpm -qa gpg-pubkey*. When an rpm is signed it is signed with a private key and information about the corresponding public key is placed in the rpm file. That information is used to retrieve the correct public key for verification. So, as long as you've not deleted it, they will verify. The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That's exactly right, and why the public key should be as trustworthy as possible, because once you accept a single trojanned package you may either suffer damage immediately, or have some part of the next time you did an update fail. Imagine a slight change to updated so it never tells you there *is* an update. I am making the point that an improved method of checking the new key is desirable, technically possible, and that a false package could cause problems in a very short time, and might be able to hide thereafter. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 4, 2008 at 12:58 PM, Bill Davidsen [EMAIL PROTECTED] wrote: No one claimed that it couldn't be done, or even that it wouldn't work, just that it was bad politics to have another repo sign. Has anyone with the authority to sign with the livna key come forward and said they'd be willing to do it? Have you tested recently rpm's ability to import keys that have been signed versus bare keys? -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 04, 2008 at 12:52:51 -0800, Jeff Spaleta [EMAIL PROTECTED] wrote: On Thu, Sep 4, 2008 at 12:58 PM, Bill Davidsen [EMAIL PROTECTED] wrote: No one claimed that it couldn't be done, or even that it wouldn't work, just that it was bad politics to have another repo sign. Has anyone with the authority to sign with the livna key come forward and said they'd be willing to do it? Have you tested recently rpm's ability to import keys that have been signed versus bare keys? Is that what my problem was yesterday? I filed a bugzilla about a key I was trying to import (mostly about the error message not being very helpful) and got feedback that the key was importable by the rawhide rpm. (Which I hope to test late tonight or tomorrow.) -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 4, 2008 at 12:57 PM, Bruno Wolff III [EMAIL PROTECTED] wrote: Is that what my problem was yesterday? I filed a bugzilla about a key I was trying to import (mostly about the error message not being very helpful) and got feedback that the key was importable by the rawhide rpm. (Which I hope to test late tonight or tomorrow.) Was it? I not completely up to speed on rpm's capabilities. But I think it was a problem at one point but i may not be remembering correctly. You shouldn't trust me. I think it would be wisest for the people who are suggesting that signed keys be used... go ahead and test that rpm can import them on F8 and F9 systems. If it doesn't work.. its a non-starter from a technical perspective and we need to move on. -jef -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Jeff Spaleta wrote, On 09/04/2008 05:05 PM: On Thu, Sep 4, 2008 at 12:57 PM, Bruno Wolff III [EMAIL PROTECTED] wrote: Is that what my problem was yesterday? I filed a bugzilla about a key I was trying to import (mostly about the error message not being very helpful) and got feedback that the key was importable by the rawhide rpm. (Which I hope to test late tonight or tomorrow.) Was it? I not completely up to speed on rpm's capabilities. But I think it was a problem at one point but i may not be remembering correctly. You shouldn't trust me. I think it would be wisest for the people who are suggesting that signed keys be used... go ahead and test that rpm can import them on F8 and F9 systems. If it doesn't work.. its a non-starter from a technical perspective and we need to move on. -jef Although rpm may not have the ability to use keys with signatures in them, this does NOT make it a non-starter. PGP|GPG can generate DETACHED signatures[1], which can be used with the public key file out side of rpm's band to verify the new key. [1] gpg --help 21 |grep detached signature -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Thu, Sep 4, 2008 at 1:59 PM, Todd Denniston [EMAIL PROTECTED] wrote: Although rpm may not have the ability to use keys with signatures in them, this does NOT make it a non-starter. It's going to impact in what fashion we distribute the key. if we can'd distribute the signed key and have it import as expected...then there's no point in attempting to distribute a signed key. Do all this 3rd party signing stuff on a public key server. PGP|GPG can generate DETACHED signatures[1], which can be used with the public key file out side of rpm's band to verify the new key. what is stopping any 3rd party from generating detached signatures right now? What was stopping them from doing it on the last key? If you or I or livna or anyone else wanted to create a detached signature on the Fedora key..we could have..and we'd still be we are right now dealing with how to distribute a new key. The extra signatures do not materially help because we do not have a technical mechanism to make use of those signatures as part of the client side package management operations. Look at the existing Fedora key as it sits on the pgp.mit.edu key server. People have signed it there. We have no way to make use of that information client side. But you can... anyone can... just as anyone can push a new signature against that existing key. Nor do we have a special mechanism which lets 3rd parties verify the key's validity that individual end-users do not have. And this last one is key. Having livna, or myself, or you.. sign a key that was transmitted electronically to us doesn't do squat in terms of increasing its trustability. if anything it distorts the web of trust because we've signed something we can't tangible verify. Distributing the detached signatures as part of the fedora-release package with a bare importable key..when we aren't making use of those detached signatures as part of the packaging process..at all...seems...futile to me. We don't have a mechanism which enforces the existence of signatures on the keys in the rpm keyring. There is no trust metric exposed by which you can rank the trustability of a particular key when using it. If you want 3rd parties to sign the Fedora packaging signing key... talk to the 3rd parties about signing the new key as soon as its made available and placing those detached signatures on sites they control or a public key server so you can verify the detached signatures when Fedora releases the bare key with 3rd parties you personally trust. If you want to be security paranoid concerning the validity of the new key when it becomes available.. go right ahead.. be paranoid about it. But if you need 3rd parties to sign off on the key before you use it, then you should already have been talking to 3rd parties about doing it for the last Fedora key. Talk to the 3rd parties.. get them to agree to sign the new key and put the detached signatures somewhere public. If you can convince them to actually sign the key, since they have the exact same problem that you have.. they have to be transmitted the key in order for them to sign it. So they have to trust the transmission of the key... just as you do. There is a basic logic fallacy here, some 3rd party has to initially trust the key. If you personally aren't going to be that 3rd party...then why would you expect another 3rd party to be the first? If you are going to be paranoid about verifying the transmission of the new key to yourself... then you have to be equally paranoid about how the signatories of that key were transmitted the key before they signed it. GPG keysigning events typically involve face-to-face meetings with some form of official documentation (drivers licenses AND passports typically) which people agree to trust. Those identification documents are crucial elements of GPG signing events... they form a baseline expectation that you are who you say you are. You can't do that sort of thing with the fedora signing key. You can't meet face-to-face to verify its identity, you can't get government issued ID which form the baseline for trust (assuming the ID is of course not falsified). At best we could maybe get the release engineering people who have direct access to the key to create detached signatures, because they perhaps the only people who do not have to be transmitted the key in order to sign it. But now you are left with the problem of trusting their personal keys. Are those people in your web of trust? Are you going to meet face to face with them and exchange key signatures? If rpm's key management doesn't handle signed keys..how do you know to trust their keys which signed the signature. And on and onall of it outside of the band of rpm. We don't have a compelling reason to distribute those detached signatures as part of the fedora-release package which will contain the key. We don't have a way to make use of them, and if you have to go out of band to verify the key...then go out of band. All
Re: Secrecy and user trust
Patrick O'Callaghan wrote: The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That is an extremely unlikely possibility as you have to generate a key with the same key id (fingerprint)as the original. Also, you have to determine how to trick all users in to replacing the original. -- Necessity is a mother. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Fri, 2008-09-05 at 08:02 +0800, Ed Greshko wrote: Patrick O'Callaghan wrote: The hypothetical scenario being discussed is that you have already replaced the former (good but now possibly suspect) public key with a spurious new one. If that were to happen, you would be in danger of accepting trojanned packages signed with this new fake key. My point is that you would also *reject* packages signed with the new good key, and this would be noticed very quickly (basically the next time you did an update). That is an extremely unlikely possibility as you have to generate a key with the same key id (fingerprint)as the original. Also, you have to determine how to trick all users in to replacing the original. Exactly. That's what I've been saying all along. I don't understand what the disagreement is about, if anything. poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Anders Karlsson wrote: * Travis Arnold [EMAIL PROTECTED] [20080902 22:52]: [drivel snipped] Hey I am currently downloading the ISO dvd to install after I finish my day's lessons, is this not a good idea to do? The word from the Fedora folks on Aug 14th was - don't update until further notice. Since then, they have - IIRC - said it's safe to do so. The ISO's should be safe, as well as the packages that you can update to from the servers. New updates should start rolling once they have resigned everything. Distributing that will be quite slow, since they need to (a) validate, then (b) sign, then (c) distribute out-of-band to mirrors, and then hardest of all find a secure way to provide the public part of the signing key. Obviously you don't risk letting someone slip in a bogus NEW fake key and go around on this again. Suggestion: since the livna key is still secure (AFAIK) let them distribute the new Fedora key and sign the RPM. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Ralf Corsepius wrote: On Tue, 2008-09-02 at 17:27 +0100, Bill Crawford wrote: On 02/09/2008, Bill Davidsen [EMAIL PROTECTED] wrote: If there is a known date before which packages can be trusted, that should be said. Users who lag the cutting edge will be reassured. People won't have to be checking security logs for a decade if the problem is more recent. People on distributions older than FC8 which are not maintained should be told if the problem goes back that far. The infrastructure is up and running. FC-10/rawhides's infrastructure seems up and running. FC-9 and FC-8's cvs and buildsys are up again, but no pushes are happening. In a nutshell, this means FC-8/F-9's infrastructure is effectively down. I tried to update a clean install (see below) and got metadata but no packages. That may have just been a bad time, or even the old packages may be unavailable. Fortunately for me I have every RPM I ever got, back to FC4, and the FC1 KRUD relase as well. Unfortunately for me I'm not sure I trust them. I wanted to D/L the current and compare with the old I already have, and see if anything has changes. Note on not downloading over and over... if you have multiple systems, you can set one to keep the RPMs after use, then copy them to the same location in /var/cache/yum in another machine. Just the RPMs, not the metadata. This allows the metadata to come in from the network and the RPMs to be local, helpful on a machine with slow network. For no network at all, the rpm freshen command will update only what you have installed. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Wed, Sep 03, 2008 at 14:12:47 -0430, Patrick O'Callaghan [EMAIL PROTECTED] wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. You still need a secure channel. What is changed is that it only needs protection for integrity, not eavesdropping. The worst case is actually a man in the middle attack. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Kevin Fenzi wrote: On Wed, 03 Sep 2008 10:30:39 -0400 [EMAIL PROTECTED] (Bill Davidsen) wrote: [...] and then hardest of all find a secure way to provide the public part of the signing key. Obviously you don't risk letting someone slip in a bogus NEW fake key and go around on this again. Indeed. The proposed plan (that has since had a few modifications): http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html Since rpm/yum don't have any method to handle a key revocation, this process is harder than it might otherwise be. As I understand the plan currently, the new key will be included in an updated fedora-release package that will be signed by the old key. This will make the change as transparent as possible for most users and since it is not believed that the old key is compromised at this time, it is reasonably secure. (Insert various caveats regarding the meaning of reasonably secure and not believed ... compromised ... as needed.) I presume that the new key's fingerprint and other details will be added to https://fedoraproject.org/keys sometime soon and that can be used by those who want a bit more verification of the new key before trusting it. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Sanity is the trademark of a weak mind. -- Mark Harrold pgpXUKhgqSZUA.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Patrick O'Callaghan wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. And packages signed with any valid redhat key would be rejected. The public key really must be distributed in a secure manner. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
* Bill Davidsen [EMAIL PROTECTED] [20080904 05:29]: Patrick O'Callaghan wrote: On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote: hardest of all find a secure way to provide the public part of the signing key The whole point about asymmetric encryption is that you don't need a secure distribution channel. The worst that can happen is that some fake public key gets distributed, which won't match the private key and hence will be instantly detectable. NAK - if a fake public key were distributed then packages signed with the fake key would be matched, allowing full access to install crap in your machine. And packages signed with any valid redhat key would be rejected. The public key really must be distributed in a secure manner. I am sure the infrastructure team is all ears for a detailed suggestion on how you believe this should be achieved. And with your extensive experience in the field - you ought to be able to provide a detailed plan of action. It's very easy sitting at the side-line criticising, but actually *doing* it is much harder. IMHO - we're at the put up or shut up point with the criticism now. /Anders -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On 02/09/2008, Bill Davidsen [EMAIL PROTECTED] wrote: If there is a known date before which packages can be trusted, that should be said. Users who lag the cutting edge will be reassured. People won't have to be checking security logs for a decade if the problem is more recent. People on distributions older than FC8 which are not maintained should be told if the problem goes back that far. The infrastructure is up and running. We have been told that new updates will be made available as soon as they (and existing content) have been signed with a new key. They have announced that they do not believe there is any risk from existing content. What do you want to know? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Crawford wrote: On 02/09/2008, Bill Davidsen [EMAIL PROTECTED] wrote: If there is a known date before which packages can be trusted, that should be said. Users who lag the cutting edge will be reassured. People won't have to be checking security logs for a decade if the problem is more recent. People on distributions older than FC8 which are not maintained should be told if the problem goes back that far. The infrastructure is up and running. We have been told that new updates will be made available as soon as they (and existing content) have been signed with a new key. They have announced that they do not believe there is any risk from existing content. What do you want to know? When and how did the intrusion occur? How was it initially detected? -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On 02/09/2008, Les Mikesell [EMAIL PROTECTED] wrote: When and how did the intrusion occur? How was it initially detected? *shrug* I don't actually need to know, so I'm not making a fuss. I suspect, as has been hinted at here multiple times, there may be legal reasons why they haven't provided you with some of the details you would like to see. I'd suggest re-reading the announcement that Paul W. Frields sent out (url below) and then, should you really, really feel the need to know more, I'd suggest you contact whoever at the Fedora Project you pay for support, complaining about your SLA not being met ;o) http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Crawford wrote: When and how did the intrusion occur? How was it initially detected? *shrug* I don't actually need to know, so I'm not making a fuss. Everyone needs to whether or not they are at risk with the same vulnerability and how to detect it. I suspect, as has been hinted at here multiple times, there may be legal reasons why they haven't provided you with some of the details you would like to see. I'd suggest re-reading the announcement that Paul W. Frields sent out (url below) and then, should you really, really feel the need to know more, I'd suggest you contact whoever at the Fedora Project you pay for support, complaining about your SLA not being met ;o) http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html This is about community, not SLA's. Communities are easily alienated when not included in needed communications. I'd suggest reconsidering whether your community is important or not. -- Les Mikesell [EMAIL PROTECTED] -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
Bill Crawford wrote:
On 02/09/2008, Les Mikesell [EMAIL PROTECTED] wrote:
When and how did the intrusion occur? How was it initially detected?
*shrug*
I don't actually need to know, so I'm not making a fuss.
I suspect, as has been hinted at here multiple times, there may be
legal reasons why they haven't provided you with some of the details
you would like to see.
As noted, the detail I would have liked was to know if this was a
failure of system security or a failure of misplaced trust. If there is
a hole in their server system security it's likely to be in ours as well.
And if someone could say with certainty that packages downloaded before
{date} were safe, it would be more reassuring than there is little
risk to Fedora users who wish to install or upgrade signed Fedora
packages. If the start date of the problem is known, that would be
really good information for people who keep a local repository and don't
have to upgrade every new install totally over the network.
I'd suggest re-reading the announcement that Paul W. Frields sent out
(url below) and then, should you really, really feel the need to know
more, I'd suggest you contact whoever at the Fedora Project you pay
for support, complaining about your SLA not being met ;o)
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html
I felt the need to spend some of my three day holiday reinstalling
servers with another distribution, when knowing the start date of the
problem would have let me make an intelligent choice. Saying was
quickly discovered doesn't tell me if it was minutes, hours, or months.
What I was looking for was a safe if loaded before date.
So yes, I really, really felt the need to know more.
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, 2008-09-02 at 17:51 +0100, Bill Crawford wrote: On 02/09/2008, Les Mikesell [EMAIL PROTECTED] wrote: When and how did the intrusion occur? How was it initially detected? *shrug* I don't actually need to know, so I'm not making a fuss. I disagree. I think we do need to know. What I don't worry about is knowing *immediately*. I'm willing to cut the Fedora devs some slack as it may be an ongoing situation and I don't doubt they are fully occupied in pushing updates, signing packages etc. However I think we have a right to expect a much more detailed report on this in due course (no, I don't know how long that is). poc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
* Les Mikesell [EMAIL PROTECTED] [20080902 19:15]: Bill Crawford wrote: When and how did the intrusion occur? How was it initially detected? *shrug* I don't actually need to know, so I'm not making a fuss. Everyone needs to whether or not they are at risk with the same vulnerability and how to detect it. Les, This has been gone over more than once, and you have been involved in the discussions. You already know what has been said, so there is really no need to rehash it again. I suspect, as has been hinted at here multiple times, there may be legal reasons why they haven't provided you with some of the details you would like to see. I'd suggest re-reading the announcement that Paul W. Frields sent out (url below) and then, should you really, really feel the need to know more, I'd suggest you contact whoever at the Fedora Project you pay for support, complaining about your SLA not being met ;o) http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html This is about community, not SLA's. Communities are easily alienated when not included in needed communications. I'd suggest reconsidering whether your community is important or not. I keep hearing this statement from a small but rather vocal selection of people. This selection of people has a rather large overlap with another small selection of people who is keen on complaining about a lot of other things about the Fedora project. Follow announce-list, when there is news, it'll be posted there. /Anders -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
John Aldrich wrote:
Quoting Bill Davidsen [EMAIL PROTECTED]:
As noted, the detail I would have liked was to know if this was a
failure of system security or a failure of misplaced trust. If there is
a hole in their server system security it's likely to be in ours as
well.
And if someone could say with certainty that packages downloaded before
{date} were safe, it would be more reassuring than there is little
risk to Fedora users who wish to install or upgrade signed Fedora
packages. If the start date of the problem is known, that would be
really good information for people who keep a local repository and
don't have to upgrade every new install totally over the network.
Well, I know someone on this list said I should feel safe in upgrading
my F6 box to F9. I don't know if that answers your questions or not.
That being said, I think I'll wait until F10 or until fresh ISO images
come out. Despite the fact that my only installation is a single,
personal box, I don't want to risk getting hacked because someone *may*
have gotten some bogus packages into the system and/or compromised the
signing key for Fedora.
Unless/until someone from Fedora says It is safe to install Fedora 9
from the original ISO images distributed when F9 was released I am not
going to trust that they are safe.
Hey I am currently downloading the ISO dvd to install after I finish my
day's lessons, is this not a good idea to do?
Travis
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, 02 Sep 2008 16:52:08 -0400 [EMAIL PROTECTED] (Travis Arnold) wrote: John Aldrich wrote: ...snipp... Unless/until someone from Fedora says It is safe to install Fedora 9 from the original ISO images distributed when F9 was released I am not going to trust that they are safe. Hey I am currently downloading the ISO dvd to install after I finish my day's lessons, is this not a good idea to do? From: http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages. This pretty heavily implies to me that the iso images are fine as shipped when F9 was released. Do you expect the project to announce each item that is ok? Instead, please expect that anything that was bad/wrong/shouldn't be used would be heavily announced and removed from download. Also, you might consider using the fedora unity respin and save yourself some time downloading updates: http://spins.fedoraunity.org/spins Travis kevin signature.asc Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, 2008-09-02 at 17:27 +0100, Bill Crawford wrote: On 02/09/2008, Bill Davidsen [EMAIL PROTECTED] wrote: If there is a known date before which packages can be trusted, that should be said. Users who lag the cutting edge will be reassured. People won't have to be checking security logs for a decade if the problem is more recent. People on distributions older than FC8 which are not maintained should be told if the problem goes back that far. The infrastructure is up and running. FC-10/rawhides's infrastructure seems up and running. FC-9 and FC-8's cvs and buildsys are up again, but no pushes are happening. In a nutshell, this means FC-8/F-9's infrastructure is effectively down. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Secrecy and user trust
On Tue, Sep 2, 2008 at 2:04 PM, Anders Karlsson [EMAIL PROTECTED] wrote: * Travis Arnold [EMAIL PROTECTED] [20080902 22:52]: [drivel snipped] Hey I am currently downloading the ISO dvd to install after I finish my day's lessons, is this not a good idea to do? The word from the Fedora folks on Aug 14th was - don't update until further notice. Since then, they have - IIRC - said it's safe to do so. The ISO's should be safe, as well as the packages that you can update to from the servers. New updates should start rolling once they have resigned everything. /Anders For once I'm glad I've not updated my system in the last few days; and I won't for quite a few more. ~af -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
