gpg keys of older/newer fedora versions
[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? Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Fri, 17 Jul 2015, Zbigniew Jędrzejewski-Szmek 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? I see no reason not to do that. We were also going to put those keys into DNS, pendig some changes of the OPENPGPKEY ietf draft document. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Fri, Jul 17, 2015 at 05:28:48PM +, Zbigniew Jędrzejewski-Szmek 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. > I thought I'd ask here first: is there a strong reason *not* to include those > keys? The mock package contains a huge collection of keys in /etc/pki/mock/ (Fedora, CentOS, EPEL, RHEL), maybe they could be split out in a separate package to be used both by mock and dnf. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Fri, 17 Jul 2015 17:28:48 + Zbigniew Jędrzejewski-Szmek 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? * 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. * 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. ;) * 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? kevin pgpV3afbRI_kj.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote: > On Fri, 17 Jul 2015 17:28:48 + > Zbigniew Jędrzejewski-Szmek 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
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 + >> Zbigniew Jędrzejewski-Szmek 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Wed, Aug 5, 2015 at 8:41 AM, Ryan S. Brown 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 + > >> Zbigniew Jędrzejewski-Szmek 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@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! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On 7/18/15, Zbigniew Jędrzejewski-Szmek wrote: > I thought I'd ask here first: is there a strong reason *not* to include > those keys? It's not recommended to encourage end users installing EOL releases. However a seperate package for gpg keys from EOL releases is OK. But is it worthwhile to move these keys out from mock? Thanks. -- Yours sincerely, Christopher Meng http://awk.io -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Wed, 5 Aug 2015, Neal Gompa wrote: 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. Agreed. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Thu, Aug 06, 2015 at 12:58:36PM +0800, Christopher Meng wrote: > On 7/18/15, Zbigniew Jędrzejewski-Szmek wrote: > > I thought I'd ask here first: is there a strong reason *not* to include > > those keys? > > It's not recommended to encourage end users installing EOL releases. > > However a seperate package for gpg keys from EOL releases is OK. > > But is it worthwhile to move these keys out from mock? I think it is, for two reasons: 1. keys in mock are in a mock specific directory, so dnf doesn't know about them. I'd like things to work out-of-the-box, without the need to manually adjusts paths or copy keys around. 2. mock is at a higher level in the stack. It has different purpose, gives privileges to some users, has additional functionality, etc. Mock also pulls in some packaging tools, including both dnf and yum. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On 08/05/2015 09:58 PM, Christopher Meng wrote: On 7/18/15, Zbigniew Jędrzejewski-Szmek wrote: I thought I'd ask here first: is there a strong reason *not* to include those keys? It's not recommended to encourage end users installing EOL releases. I don't see how this affects people installing old releases either way. It's easy to install any release. Just point to the right repo, the keys are included. Is there some other aspect to this that I'm missing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Thu, Aug 06, 2015 at 11:43:19AM -0700, Samuel Sieb wrote: > On 08/05/2015 09:58 PM, Christopher Meng wrote: > >On 7/18/15, Zbigniew Jędrzejewski-Szmek wrote: > >>I thought I'd ask here first: is there a strong reason *not* to include > >>those keys? > > > >It's not recommended to encourage end users installing EOL releases. > > > I don't see how this affects people installing old releases either > way. It's easy to install any release. Just point to the right > repo, the keys are included. Is there some other aspect to this > that I'm missing? How would you know that those keys are the right keys? Once it is installed, it will use it's own keys, but during the initial installation you have to provide the keys (or take the leap of faith with --nogpg). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
