New Key Discussion

[Warren Togami]

(Copying to list so there is a public record.)

Below are some notes toward forming a recommendation for FESCO for the
procedure of reissuing the new keys and how we will handle the packages
in the repository.  Please add your comments.

1) Generate new key for F8 and F9 stable, and a separate key for testing.

The goal of this new key would be to upgrade from "high certainty" to
"full known certainty" in the integrity of package signatures.

2) Announce new key and instructions for users because most users will
be required to install the new fedora-release manually.

Unfortunately, nobody could think of a fool-proof way to automate
getting the new key to users.  We considered issuing a new
fedora-release signed by the old key.  This idea was rejected because
after another update is issued with the new key, then the transaction
requires manual intervention to succeed.  There is simply no escaping
the need to manually install the new key.

(Any other ideas?)

On the plus side: Unlike PK at F9 GA, the latest PK in F9 updates can
now ask the user if they wish to import a key.

3) Begin using the new key immediately to sign new updates.

4) Begin resigning all existing F8, F9, update and testing packages in
repos, leave ISO's alone.   Replace content on mirrors over time.

According to Jesse this step would require ~3 weeks of time.  For this
reason it may be impractical to do this prior to

Crap.  I just realized that anybody behind a caching proxy server will
have severe issues when mirror content is resigned.  Packages will
inconsistently appear to be the old key long after they were signed
because their contents changed but their URL did not.  The only way we
will avoid a many broken users and mass complaints is to make an updated
version of yum smarter when faced with X-Cache headers.

5) In a few weeks after all F8+ packages are resigned with the new key,
revoke the old key.  The only way we can revoke the old key is to rpm -e
it.  Unfortunately, skvidal did some research into ways we could
possibly achieve this and our options are not good.  rpm -e is
impossible during rpm %post because it locks the transaction.  We really
do need a way to automate revocation of the old key.  It seems we have a
few weeks to figure out a way to do it.

(Idea: Perhaps we add a hack to rpm itself in a package update?  Ugly as
hell, but what other options do we have?)

During the meeting it was discussed that we might issue a new key and
keep the existing packages signed with the old key.  This idea was
rejected because there would be almost no point in generating a new key.

6) Fedora 10 will have its own key generated according to Jesse.

7) We should really consider a "master key" mechanism for future Fedora
releases that would allow us to automate revocation of an old key and
automate migration to a new key in a way that does not require manual
intervention of the user.  The master key would sign any new key
generated.  The master key would be kept somewhere away from any
networked computer.

Warren Togami
wtogami(a)redhat.com

[Jesse Keating]

On Tue, 2008-08-26 at 13:16 -0400, Warren Togami wrote:
>  4) Begin resigning all existing F8, F9, update and testing packages
> in
>  repos, leave ISO's alone.   Replace content on mirrors over time. 
Josh suggested doing releases in whole, IE do all the F8 content, then
all the F9 content.  That could make it go a bit faster and not leave
any users with mixed bags of signed content.

I'm only guessing on the 3 weeks thing, it could go faster, if I get
clever with expect (but then I think the passphrase sits somewhere in
the process list or memory or something, I'm not exactly comfortable
with that).

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Bill Nottingham]

Jesse Keating (jkeating(a)redhat.com) said: 
>  Josh suggested doing releases in whole, IE do all the F8 content,
> then
>  all the F9 content.  That could make it go a bit faster and not leave
>  any users with mixed bags of signed content.
>  
>  I'm only guessing on the 3 weeks thing, it could go faster, if I get
>  clever with expect (but then I think the passphrase sits somewhere in
>  the process list or memory or something, I'm not exactly comfortable
>  with that). 
It should be doable piecemeal, correct - there's no reason we have to
push them until all of a particular release is done?

Bill

[Warren Togami]

Bill Nottingham wrote:
>  Jesse Keating (jkeating(a)redhat.com) said: 
> > Josh suggested doing releases in whole, IE do all the F8 content, then
> > all the F9 content.  That could make it go a bit faster and not leave
> > any users with mixed bags of signed content.
> >
> > I'm only guessing on the 3 weeks thing, it could go faster, if I get
> > clever with expect (but then I think the passphrase sits somewhere in
> > the process list or memory or something, I'm not exactly comfortable
> > with that).
>  
>  It should be doable piecemeal, correct - there's no reason we have to
>  push them until all of a particular release is done? 
Piecemeal would be less sudden load on the mirrors to sync.

The caching proxy problem however will be equally bad no matter how we 
stage the resigned packages.

Warren

[Jesse Keating]

On Tue, 2008-08-26 at 13:16 -0400, Warren Togami wrote:
>  
>  Below are some notes toward forming a recommendation for FESCO for the
>  procedure of reissuing the new keys and how we will handle the packages
>  in the repository.  Please add your comments. 
In the interest of getting this into FESCo's schedule, warren can you
make a wiki page with this info and toss it to the fesco chair to get on
the schedule?  I don't know if my proposal template made the transition
though :/

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Jeffrey Ollie]

On Tue, Aug 26, 2008 at 12:16 PM, Warren Togami <wtogami(a)redhat.com&gt; wrote:
>  5) In a few weeks after all F8+ packages are resigned with the new key,
>  revoke the old key.  The only way we can revoke the old key is to rpm -e
>  it.  Unfortunately, skvidal did some research into ways we could
>  possibly achieve this and our options are not good.  rpm -e is
>  impossible during rpm %post because it locks the transaction.  We really
>  do need a way to automate revocation of the old key.  It seems we have a
>  few weeks to figure out a way to do it.
>
>  (Idea: Perhaps we add a hack to rpm itself in a package update?  Ugly as
>  hell, but what other options do we have?) 
Drop a script in /etc/cron.hourly that rpm -e's the key and then
deletes/disables itself.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"