Bug 436812

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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

still present in F10: rpm-4.6.0-0.rc1.8

I have similar problems with kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm package by Matthias Hensler.

When trying to check this package on system without his key:
rpm --checksig kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm
kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm: sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS:(MD5) PGP#22b2951d)

And on system with key:
rpm --import SUSPEND2-RPM-KEY
rpm --checksig kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm
kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm: sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS:(MD5) PGP#16fdb298)

It's curious, that there is an unknown key 16fdb298.

Do you have a URL pointer to the signed kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm
package?

Ah, there its is

http://mhensler.de/swsusp/download/yum/fc10/kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm

But the package at that URL is not signed ...

... a URL for a package signed with a 4096bit RSA key, and a pubkey, are
needs to attempt a reproducer.

It is signed with this key:
http://mhensler.de/swsusp/download/SUSPEND2-RPM-KEY

You have right package, just it's not signed by standard fedora keys.

The suspend2 key is not a 4096 bit key:

$ gpg --with-fingerprint --keyid-format long SUSPEND2-RPM-KEY
pub  1024R/86A0081B22B2951D

But I see the same problems with the kernel-tuxonice on my Fedora 10. But this is another bug then the one I reported:

Unsigned package:
http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.unsigned

Signed package:
http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm

Public Key:
http://till.fedorapeople.org/4096-RSA-rpm-bug/RPM-GPG-KEY-opensource-till-name-2007-06-22

Steps to reproduce:
This uses a local rpm database in $PWD/rpm-db to make it possible to reproduce this without being root or compromising the own rpm database with untrusted keys:

1. rpm --verbose --dbpath $PWD/rpm-db --import http://till.fedorapeople.org/4096-RSA-rpm-bug/RPM-GPG-KEY-opensource-till-name-2007-06-22

2. LANG=C rpm --verbose --dbpath $PWD/rpm-db --checksig http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm

http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm:
    Header V4 RSA/SHA512 signature: BAD, key ID 1c109517
    Header SHA1 digest: OK (b3398044a25fe5bc5e4c5bded44c0dd5d10e13db)
    V4 RSA/SHA512 signature: BAD, key ID 1c109517
    MD5 digest: OK (f16dd8cfcf437beb6d467e4f652c6bbd)

3.
LANG=C rpm --verbose -qip http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm

error: http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm: Header V4 RSA/SHA512 signature: BAD, key ID 1c109517
error: http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm: not an rpm package (or package manifest)

Here is also a sha1 signed rpm package, that does not work:
http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.sha1signed

