Markus Lehtonen did some initial work here, but apparently the upstream support for this has bitrotten somewhat (Fedora does not sign their feeds). We need to unbreak it and make sure it doesn't break again via selftest (probably same place where checking rpm signing is tested). http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=marquiz/dnf-rpm4&id=443e42c755e9b49d55a28eaf8ed361aff069f81b
What do you mean by "sign their feeds"? If you mean signing the repomd.xml with the distro GPG key, I don't know why you think the repodata needs something special to do this? That said, openSUSE does it with OBS just fine automatically using obs-sign[1]. Fedora signs the Cisco OpenH264 repository using sigul[2]. CentOS signs its repository metadata since CentOS 7.3 (with a tool or manually, I don't know). DNF supports verifying detached signatures of repomd.xml. Just sign the repomd.xml file as you would any other file (thus, generate a repomd.xml.asc file). Export the GPG public key somewhere so that it can be referenced in the .repo file. Now, if you're talking about RPM itself not being able to handle the password signing for packages, yes this was changed in RPM 4.13[3]. The commit[4] that changed this behavior explicitly did so because gnupg2 doesn't allow passing passphrases through a file descriptor by default since gnupg 2.1. If you're still using gpg1, then you can probably revert this behavior and do it the old way. However, I don't think there's much different between the old way and the new way (using pinentry and feeding to gpg2 directly). And the new way is secure, since the passphrase always goes to gpg2. [1]: https://github.com/openSUSE/obs-sign [2]: https://pagure.io/sigul [3]: http://rpm.org/wiki/Releases/4.13.0 [4]: https://github.com/rpm-software-management/rpm/commit/0bce5fcf270711a2e077fba0fb7c5979ea007eb5
(In reply to comment #1) > > DNF supports verifying detached signatures of repomd.xml. Just sign the > repomd.xml file as you would any other file (thus, generate a repomd.xml.asc > file). Export the GPG public key somewhere so that it can be referenced in > the .repo file. > One thing I forgot to note, you also need to configure DNF globally to verify repodata signatures, which you can do by adding "repo_gpgcheck=1" to dnf.conf.
(In reply to comment #2) > > DNF supports verifying detached signatures of repomd.xml. Just sign the > > repomd.xml file as you would any other file (thus, generate a repomd.xml.asc > > file). Export the GPG public key somewhere so that it can be referenced in > > the .repo file. > > > > One thing I forgot to note, you also need to configure DNF globally to > verify repodata signatures, which you can do by adding "repo_gpgcheck=1" to > dnf.conf. Signing feeds is not the issue. The problem is that feed signature verification with dnf's repo_gpgcheck facility doesn't actually work and has bitrotted according to our testing. Can you point us to some place where feeds are signed and *verified* using *dnf*?
(In reply to comment #3) > Signing feeds is not the issue. The problem is that feed signature > verification with dnf's repo_gpgcheck facility doesn't actually work and has > bitrotted according to our testing. Can you point us to some place where > feeds are signed and *verified* using *dnf*? Apologies for too hasty response - it's entirely possible that the problem is on our side, and something in dependency chain is misconfigured, it's just that when we tried, there was a generic and not very helpful error coming from pygpgme.
(In reply to comment #4) > (In reply to comment #3) > > > Signing feeds is not the issue. The problem is that feed signature > > verification with dnf's repo_gpgcheck facility doesn't actually work and has > > bitrotted according to our testing. Can you point us to some place where > > feeds are signed and *verified* using *dnf*? > > Apologies for too hasty response - it's entirely possible that the problem > is on our side, and something in dependency chain is misconfigured, it's > just that when we tried, there was a generic and not very helpful error > coming from pygpgme. The GPG verification code was rewritten for DNF 2.1.1 to use gpgme's official Python bindings (python3-gpg)[0]. If you're still trying to use pygpgme, it won't work as there are major bugs with it, and DNF doesn't even use it anymore. You can test the verification for yourself on Fedora with the OpenH264 repository. Fedora signs this repository, as you can see from the repo file[1] that ships on Fedora systems. I've also tested in the past with openSUSE repositories, and from what I can tell, it works. If it doesn't work, please file a bug[2] and tell us in #yum on Freenode. [0]: https://github.com/rpm-software-management/dnf/commit/5145f588b8ba1ff57351cdbf6a8238626c10f446 [1]: https://pagure.io/fedora-repos/blob/f26/f/fedora-cisco-openh264.repo [2]: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf&version=rawhide
Thank you for the information. We'll need to upgrade dnf to 2.1.1 and try again.
(In reply to comment #6) > Thank you for the information. We'll need to upgrade dnf to 2.1.1 and try > again. The current release of DNF is 2.2.0, paired with libdnf 0.8.1.
Thanks! I guess we need to update the stack and drop pygpgme then first.
Since you're using BitBake to generate these package builds, I don't really know how to adjust these things for you, but you can see from the Fedora spec[1] and the Mageia spec[2] on how to build gpgme for this. Then you can adjust dnf accordingly to depend on the gpg python module output by gpgme. Also, as an FYI, pygpgme is dead upstream. [1]: https://src.fedoraproject.org/cgit/rpms/gpgme.git/tree/gpgme.spec [2]: http://svnweb.mageia.org/packages/cauldron/gpgme/current/SPECS/gpgme.spec?view=markup
This shouldn't be an issue. Python 3 bindings are already enabled in gpgme recipe (although that was fixed pretty recently). We'll be entirely happy to get rid of pygpgme :)
(In reply to comment #10) > This shouldn't be an issue. Python 3 bindings are already enabled in gpgme > recipe (although that was fixed pretty recently). We'll be entirely happy to > get rid of pygpgme :) You need to make sure that gpgme is fully switched over to use gpg2, as well. Otherwise there will be random unexplainable crashes/failures.
Tentative dnf/libdnf updates to latest upstream releases are here: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates Note that they don't currently work due to this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1441636
Okay, I added a workaround, so the latest dnf/libdnf should work now. You can base the feed signing work on top of this branch: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
Moving to 2.4M3. Started to work on this.
I have a new patchset here: http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/fixes-11209 With that I'm able to use signed package feeds. Quickly tested with qemux86: 0. Enable package feed signing and package-management in local.conf: INHERIT += "sign_package_feed" PACKAGE_FEED_GPG_NAME = "<keyid>" PACKAGE_FEED_GPG_PASSPHRASE_FILE = "<path>" IMAGE_FEATURES += "package-management" 1. Build image and create package feed $ bitbake core-image-minimal package-index 2. Make the package feed available over http on your development machine 3. Run the image in qemu $ runqemu nographic 4. In the target, add repo root@qemux86:~# cat > /etc/dnf/dnf.conf << EOF [yocto] name=yocto baseurl=http://192.168.7.1/rpm/ gpgcheck=1 repo_gpgcheck=1 gpgkey=http://192.168.7.1/rpm/PACKAGEFEED-GPG-KEY-nodistro.0 EOF 5. In the target, run dnf root@qemux86:~# dnf -v update ... root@qemux86:~# dnf install util-linux-fsck ...
(In reply to comment #15) > With that I'm able to use signed package feeds. Quickly tested with qemux86: > 0. Enable package feed signing and package-management in local.conf: > INHERIT += "sign_package_feed" > PACKAGE_FEED_GPG_NAME = "<keyid>" > PACKAGE_FEED_GPG_PASSPHRASE_FILE = "<path>" > IMAGE_FEATURES += "package-management" > > 1. Build image and create package feed > $ bitbake core-image-minimal package-index > > 2. Make the package feed available over http on your development machine > > 3. Run the image in qemu > $ runqemu nographic > > 4. In the target, add repo > root@qemux86:~# cat > /etc/dnf/dnf.conf << EOF > [yocto] > name=yocto > baseurl=http://192.168.7.1/rpm/ > gpgcheck=1 > repo_gpgcheck=1 > gpgkey=http://192.168.7.1/rpm/PACKAGEFEED-GPG-KEY-nodistro.0 > EOF > > 5. In the target, run dnf > root@qemux86:~# dnf -v update > ... > root@qemux86:~# dnf install util-linux-fsck > ... Can you add these steps to the remote feeds selftest we have? All the necessary pieces are already there, you simply need to extend the testcase defined here: meta/lib/oeqa/selftest/cases/runtime_test.py (look for test_testimage_dnf) meta-selftest/lib/oeqa/runtime/cases/dnf-runtime.py
Patches sent for review: https://patchwork.openembedded.org/series/8187/
Merged in oe-core master: http://git.openembedded.org/openembedded-core/commit/?id=4d65421f381fc69397d7c61ba76488775e83e043
This also needs a documentation update, as the docs currently say rpm feed signing is (temporarily) not supported. Reassign to Scott please.
Alexander, Are the steps in Comment 15 basically the procedure to get this done? If so, we can add a section that documents those steps. We do have this section (http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#signing-rpm-packages) in the dev-manual. Can we just update that section? Scott
(In reply to comment #20) > > Are the steps in Comment 15 basically the procedure to get this done? If > so, we can add a section that documents those steps. > > We do have this section > (http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#signing-rpm- > packages) in the dev-manual. > > Can we just update that section? No, it's related to the next section: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing-package-feeds You could just remove RPM from the note saying that signed package feeds are not supported.
Ok - I took out the note. Can we call it good on this one? Scott http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing-package-feeds
No. This still makes it sound like signing RPM repodata (package feeds) is not supported. This change is supposed to *add* support for it.
(In reply to comment #22) > Ok - I took out the note. Can we call it good on this one? > > Scott > > http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing- > package-feeds Replace " In addition to being able to sign RPM packages, you can also enable the OpenEmbedded build system to be able to handle previously signed package feeds for IPK packages. " with " In addition to being able to sign RPM packages, you can also enable signed package feeds for IPK and RPM packages. "
(In reply to comment #24) > (In reply to comment #22) > > Ok - I took out the note. Can we call it good on this one? > > > > Scott > > > > http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing- > > package-feeds > > Replace > > " In addition to being able to sign RPM packages, you can also enable the > OpenEmbedded build system to be able to handle previously signed package > feeds for IPK packages. " > > with > > " In addition to being able to sign RPM packages, you can also enable signed > package feeds for IPK and RPM packages. " Alexander - I've made this replacement: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing-package-feeds Let me know if there are further issues on this one. Thanks, Kristi
(In reply to comment #25) > Alexander - I've made this replacement: > http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#processing- > package-feeds > > Let me know if there are further issues on this one. Looks good now, thank you.
Thanks - setting to RESOLVED and putting the doc flag to 'done'.