Hide Forgot
Description of problem: After adding a repo and importing its GPG key, dnf does not update the key even if its expiration date was changed. Version-Release number of selected component (if applicable): $ dnf --version 1.1.10 Installed: dnf-0:1.1.10-1.fc23.noarch at 2016-09-06 09:04 Built : Fedora Project at 2016-08-18 14:43 Installed: rpm-0:4.13.0-0.rc1.13.fc23.x86_64 at 2016-08-05 04:54 Built : Fedora Project at 2016-04-25 13:50 How reproducible: Always Steps to Reproduce: 1. Create a new GPG key. For convenience set it to expire in 1 day. 2. Create a new directory that will act as the new repo, e.g., ~/repo. 3. Copy any rpm to ~/repo. 4. Ensure that the GPG key is set as the %_gpg_name value in ~/.rpmmacros. 5. Export the secret keys to gpg2 as well with "gpg --export-secret-keys | gpg2 --import". Seems to be a requirement for rpmsign to work. 6. Sign the rpm under ~/repo. 7. In the ~/repo directory run "createrepo -v --update .". 8. In the ~/repo directory run "gpg --detach-sign -a --default-key [name of GPG key] repodata/repomd.xml" 9. In the ~/repo directory run "gpg --export -a [name of GPG key] > repodata/repomd.xml.key. 10. Create the file /etc/yum.repos.d/test.repo with the ff contents: [test] name=test repo baseurl=file:///path/to/repo/folder gpgcheck=1 gpgkey=file:///path/to/repomd.xml.key enabled=1 repo_gpgcheck=1 11. Run "sudo dnf makecache". This will import the GPG key. 12. Wait until the key expires. 13. Update its expiration date and re-export the updated key to ~/repo/repodata/repomd.xml.key. 13. Rerun "sudo dnf makecache". Actual results: dnf will show an error "Failed to synchronize cache for repo 'test', disabling." Expected results: dnf should import the new key. Additional info: One workaround is to delete the folder that contains the repo's info under /var/cache/dnf. Like if the repo is named test, then the folder /var/cache/dnf/test-xxxxx should be deleted for dnf to update the GPG key.
A data point that may be relevant: Using gpg 1.4.21 on Fedora 24, I find that `gpg --import $keyfile` does not update an existing expired key with a newer key with a future expiration date. The --import option seems to only get new signatures, but not new expiration dates. I have to fully delete the key, then import the new one, to get the new expiration date. I do not remember ever having to delete a key in the past to get the expiration date updated. In any case, it sounds like it could be the root of the problem reported above with dnf not updating PGP key expiration dates.
(In reply to Jon Jensen from comment #1) > The --import option seems to only get new signatures, but not new expiration > dates. Therefore it seems to be an issue of gnupg. Please let us know whether there is anything that needs to be changed on the DNF side.
I'm fairly sure there's nothing wrong with gpg 1.4.21, I cannot reproduce this here with a simple test. I generated a key on a clean install, exported the never expiring version, edited to expire in 6 days, exported that. Then removed the ~/.gnupg directory and imported both of them. The 6 day one replaced the never expiring one just fine. [root@c84e269304e5 ~]# gpg --list-keys && gpg --import expire-test-never-gpg1.key.asc gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: keyring `/root/.gnupg/secring.gpg' created gpg: key 6C2BCE6D: public key "expire-test <expire-test>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) [root@c84e269304e5 ~]# gpg --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 2048R/6C2BCE6D 2016-10-20 uid expire-test <expire-test> sub 2048R/37C386AA 2016-10-20 [root@c84e269304e5 ~]# gpg --list-keys && gpg --import expire-test-6-days-gpg1.key.asc /root/.gnupg/pubring.gpg ------------------------ pub 2048R/6C2BCE6D 2016-10-20 uid expire-test <expire-test> sub 2048R/37C386AA 2016-10-20 gpg: key 6C2BCE6D: "expire-test <expire-test>" 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 [root@c84e269304e5 ~]# gpg --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 2048R/6C2BCE6D 2016-10-20 [expires: 2016-10-26] uid expire-test <expire-test> sub 2048R/37C386AA 2016-10-20 I'm guessing this is something to do with your environment. If you can reproduce this in a clean fashion (eg. a script that can be run on a clean system) then we'll have something to work with.