Description of problem: rpm --addsign broken with some large rpms. I have tried to sign a JDK rpm with my private keys, rpmsign succeeds, but can not be verified. Version-Release number of selected component (if applicable): RHEL-5.3 gnupg-1.4.5-14 rpm-4.4.2.3-9.el5 rpm-libs-4.4.2.3-9.el5 How reproducible: 100% Steps to Reproduce: 1. make your private keys ~]# gpg --gen-key ### answer everything with default value. ~]# gpg --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 1024D/2893A5EB 2009-08-17 [expires: 2014-08-16] uid RPM Admin <admin> sub 2048g/13D5232B 2009-08-17 [expires: 2014-08-16] ~]# gpg --export -a > 1 && rpm --import 1 2. vim ~/.rpmmacros add line below %_gpg_name RPM Admin <admin> 3. get rpm from http://ftp.scientificlinux.org/linux/scientific/53/x86_64/updates/security/jdk-1.6.0_13-fcs.x86_64.rpm or extrace from offical jdk-6u13-linux-x64-rpm.bin ( java.sun.com ) ]# md5sum jdk-1.6.0_13-fcs.x86_64.rpm 389ba742fe401375c174d28c4e6b66bf jdk-1.6.0_13-fcs.x86_64.rpm ]# md5sum jdk-6u13-linux-amd64.rpm 389ba742fe401375c174d28c4e6b66bf jdk-6u13-linux-amd64.rpm the rpm is not signatured by anyone before. ~]# rpm -qpi jdk-1.6.0_13-fcs.x86_64.rpm Name : jdk Relocations: /usr/java Version : 1.6.0_13 Vendor: Sun Microsystems, Inc. Release : fcs Build Date: Tue 10 Mar 2009 05:19:29 AM CST Install Date: (not installed) Build Host: jdk-lin-amd64.sfbay.sun.com Group : Development/Tools Source RPM: jdk-1.6.0_13-fcs.src.rpm Size : 139414757 License: Sun Microsystems Binary Code License (BCL) Signature : (none) Packager : Java Software <jre-comments.com> URL : http://java.sun.com/ Summary : Java(TM) Platform Standard Edition Development Kit 4. sign it and verify rpm --addsign jdk-1.6.0_13-fcs.x86_64.rpm rpm -K jdk-1.6.0_13-fcs.x86_64.rpm Actual results: jdk-1.6.0_13-fcs.x86_64.rpm: (SHA1) DSA md5 gpg NOT OK Expected results: jdk-1.6.0_13-fcs.x86_64.rpm: (SHA1) DSA md5 gpg OK Additional info: signature with other small rpms is ok.
I am having the exact same problem signing the Sun jdk rpm: Sign the package via: $ rpmsign --resign package.rpm No errors, then trying to install it via yum fails with this error message: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 348aec7e yet, I do have my key, with the ID it complains about, installed: $ rpm -q gpg-pubkey-348aec7e-40ca17fa gpg-pubkey-348aec7e-40ca17fa.(none) ~Jason
Same problem here. Guys, do you have any workarounds?
See bug 463482. The best workaround in more than one way is to repackage the broken Sun JDK/JRE packages with spec from http://jpackage.org/, that gives you far saner packages which can also be signed.
This bug is still present in RHEL6.2 and is preventing packages to be imported into Satellite/Spacewalk
As explained in bug 463482, the issue is that the older Sun (well, Oracle these days) JRE/JDK packages are rpm V3 format, which cannot be signed with rpm >= 4.x. The actual bug here is that --addsign claims success when this is what you should get (its been fixed in later rpm versions): [pmatilai@localhost tmp]$ rpm --addsign jdk-1.6.0_13-fcs.x86_64.rpm Enter pass phrase: Pass phrase is good. jdk-1.6.0_13-fcs.x86_64.rpm: error: Cannot sign RPM v3 packages
Well, that was true with the older JDK rpm's, but these days Sun/Oracle is doing version 4 rpms: rpm -q --qf '%{RPMVERSION}\n' -p /tmp/jdk-hold/jdk-1.6.0_33-fcs.i586.rpm 4.0.4 So any reason rpm can't sign a 4.0.4 rpm correctly? Or is it a size issue as mentioned earlier in this bug? what rpm version will report when it can't really sign? rpm 4.8.0 from rhel 6 didn't whine.
my bad. If I go to the newest EL5 rpm I can sign the 4.0.4 package fine. *sigh* Sun/Oracle ships the i586 rpm as 4.0.4, the x86_64 one as 3.0.6. so not an rpm/yum issue. this is an Oracle drain bamage issue. We'll see if we can get them to fix their 64bit rpm.
Ran into same issue here: $ rpm -q --qf '%{RPMVERSION} %{BUILDHOST}\n' -p jdk-6u35-linux-amd64.rpm jdk-6u35-linux-i586.rpm warning: jdk-6u35-linux-amd64.rpm: Header V3 RSA/SHA1 signature: NOKEY, key ID 4fa2c6aa 3.0.6 jdk-lin-amd64.sfbay.sun.com 4.0.4 jdk-lin-i586.us.oracle.com so at least latest Java 6 version for 64-bit is still build on an older system (probably RHEL4) than the 32-bit...
Yes, Oracle is still shipping a bad (well really old) 64bit RPM. the issue is with Oracle and not with RedHat. I have contacted Oracle support channels and they were going to look into it. they seemed a bit surprised that the 64bit RPM is a version 3 RPM. It has been a while since I have heard back from them though... oh, and whatever box Oracle is using for the 64bit builds, it is older that rhel4. even el3 had rpm4.
(In reply to comment #9) > oh, and whatever box Oracle is using for the 64bit builds, it is older that > rhel4. even el3 had rpm4. Oh, before I've run more investigation, does anyone remember quickly the last RedHat (Enterprise) distribution which was based on rpm < 4 - looks for signing such packages, a Linux version near to Stone Age must be used :-(
I don't think any RHEL was RPM < 4. I couldn't find the SRPMS for 2.1 online, so pulled out the old install media from the bookshelf. RHEL 2.1ES shipped RPM 4.0.4. from some more poking, looks like you have to go back to RHL 6.2 for RPM 3 :).
The java 7 x86_64 packages seem to be built with a workable version of rpm: $ rpm -qp --qf '%{NEVRA} rpmver:%{RPMVERSION} buildhost:%{BUILDHOST}\n' j* jdk-2000:1.7.0_09-fcs.x86_64 rpmver:4.4.2.3 buildhost:jdk7-lin-amd64 jre-1.7.0_09-fcs.x86_64 rpmver:4.4.2.3 buildhost:jdk7-lin-amd64 Of course this doesn't help those of us on java 6. Steven, you mentioned contacting Oracle support (as this certianly not a RHEL bug, but an Oracle one), do you have a reference number for this request so others can follow along?
Sorry, it isn't via a publicly available support interface. I'm not even sure if the Oracle support interface is publicly viewable. It is through some private work contacts we have due to us being a RDBMS customer of theirs.
As RHEL5 enters its production phase 2 changes are limited to critical issues only, Adding new features as support for these ancient rpm v3 packages is out of the scope of all upcomming REHL 5 releases. Sorry. In RHEL6 this is at least fixed to the point of giving a proper error message.