Description of problem:
When I sign a package with a 4096bit RSA key, rpm does not complain, but rpm
reports, that the signature is invalid when checking it.
Version-Release number of selected component (if applicable):
rpm-4.4.2.2-7.fc8
How reproducible:
always
Steps to Reproduce:
1. create 4096 bit RSA keys with gpg
2. sign a rpm package with this key with "rpm --addsign *.rpm" (~/.rpmacros may
need to be setup)
3. import public gpg into rpm: "rpm --import path/to/public-gpg-key"
4. verify signature: "rpm --checksig *.rpm"
Actual results:
[...]
V3 RSA/SHA1 signature: BAD, key ID abcdefg
[...]
Expected results:
rpm should report the signature as OK or deny to sign the package when it cannot
handle it and mention this in the documentation.

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

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.

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.

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.

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.

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

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.

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