Bug 1376433

Summary:	dnf does not update GPG key of repo when its expiration date was changed
Product:	[Fedora] Fedora	Reporter:	lpugoy
Component:	gnupg	Assignee:	Brian Lane <bcl>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	23	CC:	bcl, jon, jsilhan, mluscon, packaging-team-maint, pnemade, rdieter, rpm-software-management, tmraz, vmukhame
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-20 23:22:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description lpugoy 2016-09-15 12:19:44 UTC

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.

Comment 1 Jon Jensen 2016-10-19 16:01:36 UTC

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.

Comment 2 Michal Luscon 2016-10-20 09:22:35 UTC

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

Comment 3 Brian Lane 2016-10-20 23:22:08 UTC

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.