gpg keys of older/newer fedora versions

[Neal Gompa]

On Wed, Aug 5, 2015 at 8:41 AM, Ryan S. Brown <ryansb at redhat.com> wrote:

> On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote:
> >> On Fri, 17 Jul 2015 17:28:48 +0000
> >> Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> wrote:
> >>
> >>> [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383]
> >>>
> >>> 'dnf install --installroot=... --releasever=XX dnf' can be used to
> >>> bootstrap a Fedora chroot. The only snag is that --nogpg is often
> >>> recommended, because fedora-repos only provides the GPG keys for the
> >>> current and next release.
> >>>
> >>> It would be convenient (and safe!) to provide keys for past and
> >>> future releases, so such bootstrapping can be done without either
> >>> importing the keys manually and/or using --nogpg.
> >>>
> >>> I thought I'd ask here first: is there a strong reason *not* to
> >>> include those keys?
> >>
> >> So, I missed this thread, but saw it from the bug filed:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1246701
> >>
> >> Several things here:
> >>
> >> * If we ship gpg keys for old eol Fedora releases, aren't we
> >>   encouraging people to setup things we no longer support?
> > I never asked for keys from EOL releases. I think keys should
> > be removed after EOL.
> >
> >> * If we only ship supported releases in each fedora-repos package, it
> >>   means more churn for that package for everyone as when a release goes
> >>   EOL we would need to push a new update that removes the old EOL key.
> > Is "everyone" the users or they maintainers of fedora-repos.rpm?
> > The "churn" is really tiny: the package is small, and this happens
> > only twice a year, so I dont' think users will notice or care. As for
> > the maintainers: I know it is a bit of extra work. I'm trying to ask
> > nicely :)
> >
> >> * As till pointed out, mock seems to already carry these keys, so some
> >>   coordination here seems like a good idea no matter what we do. ;)
> > Yeah. One issue I see is that mock seems to be always trailing with
> > the updates. Mock in F22 now has
> > /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary
> > /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary
> > The version in updates-testing removes keys for F19 and F20,
> > and adds keys for F23. It has chroot definitions to match those keys.
> > *If* mock was relying on fedora-repos to carry they keys, it would
> > be possible to have chroots without a matching key. I don't
> > know if that would be good (EOL chroots stop working as expected) or
> > bad (EOL chroots stop working unexpectedly).
>
> I disagree that including the keys for EOL'd releases counts as
> "encouraging" people to use old stuff. If someone has a reason to be
> building RPMs for something way-old, I think it'd be nice for us to keep
> those GPG keys available for them.
>
> Speaking only for myself, whenever I have to build something for a very
> old box, the last thing I want is mock giving me grief about not having
> a GPG key that old.
>
> >> * Can you describe the use case here a bit more? Why wouldn't you use
> >>   mock (which has the keys already) to make a chroot?
> > I want to use dnf to create containers, e.g. for running with
> > systemd-nspawn. Sometimes for installation of Fedora on a disk
> > to bootstrap a new machine. In either way, it is a one-time
> > operation where the result is permanent.
> >
> > mock is about repeatedly creating chroots tailored for rpm building...
> > The underlying installation mechanism is pretty much the same,
> > but that's about it.
> >
> > Zbyszek
> >
>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​As someone who is regularly using mock to build RPMs for various Fedora
releases for $DAYJOB as well as for packages that I submit to Fedora
Project, I would prefer if the ability to build RPMs for older releases is
preserved (even EOL ones). As for the container things, it'd be interesting
if mock could use DNF+nspawn for that work in the future, and if that means
splitting out GPG keys and such into a package that both DNF and mock can
use, that would be great.

I personally don't think that having mock being able to build for older
releases would encourage the view that Fedora supports older releases.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150805/4105412e/attachment.html>