iozone is a dead.package in rawhide
by Tom Callaway
Due to licensing issues (iozone's license doesn't grant permission to
modify), I've dead.package'd iozone in devel. Please block it from
rawhide and all future dists.
Thanks,
~spot
15 years, 7 months
New Key Discussion v2 for FESCO Meeting
by Warren Togami
(Copying to FESCO list for discussion. I propose that FESCO looks over
the following plan and voice any concerns. But for the sake of time, I
recommend that FESCO vote to allow rel-eng the autonomy to execute so we
do not have further delays in getting updates out.)
This version is updated with an auto-key migration proposal by wwoods
and mbonnet. Jeremy and I think it is a decent plan. There is also an
auto-revoke plan.
1) Rel-eng gets security team's approval to the below plan.
2) 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.
3) AUTOMATIC KEY MIGRATION
New fedora-release contains NEW KEY, and NEW .repo file. New repo is
pointing at a new location on the mirror. This fedora-release is put
into the OLD repo, signed by the old key.
User upgrades into the new fedora-release and latest PackageKit, then
subsequent update will point at the new repo. Old .repo definition is
untouched at this point.
New repo contains subsequent Fedora updates signed by the new key.
4) Announce about the new key and let everyone be aware of the details
of this migration and user impact.
5) Push updates signed by the new key into the new repo.
6) Resigning all existing F8, F9, update and testing packages in
repos, leave ISO's alone. When resigned content is ready, remove the
RPMS from old repo, and put the resigned RPMS into new repo.
(WOO HOO!! This actually solved the proxy cache issue, since the URL's
of the changed content actually changes.)
7) After all old repo is emptied, issue a new rpm update in new repo.
This rpm contains an ugly hardcoded hack to eliminate the old key. This
sucks a lot, but Jeremy and I think this is our cleanest option. Jeremy
thinks, remove this hack for F10 rpm, and add it to Anaconda instead.
With this new rpm, is a new fedora-release that deletes the old .repo file.
8) Fedora 10 will have its own new key.
9) For Fedora 10 let us consider a better way to handle automatic key
migration. Let us NOT decide on this now. Agreeing to steps 1 through
5 are most critical in the short-term.
Warren Togami
wtogami(a)redhat.com
15 years, 7 months
Re: New Key Discussion for FESCO Meeting
by Toshio Kuratomi
Warren Togami wrote:
> (Copying to FESCO list for discussion. I propose that FESCO looks over
> the recommended steps below. If anything looks disagreeable please let
> rel-eng know. Otherwise I propose that FESCO vote to allow rel-eng the
> autonomy to implement a plan similar to below so we don't have to wait
> another week for another FESCO vote to decide how we will handle the
> rekeying.)
I'm sending to rel-eng and CC'ing FESCo list.
>
> 6) 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.
>
Did anyone look into geppetto's idea to have the new fedora-release
Obsolete the old key?
[snip]
> 8) 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.
>
Does this work better than having two keys in fedora-release? one of
which is the key that is used and the other which is a backup? (ie, the
public key is disseminated with fedora-release but the private key is
kept off of a networked computer. If we need to resign all packages, we
sign the packages with this backup key. And issue a new fedora-release
signed with this key and containing this key and a freshly generated
backup key)
-Toshio
15 years, 7 months
New Key Discussion
by 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
15 years, 7 months
Test 1 2 3
by Jeffrey Ollie
Test 1 2 3
--
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"
15 years, 7 months
[Fedora Release Engineering] #761: Block isicom from rawhide (and all future Fedora releases)
by Fedora Release Engineering
#761: Block isicom from rawhide (and all future Fedora releases)
----------------------------+-----------------------------------------------
Reporter: spot | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 10 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
the "isicom" package is now a dead.package, it depended on a kernel driver
we hadn't been enabling, and included binary firmware without any
licensing.
Please block it from rawhide and all future Fedora releases.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/761>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
15 years, 8 months
