Bug 165244 - rpmbuild -ba --sign or rpm --resign fail to sign package
rpmbuild -ba --sign or rpm --resign fail to sign package
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-05 15:37 EDT by Steve Willoughby
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-09 09:17:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Willoughby 2005-08-05 15:37:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
rpmbuild -ba --sign --target i386-Fedora-4 <package.spec> builds the package, but never asks for the secret key passphrase nor signs the package.  No indication is given that anything failed.

rpm --resign <package.rpm> gives a line of output:
  <package>:
but does not ask for the passphrase nor signs the package.

This system was upgraded from FC1 to FC4.  I've found several instances where the old package remained in place because the replacement package had a different name ie. kernel-sources should have been removed and replaced with kernel-devel.

There are two gnupg packages installed - gnupg-1.4.1-3 and gnupg2-1.9.16-4.fc4.

I've tried changing the order of the options with no difference in behaviour.

I have several secret keys but haven't been prompted to choose any one.

Version-Release number of selected component (if applicable):
rpm-4.4.1-22  kernel-2.6.12-1.1398_FC4  

How reproducible:
Always

Steps to Reproduce:
1.rpmbuild -ba --sign --target i386-Fedora-4 <package.spec>
2.check the rpm with rpm -qi <package.rpm>
3.Signature in info will be indicated as none.
or
1.rpm --resign <package.rpm>
2.check the rpm with rpm -qi <package.rpm>
3.Signature in info will be indicated as none.

  

Actual Results:  Either command completes with no errors.  When the package rpm file is checked, the signature has not been incorporated into the package.

Expected Results:  The Signature field in the rpm -qi <package.rpm> info report should have had the information relating to the secret/public key pair used to sign the package.

Additional info:

I am using the same proceedure used on FC1 to build packages successfully, except now the package is not getting signed.
Comment 1 Paul Nasrat 2005-08-05 15:50:35 EDT
What is the contents of your ~/.rpmmacros? Do you have the gpg settings in place eg:

%_signature gpg
%_gpg_path /home/pauln/.gnupg

%_gpg_name Paul Nasrat <pauln@truemesh.com>

rpmbuild -bb --sign --target i386 dummy.spec
Enter pass phrase:
Pass phrase is good.
Building target platforms: i386
Building for target i386
Processing files: dummy-1.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/dummy-root
Generating signature: 1005
Wrote: /home/pauln/rpm/RPMS/dummy-1.0-1.noarch.rpm
Comment 2 Paul Nasrat 2005-08-05 15:53:00 EDT
As regards you upgrade issues - did you upgrade using anaconda?
Comment 3 Steve Willoughby 2005-08-09 09:17:52 EDT
You put your finger on the problem - the .rpmmacros file was missing.  I copied
over from another system and modified to match the secret key I wanted to use
and signing worked!  Would be nice is the RPMBUILD man page had more info on the
minimum entries in .rpmmacros to make signing work as well as the fact that this
is the main place for that info to live.  An explicit pointer in the RPMBUILD
man page pointing to the USING GPG TO SIGN PACKAGES section in the RPM man page
might have helped.  I figured this out over three years ago looking at the time
stamp on the .rpmmacros file and it's worked ever since.  I just missed the
critical info when pouring through the man pages trying to troubleshoot the problem.

The upgrade was done through the anaconda installer - instead of installing one
of the template configurations or custom, I chose to upgrade an existing
installation.

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