gpg keys of older/newer fedora versions

[Zbigniew Jędrzejewski-Szmek]

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

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