The algorithms implemented (@rpm5.org, I don't use Fedora rpm) verify
with RSA/SHA1 using 1024/2048/4096 bit keys and the NSS implementation
through the clearsigned signature(...) probe dependency.

And I suspect that a *.rpm package signed with a V3 rather than a V4 gpg
signature using RSA/MD5 will verify correctly.

However, there appears to be an issue with RSA fingerprint generation, the V4 fingerprint
is defined differently than the V3 fingerprint for RSA keys, and so pubkeys are
not being retrieved correctly.

There's also apparently a flaw with the plaintext used for RSA signatures.

Here's the relevant details (from RFC 4880 section 12.2) re RSA fingerprint definition
with V3/V4 keys:

   Also note that if V3 and V4 format keys share the same RSA key
   material, they will have different Key IDs as well as different
   fingerprints.

   Finally, the Key ID and fingerprint of a subkey are calculated in the
   same way as for a primary key, including the 0x99 as the first octet
   (even though this is not a valid packet ID for a public subkey).

The verification in RPM assumes V3 RSA signatures for hysterical reasons.

So this "bug" is mostly a feature request, not otherwise.

With V3 signatures, at least rpm -qip works, but --checksig still does not:

LANG=C rpm --verbose --dbpath /home/till/4096-RSA-rpm-bug/rpm-db --checksig http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_md5

http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_md5:                                                                           
    Header V3 RSA/MD5 signature: BAD, key ID 1c109517                                                                                                                      
    Header SHA1 digest: OK (b3398044a25fe5bc5e4c5bded44c0dd5d10e13db)                                                                                                      
    V3 RSA/MD5 signature: BAD, key ID 1c109517
    MD5 digest: OK (f16dd8cfcf437beb6d467e4f652c6bbd)

LANG=C rpm -qip http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_md5
warning: http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_md5: Header V3 RSA/MD5 signature: NOKEY, key ID 1c109517
Name        : obsoletes-test               Relocations: (not relocatable)
Version     : 1                                 Vendor: (none)
Release     : 1.tillf8                      Build Date: Thu Dec 11 22:14:37 2008
Install Date: (not installed)               Build Host: localhost
Group       : T                             Source RPM: obsoletes-test-1-1.tillf8.src.rpm
Size        : 0                                License: T
Signature   : RSA/MD5, Fri Dec 12 13:34:35 2008, Key ID 6a3a10b31c109517
URL         : T
Summary     : T
Description :

http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_sha512
http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.v3signed_sha1

But maybe I am doing something wrong here.

(In reply to comment #10)

> The verification in RPM assumes V3 RSA signatures for hysterical reasons.
> 
> So this "bug" is mostly a feature request, not otherwise.

If this is the case, then rpm should pass --force-v3-sigs to gpg when using --addsign.

I created the last signed packages with this setup:

I put this in ~/.rpmmacros, because in contradiction to the manpage, rpm does not use %_gpgbin afaics:

%__gpg /home/till/bin/rpm-gpg.sh

This is the contents of my wrapper script:

#! /bin/bash
echo "$@" >> /home/till/rpm-gpg-debug
exec /usr/bin/gpg --force-v3-sigs --digest-algo=sha1 "$@"

I adjusted the --digest-algo for md5 and left it away for sha512.

Re
> If this is the case, then rpm should pass --force-v3-sigs to gpg when using
> --addsign.

The gpg signing invocation used by rpm is entirely configurable with macros:

%__gpg_sign_cmd                 %{__gpg} \
        gpg --batch --no-verbose --no-armor --passphrase-fd 3 --no-secmem-warning \
        -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}

Feel free to do whatever you wish. I supplied the hysterical details re V3 RSA signatures
for reference purposes.

Note that however this #436812 featlet/bugture is resolved, most rpm implementations
in "production" do not correctly handle RSA V4 signatures.

(aside)
You'ld think a package signer would verify that, indeed, a package verifies after signing
    rpm -Kvv *.rpm
rather than just releasing, wouldn't ya?

Personally I'd rather see the RPM crypto implementation "Just Work" rather than limit
the functionality to V3 signatures only. But that also means that rpm verification will need
every algorithm that might ever be used by gpg when signing, including
MD2/tiger192 hashes and ECDSA and odd-ball variants of DSA with q={224,256} bits > 1024 and
(likely soon) RSA/MD6 or whatever is chosen from the SHA-3 competition.

Re
> However, there appears to be an issue with RSA fingerprint generation, the V4
> fingerprint
> is defined differently than the V3 fingerprint for RSA keys, and so pubkeys are
> not being retrieved correctly.

Good, the RSA V4 fingerprint generation has been fixed @rpm5.org in the last year.
Now to see what is b0rken with the plaintext being signed; the plaintext hash is
conventionally salted with pubkey parameters per RFC 4880.

And then onto beecrypt/openssl/gcrypt algorithm implementation testing ...

(In reply to comment #12)
> Re
> > If this is the case, then rpm should pass --force-v3-sigs to gpg when using
> > --addsign.
> 
> The gpg signing invocation used by rpm is entirely configurable with macros:
> 
> %__gpg_sign_cmd                 %{__gpg} \
>         gpg --batch --no-verbose --no-armor --passphrase-fd 3
> --no-secmem-warning \
>         -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}
> 
> Feel free to do whatever you wish. I supplied the hysterical details re V3 RSA
> signatures
> for reference purposes.

Except that this is not what is written in the manpage, but I filed a different bug about this. (bug: 476201). Also the interface is not documented. Is it also possible to make rpm not ask for the password? It always does, even if I change the gpg command to use the agent instead.

> Note that however this #436812 featlet/bugture is resolved, most rpm
> implementations
> in "production" do not correctly handle RSA V4 signatures.

Unless the rpm in Fedora does not break packages if it does not like the signature.

> (aside)
> You'ld think a package signer would verify that, indeed, a package verifies
> after signing
>     rpm -Kvv *.rpm

This beheaviours seems to depend on the rpm version used, so maybe it worked for the package signer.

(In reply to comment #12)

> Personally I'd rather see the RPM crypto implementation "Just Work" rather than
> limit
> the functionality to V3 signatures only. But that also means that rpm
> verification will need
> every algorithm that might ever be used by gpg when signing, including
> MD2/tiger192 hashes and ECDSA and odd-ball variants of DSA with q={224,256}
> bits > 1024 and
> (likely soon) RSA/MD6 or whatever is chosen from the SHA-3 competition.

I agree here.

Re

> Except that this is not what is written in the manpage ...

And is also not what is written in either of the 2 books written about rpm.
There's far more than the man page that needs changing if accurate RPM doco
is deemed important.

Personally %_gpgbin was just stoopidness from ~2000 and not worth fussing imho,
but other opinions are rampant, yours != mine.

Legacy compatibility with hysterically accurate RPM doco can be retrofitted with
    %__gpg    %_gpgbin
if one wishes anytime.

There is certainly no way to change already released documentation everywhere.

I've finished wiring up RSA signature checking algorithms using -lgcrypt and -lopenssl
(as well as -lbeecrypt and -lnss) @rpm5.org.

RSA/SHA1 w 4096bit keys  algorithms are verifying using
    Requires: signature(...)
probes on clear/detached signed plaintext are all functional @rpm5.org. So the algorithms
and much of the digital signature verification implementation is correct.

re comment #7: I'm not seeing a signature tag in the tuxonice package that I have downloaded.

re comment #8:Thanks for the reproducer. I'm seeing this behavior now:

$ rpm -Kvv obsoletes-test-1-1.tillf8.noarch.rpm 
D: Expected size:         2435 = lead(96)+sigs(1296)+pad(0)+data(1043)
D:   Actual size:         2435
obsoletes-test-1-1.tillf8.noarch.rpm:
    Header V4 RSA/SHA512 signature: BAD, key ID 1c109517
    Header SHA1 digest: OK (b3398044a25fe5bc5e4c5bded44c0dd5d10e13db)
    MD5 digest: OK (f16dd8cfcf437beb6d467e4f652c6bbd)

So the issue for verifying RSA on *.rpm packages likely has to do with
the plaintext salting for RSA V4. There's also a chance that MD5, not
SHA1, digest is being computed for hysterical RSA V3 reasons.

Digging now ...

(In reply to comment #16)
> re comment #7: I'm not seeing a signature tag in the tuxonice package that I
> have downloaded.

What is "signature tag" ?
When trying to check signature on tuxonice kernel package, it says that there are missing key #22b2951d. How it's possible, that you don't see signature tag?

LANG=C rpm --checksig http://mhensler.de/swsusp/download/yum/fc10/kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm
http://mhensler.de/swsusp/download/yum/fc10/kernel-tuxonice-2.6.27.7-134_1.cubbi_tuxonice.fc10.i686.rpm: sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS:(MD5) PGP#22b2951d)

A signature tag is what carries the RSA signature in metadata.

The likeliest explanation for my not seeing atm is that I'm
looking a different download package than you are. I
tried several download sites.

No worries, that's lots wrong with RSA verification of *.rpm packages, I'm
drilling through the muck now. I'll re-verify the tuxonice RSA
signature from the URI you have given as part of my implementation.

(In reply to comment #18)
> The likeliest explanation for my not seeing atm is that I'm
> looking a different download package than you are. I
> tried several download sites.

My URL is the same as in comment #5.

I don't know about other packages of same name.

Good: V4 RSA plaintext hash is now generated correctly, V3 double checked
no regression too.

Last fix is to figger why RSA on *.rpm is generating BAD, the RSA algorithms/plaintext/fingerprints
are all already verified for beecrypt/NSS/gcrypt/openssl.

All @rpm5.org, @rpm.org rpm-4.4.6 is similarly b0rken (by inspection, unchecked).

rpm-4.6, not rpm-4.4.6.

rpm-4.6.0-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/rpm-4.6.0-2.fc10

rpm-4.6.0-2.fc10 has been pushed to the Fedora 10 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 'yum --enablerepo=updates-testing update rpm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2670

How is rpm-4.6.0-2.fc10 supposed to fixing this bug, the steps I have shown here to reproduce this bug, still reproduce it:

$ LANG=C rpm --checksig --dbpath $PWD/rpm-db  obsoletes-test-1-1.tillf8.noarch.rpm
obsoletes-test-1-1.tillf8.noarch.rpm: RSA sha1 (MD5) PGP md5 NOT OK

I signed this rpm with rpm-4.6.0-2.fc10.

The signed rpm can be found here:
http://till.fedorapeople.org/4096-RSA-rpm-bug/obsoletes-test-1-1.tillf8.noarch.rpm.rpm-4.6.0-2.fc10

I also suffer the same problem with this version of RPM.

Ok well... rpm-4.6.0-2.fc10 does fix an important piece of this puzzle, without which the V4 RSA signatures have no chance of verifying correctly. The other half is that at least Till Maas' key has a subkey and this is something that rpm doesn't handle correctly at all atm, especially so for RSA.

An easy fix would to make rpm simply ignore subkeys (instead parsing them and messing up the data from the top-level key), especially as the subkeys are typically encryption-only which are not relevant to rpm anyway. With a small patch to ignore the subkeys:
[pmatilai@localhost rpm]$ ./rpm -Kv /tmp/obsoletes-test-1-1.tillf8.noarch.rpm.rpm-4.6.0-2.fc10 
/tmp/obsoletes-test-1-1.tillf8.noarch.rpm.rpm-4.6.0-2.fc10:
    Header V4 RSA/SHA512 Signature, key ID 1c109517: OK
    Header SHA1 digest: OK (b3398044a25fe5bc5e4c5bded44c0dd5d10e13db)
    V4 RSA/SHA512 Signature, key ID 1c109517: OK
    MD5 digest: OK (f16dd8cfcf437beb6d467e4f652c6bbd)

In the long term, it would be nice if gpg would also signing subkeys, because this allows to store the master signing key on an offline machine and only use the subkeys on online machines. This allows to easily revoke subkeys in case it they are compromised, but still keep the web of trust to the master signing key.

If I export only the primary signing key and import it into the rpm database, then verification of the signed rpm also works with rpm from F10.

This bug is still present in F11, rpm-4.7.0-1.fc11.x86_64. That is, I also have a RSA key with subkeys for encryption. I believe this should be common for people signing packages with their personal GPG keys, instead of using a key just for package signing.

The workaround of comment #28 works for me. Thanks Till!

Panu, can you apply you patch to the Fedora RPM and close this? Or at least publish it so I can try to post a bug upstream.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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

This bug is still present in F11 and probably in F12 as it is the same version.

Fixed upstream now (by just ignoring subkeys), leaving open for Fedora status tracking.

Should be fixed in current rawhide (rpm 4.7.2-2)

rpm-4.7.2-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/rpm-4.7.2-1.fc11

rpm-4.7.2-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.