[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New Key Repo Locations



2008/8/29 Axel Thimm <Axel Thimm 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. Therefore, "they" can
setup a mirror and sign stuff with the old key, but it won't be used
by the default config.

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?

> 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.

> 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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]