Bug 455169 - Can not prevent attaching multiple PGP signatures instead of a GPG one
Can not prevent attaching multiple PGP signatures instead of a GPG one
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-13 09:03 EDT by Lubomir Rintel
Modified: 2009-07-14 10:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:34:10 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 Lubomir Rintel 2008-07-13 09:03:05 EDT
Sooo I discussed this with mbonnet a couple of days ago, and was advised to
report it as bug. Basically, due to some reason, I can not make GPG signatures,
and my instance of koji doesn't deal with other types afaik.

I can also add multiple equivalent signatures, which should not be possible (at
least according to the documentation).

Experienced exactly the ame behavior on both el5 and fc9.

Here's what I did -- please let me know if there's anything obviously wrong there:

1.) My secret GPG key is imported:
(I did not generate that key. Can there be a problem with it?)

[lkundrak@jesus devel]$ gpg --list-secret-keys
/home/lkundrak/.gnupg/secring.gpg
---------------------------------
sec   4096R/CAFF6A70 2008-06-24 [expires: 2010-06-24]
uid                  Automatic Signing Key (Build System)
<root@localhost.localdomain>

2.) RPM configured as described in documentation:

[lkundrak@jesus devel]$ cat ~/.rpmmacros 
%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

%_signature gpg
%_gpg_name Automatic Signing Key (Build System) <root@localhost.localdomain>
%_gpg_path /home/lkundrak/.gnupg
%_gpgbin /usr/bin/gpg2

3.) Let's check the RPM has no signature now:

[lkundrak@jesus devel]$ rpm -vv --checksig ovaldi-5.4.2-2.fc10.src.rpm 
D: Expected size:      4976031 = lead(96)+sigs(180)+pad(4)+data(4975751)
D:   Actual size:      4976031
ovaldi-5.4.2-2.fc10.src.rpm:
    Header SHA1 digest: OK (b5b20de6976c9a43fb8b00205720648cedc7620f)
    MD5 digest: OK (15c8575889d5f1bf97f8035e2bcd7aa3)
D: May free Score board((nil))

4.) Sign it:

[lkundrak@jesus devel]$ rpm -vv --addsign ovaldi-5.4.2-2.fc10.src.rpm 
Enter pass phrase: 
Pass phrase is good.
ovaldi-5.4.2-2.fc10.src.rpm:
D: Expected size:      4976031 = lead(96)+sigs(180)+pad(4)+data(4975751)
D:   Actual size:      4976031
gpg: WARNING: standard input reopened
D: GPG sig size: 543
D: Got 543 bytes of GPG sig
gpg: WARNING: standard input reopened
D: GPG sig size: 543
D: Got 543 bytes of GPG sig
D: Signature: size(1296)+pad(0)
D: May free Score board((nil))

5.) One V4 RSA/SHA1 was added:

[lkundrak@jesus devel]$ rpm -vv --checksig ovaldi-5.4.2-2.fc10.src.rpm 
D: Expected size:      4977143 = lead(96)+sigs(1296)+pad(0)+data(4975751)
D:   Actual size:      4977143
ovaldi-5.4.2-2.fc10.src.rpm:
    Header V4 RSA/SHA1 signature: BAD, key ID caff6a70
    Header SHA1 digest: OK (b5b20de6976c9a43fb8b00205720648cedc7620f)
    V4 RSA/SHA1 signature: BAD, key ID caff6a70
    MD5 digest: OK (15c8575889d5f1bf97f8035e2bcd7aa3)
D: May free Score board((nil))

6.) Try to sign again:

[lkundrak@jesus devel]$ rpm -vv --addsign ovaldi-5.4.2-2.fc10.src.rpm 
Enter pass phrase: 
Pass phrase is good.
ovaldi-5.4.2-2.fc10.src.rpm:
D: Expected size:      4977143 = lead(96)+sigs(1296)+pad(0)+data(4975751)
D:   Actual size:      4977143
gpg: WARNING: standard input reopened
D: GPG sig size: 543
D: Got 543 bytes of GPG sig
gpg: WARNING: standard input reopened
D: GPG sig size: 543
D: Got 543 bytes of GPG sig
D: Signature: size(1856)+pad(0)
D: May free Score board((nil))

