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.
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.
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...
Created attachment 529623 [details] patch to add an error message
Created attachment 529624 [details] spec file to apply patch
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 ***
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.