J Katz reprised a prior discussion:
Also note that you're probably going to want to edit
/etc/sysconfig/up2date and set useGPG=0 so that you don't get asked if
you want to continue on every package due to the fact that all of the
beta packages are unsigned :(
This brings us back to the question of having a beta key to verify
packages... especially with up2date stuff, it would be _extremely_
Prior disclaimers apply -- it might be appropiate to add a 'rawhide' key as
well, to allow prevention of unintended installation of rawhide in a
production environment ...
While I like this idea for this, it's not something we'll do right away. I'm
marking this defect as DEFERRED (but not closing it).
Hi, Glen, NEEDINFO and non-DEFERRable request
The production cycle is such that in the next few weeks, physical
CD's will be released into the retail market, and the up2date keying
will likewise be pre-keyed.
Does it not make sense to generate known keys for firstname.lastname@example.org and
email@example.com , and _DISTRIBUTE_ these NOW, in this cycle,
and build the rest of the infrastructure later?
Re-open for consideration of proposed RFE in RH 7.2
Post release of RH 7.2
I am still interested in this -- and indeed, if every package was signed --
with at least ONE RH key as a matter of the SOP, if the 'released without
signing' fiasco of RH 7.2 gold could have been 'covered' by acknowledging the
secondary previously 'unofficial' key.
There needs to be something similar for rhcontrib (currently rhcontrib.bero.org)
for making sure the mirrored package is the same as the one that was compiled in
rhcontrib. But there we also need some mechanism for preserving the SRPM
signature when the uploaded SRPM was signed.
At relesase of first Beta for RH 8.0
Still interested -- still applicable for all the same reasons.
Versions included in the skipjack beta should include a
beta only key and up2date support for using it.
This has been fixed for quite some time. Closing out.