Bug 1277464 - RPM should not crash on old GPG keys
Summary: RPM should not crash on old GPG keys
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 23
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-11-03 12:07 UTC by Göran Uddeborg
Modified: 2015-11-08 22:20 UTC (History)
5 users (show)

Fixed In Version: rpm-4.13.0-0.rc1.5.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-08 22:20:04 UTC

Attachments (Terms of Use)
Key acba50c7 (4.88 KB, text/plain)
2015-11-03 20:03 UTC, Göran Uddeborg
no flags Details
Key cba29bf9 (3.08 KB, text/plain)
2015-11-03 20:07 UTC, Göran Uddeborg
no flags Details

Description Göran Uddeborg 2015-11-03 12:07:51 UTC
Description of problem:
After upgrading to the F23 version of rpm, most commands started to crash with a segmentation fault.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Prepare an RPM database with some old keys.  In my case, I had the keys gpg-pubkey-cba29bf9-31295e35.src and gpg-pubkey-acba50c7-3509d939.src still around in my database.  They were installed during 2002, so they were indeed old.
2. Upgrade to current RPM
3. rpm -qa

Actual results:
A segmentation fault

Expected results:
A list of all packages.

Additional info:
After a little debugging, I found that this happens in loadKeyringFromDB.  If a key is old, rpmPubkeyNew will return null.  This value is sent to rpmGetSubkeys, which tries to dereference it.  Which of course results in the crash.

Note that I'm not arguing that RPM should continue to SUPPORT these old keys.  What I'm saying is it should handle their presence more gracefully than a crash.  Just a simple check of the return value from rpmPubkeyNew, would be enough.  If it is null, then skip this iteration iteration.  Add a little warning that the key ought to be removed, and things would be much nicer! :-)

Comment 1 Ľuboš Kardoš 2015-11-03 14:23:58 UTC
Your keys were probably ignored also in rpm-4.12 but rpmGetSubkeys() was added in rpm-4.13 and it causes this crash.

Yes, I can just add condition if rpmPubkeyNew() returns NULL then ingore it and show a warning. But I want to know what is wrong with your old keys. Can you put here output of "rpm --nosignature -qi gpg-pubkey-cba29bf9-31295e35" and  "rpm --nosignature -qi gpg-pubkey-acba50c7-3509d939" ?

Comment 2 Göran Uddeborg 2015-11-03 20:03:58 UTC
Created attachment 1089191 [details]
Key acba50c7

Comment 3 Göran Uddeborg 2015-11-03 20:07:32 UTC
Created attachment 1089192 [details]
Key cba29bf9

At your service! :-)

Thinking about it, I don't really know if there is anything wrong with the key acba50c7.  When I realized the reason, I did an "rpm --last ..." and started to remove keys from the end.  After the second key, rpm started working.  So I can't be sure if I had left the first and only removed the second.

(I could find out, but I guess you're in a better position to investigate this from here.)

Comment 4 Fedora Update System 2015-11-06 13:36:02 UTC
rpm-4.13.0-0.rc1.5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-52b53659c1

Comment 5 Fedora Update System 2015-11-08 13:24:37 UTC
rpm-4.13.0-0.rc1.5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update rpm'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-52b53659c1

Comment 6 Fedora Update System 2015-11-08 22:20:01 UTC
rpm-4.13.0-0.rc1.5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.