On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote:
2008/8/29 Axel Thimm <Axel.Thimm(a)atrpms.net>:
> 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  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
Therefore, "they" can setup a mirror and sign stuff with
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
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
> 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
> 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
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").
# lynx --dump
# 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
Axel.Thimm at ATrpms.net