7.) Another V4 RSA/SHA1 got added instead of replacing the existing one:
(I can add as many as I want to...)

[lkundrak@jesus devel]$ rpm -vv --checksig ovaldi-5.4.2-2.fc10.src.rpm 
D: Expected size:      4977703 = lead(96)+sigs(1856)+pad(0)+data(4975751)
D:   Actual size:      4977703
ovaldi-5.4.2-2.fc10.src.rpm:
    Header V4 RSA/SHA1 signature: BAD, key ID caff6a70
    Header SHA1 digest: OK (b5b20de6976c9a43fb8b00205720648cedc7620f)
    V4 RSA/SHA1 signature: BAD, key ID caff6a70
    V4 RSA/SHA1 signature: BAD, key ID caff6a70
    MD5 digest: OK (15c8575889d5f1bf97f8035e2bcd7aa3)
D: May free Score board((nil))

8.) The signatures are of "MD5 PGP" type, not "gpg" as expected:

[lkundrak@jesus devel]$ rpm --checksig ovaldi-5.4.2-2.fc10.src.rpm 
ovaldi-5.4.2-2.fc10.src.rpm: RSA sha1 MD5 PGP MD5 PGP md5 NOT OK
[lkundrak@jesus devel]$
Comment 1 Panu Matilainen 2008-07-14 08:43:30 EDT
sec   4096R/CAFF6A70
      ^^^^

Probably related, if not entirely equal, to bug 436812.
Comment 2 Lubomir Rintel 2008-07-14 11:44:12 EDT
Maybe.

However, for me the key verification succeeds:

[lkundrak@trurl ~]$ rpm --addsign collectd-4.4.0-0.centos5.src.rpm
Enter pass phrase: 
Pass phrase is good.
collectd-4.4.0-0.centos5.src.rpm:
gpg: WARNING: standard input reopened
gpg: WARNING: standard input reopened
[lkundrak@trurl ~]$ 
[lkundrak@trurl ~]$ rpm --checksig collectd-4.4.0-0.centos5.src.rpm
collectd-4.4.0-0.centos5.src.rpm: rsa sha1 (md5) pgp (md5) pgp md5 OK
[lkundrak@trurl ~]$ 

I'll try with a shorter key.
Comment 3 Lubomir Rintel 2008-07-14 11:55:07 EDT
2048b key works well for me. Thanks.
Comment 4 Panu Matilainen 2008-07-14 12:24:50 EDT
Ok so it is at least somewhat related, thanks for testing it. I'll need to see
what the deal with 4096 keys is one of these days...
Comment 5 Jeff Johnson 2008-07-14 14:03:55 EDT
Note that rpm has always hysterically confused implementation with algorithm.

So "PGP" is a synonym for "RSA" in ancient rpm speak.

Its taken years and years of careful tag changes to dig out of the
ancient hysterical implementation <-> algorithm confusion for
RPM signatures.

FWIW, 4096b RSA keys went in after rpm-4.4.2, the rpm.org code base starting
point, and the necessary changes have not been integrated afaik. WORKEDFORME
when I tested, but you most definitely want something other that a 4096b RSA
key, there's way too much borkage around.

Or release updates for rpm, I dare you! ;-)
Comment 6 Jeff Johnson 2008-07-14 15:12:47 EDT
I should be more careful:
   "PGP" is/was a synonym for "RSA/MD5"
because that is what was implemented in pgp in 1997 munitions.

The --checksig spewage has never been particularly informative ...

Note that RSA signatures rmay equire support for additional digest algorithms
implemented in rpm as well. gpg signing, but rpm verifying, always assumes
that rpm has same algos implemented as gpg does.

E.g. RSA/tiger192 signatures are unverifiable because there's no support (iirc) for tiger192 digests
through NSS.
Comment 7 Bug Zapper 2009-06-09 22:04:13 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2009-07-14 10:34:10 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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