On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: > 2008/8/29 Axel Thimm <Axel.Thimm@xxxxxxxxxx>: > > > If ATM the key is considered stolen, the users need to stop using the > > key immediately anyway. Issuing a new package signed with the old key > > is just keeping the racing window open. > > I don't think that the key is considered stolen atm. What has happened > (to my limited knowledge) is that the machine storing the (encrypted) > key was compromised, however, during the window of the compromise, the > passphrase to the key was not entered. Therefore, what "they" have is > an encrypted key that "they" don't know the passphrase to. > > > IOW the users do need to acknowledge the change of keys (like you do > > when an ssh host key has been changed). Otherwise any user with an F9 > > DVD is susceptible for being spoofed anyway, we won't be able to cure > > that: The people that stole the key just need to get control over a > > Let's assume that the key *was* actually compromised, passhphrase and > all. With the current plan, without additional intermediate > compromises (say the user's DNS server), I still don't see the risk. > We're using MM to redirect ALL requests for the old repo location to > mirrors that we have ultimate control over. I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is. One of them is mine, and for what I know I could be the one having stolen the key injecting bad packages right now. Or maybe the key & passphrase show up on some hacker forums and anyone and his cat will be able to spoof us up. Also most security breaches actually happen with insider knowledge, so I could have registered a mirror just for trojaning the users that would be redirected to me. We'll see what the investigation will turn up, maybe we will see former Fedorians exercising criminal skills alongside packaging. > Therefore, "they" can setup a mirror and sign stuff with the old > key, but it won't be used by the default config. Why not? See above. Maybe new mirrors since the incident have not been allowed to registered, but what if the intruder registered them beforehand? > Which brings up an interesting question in my mind - how are we > ensuring that the old key is actually removed from user machines and > no longer trusted? I remember something about the new fedora-release > obsoleting the old key, but that was seen as not something we could > do. Why not? I also don't see a reason. Removing a key in %pre or %post is not an issue with rpm >= 4.3 (maybe even earlier). > > The only way to not have this happen is to loudly announce that the > > old key is being revoked and content signed with it needs to be cast > > away and replaced. > > That's pretty much what's happening. The issue that we have with a > clean transistion is that the PackageKit that was included in Fedora 9 > GA did not have the ability to import new keys, and we want this > transition to be as painless as possible for our users. Possibly better to have a non-painless and non-automatic transition, so F9 DVD owners don't get into any bad mirrors. > > All this assumes that there is real suspicion that the old key has > > been stolen, but the new key procedure does indicate that > > case. Otherwise, if it is just being done for good measure, then it's > > a bad step. > > Why is it bad to exercise an abundance of caution in this situation? Because there is not really such a thing as a grey zone in security assertions, it is either a security issue (of a certain gravity) or not. Either the key is considered compromized and one needs to do the full program, or it is reasonably considered safe (by a brute-force safe passphrase and really assuming the passphrase has not been lost to the intruder as well), in which case no steps are needed, but phasing it out before the computing power gets accessible to break it (e.g. new keys for F10 upwards). The current program looks like a mix of assuming "safe" (so the old key can be used for signing new packages, even if it just a few) and assuming "compromised" needing a resiging of all content. But actually w/o knowing the details and the outcome of the current investigation one can't really say much. It just looks like contradicting security measures (assuming "safe" vs "compromized"). [1] # lynx --dump 'http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=x86_64' # repo = fedora-9 arch = x86_64 Using preferred netblock Using Internet2 countr y = DE country = RO country = GB country = PL country = EE country = IT country = ES country = MD country = IL country = FR country = FI country = NL country = NO country = CH country = CZ country = SE country = DK country = LV country = IS country = AT country = IE http://mirror.atrpms.net/fedora/linux/releases/9/Everything/x86_64/os http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/releases/9/ Everything/x86_64/os http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/linux/releases/9/ Everything/x86_64/os http://ftp.stw-bonn.de/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.uni-bayreuth.de/linux/fedora/linux/releases/9/Everything/x86_64/os http://ftp.uni-koeln.de/mirrors/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.sunet.se/pub/Linux/distributions/fedora/linux/releases/9/Everything/x 86_64/os http://ftp.rhnet.is/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/release s/9/Everything/x86_64/os http://ftp.cica.es/fedora/linux/releases/9/Everything/x86_64/os http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/linux/releases/9/Everything /x86_64/os http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/9/E verything/x86_64/os http://ftp.sh.cvut.cz/MIRRORS/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.rediris.es/mirror/fedora-redhat/releases/9/Everything/x86_64/os ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everything/ x86_64/os http://ftp.SURFnet.nl/pub/os/Linux/distr/fedora/linux/releases/9/Everything/x86 _64/os http://ftp.lip6.fr/ftp/pub/linux/distributions/fedora/releases/9/Everything/x86 _64/os http://ftp.crc.dk/fedora/linux/releases/9/Everything/x86_64/os http://fr2.rpmfind.net/linux/fedora/releases/9/Everything/x86_64/os http://ftp.ps.pl/pub/Linux/fedora-linux/releases/9/Everything/x86_64/os http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/9/Everything/x86_64/os http://ultra.linux.cz/MIRRORS/fedora.redhat.com/linux/releases/9/Everything/x86 _64/os http://ftp.heanet.ie/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.klid.dk/ftp/fedora/linux/releases/9/Everything/x86_64/os http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/ releases/9/Everything/x86_64/os http://gd.tuwien.ac.at/opsys/linux/fedora/linux/releases/9/Everything/x86_64/os http://ftp.wcss.pl/pub/linux/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.uvsq.fr/pub/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.cru.fr/pub/linux/fedora/releases/9/Everything/x86_64/os http://mirrors.linux.edu.lv/ftp.redhat.com/pub/fedora/linux/releases/9/Everythi ng/x86_64/os ftp://ftp.uib.no/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.man.poznan.pl/pub/linux/fedora/releases/9/Everything/x86_64/os http://ftp.linux.org.uk/pub/distributions/fedora/linux/releases/9/Everything/x8 6_64/os http://fedora.inode.at/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.pbone.net/pub/fedora/linux/releases/9/Everything/x86_64/os http://fedora.fastbull.org/linux/releases/9/Everything/x86_64/os ftp://ftp.proxad.net/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everythi ng/x86_64/os http://ftp.gui.uva.es/sites/fedora.redhat.com/linux/releases/9/Everything/x86_6 4/os http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everythi ng/x86_64/os http://redhat.linux.ee/pub/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/releases/9/Everything/x86_64/o s -- Axel.Thimm at ATrpms.net
Attachment:
pgpLk5OSjxxkj.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
