Bug 748116

Summary: rpmsign does not update file
Product: [Fedora] Fedora Reporter: Bill C. Riemers <briemers>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: ffesti, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-23 11:43:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
patch to add an error message
none
spec file to apply patch none

Description Bill C. Riemers 2011-10-22 06:07:14 UTC 
Description of problem:

rpmsign appears to do everything it is suppose to but actually update the file.

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

4.9.1.2-1

How reproducible:

100%

Steps to Reproduce:
1. Attempt to sign any rpm using gpg.
2. e.g. rpmsign --addsign foo.rpm
3.
  
Actual results:

Before and after the file has the same time stamp, and there is no signature added.

Expected results:

A signature should be added.


Additional info:

[briemers@briemersw ~]$ rpm -K xulrunner-7.0.1-2.fc15.x86_64.rpm 
xulrunner-7.0.1-2.fc15.x86_64.rpm: sha1 md5 OK
[briemers@briemersw ~]$ ls -la xulrunner-7.0.1-2.fc15.x86_64.rpm 
-rw-rw-r--. 1 briemers briemers 9614417 Oct 20 22:48 xulrunner-7.0.1-2.fc15.x86_64.rpm
[briemers@briemersw ~]$ rpmsign --addsign xulrunner-7.0.1-2.fc15.x86_64.rpm Enter pass phrase: 
Pass phrase is good.
xulrunner-7.0.1-2.fc15.x86_64.rpm:
[briemers@briemersw ~]$ rpm -K xulrunner-7.0.1-2.fc15.x86_64.rpm 
xulrunner-7.0.1-2.fc15.x86_64.rpm: sha1 md5 OK
[briemers@briemersw ~]$ ls -la xulrunner-7.0.1-2.fc15.x86_64.rpm 
-rw-rw-r--. 1 briemers briemers 9614417 Oct 20 22:48 xulrunner-7.0.1-2.fc15.x86_64.rpm

Looking at the strace is not very informative, but it looks like the rpm is copied to a temp file where the key is added, and that temp file is deleted without ever copying the data into the rpm.   The rpm is only accessed read only during the entire processes.
Comment 1 Bill C. Riemers 2011-10-22 14:12:46 UTC 
It looks like the problem is that pgpPrtPkts returns a non-zero value.  In that case, rpm-sign silently fails.   It looks like pgpPrtPkts does not provide any sort of diagnostic information to indicate what the problem is with the gpg signature.
Comment 2 Bill C. Riemers 2011-10-22 14:30:27 UTC 
I generated a new key, and that one seems to work.  The differences in keys is the first one was a 2048 bit DSA key with a expiration of 5 years.  The second was a 1024 bit DSA key with no expiration.   Don't know if the part that causes problems is the number of bits, or the expiration.

At minimum, an error message needs to be added to rpm-sign there is some indication that a failure occurred and why it occurred.   I actually wasted a huge amount of bandwidth uploading rpm's to my repo, that I thought were signed... Multiple times...
Comment 3 Bill C. Riemers 2011-10-22 15:01:50 UTC 
Created attachment 529623 [details]
patch to add an error message
Comment 4 Bill C. Riemers 2011-10-22 15:02:31 UTC 
Created attachment 529624 [details]
spec file to apply patch
Comment 5 Panu Matilainen 2011-10-23 11:43:41 UTC 
Thanks for looking up the place with missing error message. It can't go making assumptions about DSA (there are any number of reasons why it could fail), but it should issue an error anyway. A rather vague message added upstream (the caller has little clue of what failed) but better than silently failing...

*** This bug has been marked as a duplicate of bug 719154 ***
Comment 6 Bill C. Riemers 2011-10-24 03:09:55 UTC 
Definitely, even a very vague message is better than no message at all.  At least this way at least the user knows something has failed.  Once they have an error message they can google, or try something different instead of just left assuming the command succeeded.