On Apr 21, 2009, at 5:41 PM, Karanbir Singh wrote:
On 04/21/2009 08:30 PM, Farkas Levente wrote:
hi, it's something strange (even if i double reload from different mirror sites). it seems to be good:
# rpm -K kdebindings-3.5.4-6.el5.src.rpm kdebindings-3.5.4-6.el5.src.rpm: (sha1) dsa sha1 md5 gpg OK
but the src.rpm still contains invalid source:
we are trying to work out why this is the way it is - Jeff's feedback re: the rpm would help, in the mean time we might have found a bug in rsync itself. I've manually pushed in a resigned package that should be visible shortly, that should fix the issue.
Once we have a clearer idea as to what caused this issue to come up, I'll post again with details and also how we might make sure this sort of a thing is better tracked for.
Hmmm, this seems to be the issue:
rpm2cpio /tmp/kdebindings-3.5.4-6.el5.src.rpm | cpio -itv -rw-r--r-- 1 root root 615 Sep 9 2004 kde-libtool.patch -rw-r--r-- 1 root root 603 Nov 18 2004 kdebindings-3.1- python2.4.patch -rw-r--r-- 1 root root 742 Sep 9 2004 kdebindings-3.1- ssl-krb5.patch -rw-r--r-- 1 root root 217 Sep 9 2004 kdebindings-3.3.0-python.patch -rw-r--r-- 1 root root 876 Mar 1 2005 kdebindings-3.3.92-xdg.patch -rw-r--r-- 1 root root 5416588 Aug 10 2006 kdebindings-3.5.4.tar.bz2 cpio: premature end of file
My 1st guess is that kdebindings-3.5.4.tar.bz2 got clobbered (perhaps by a 2nd SRPM install?) while being built.
Since all the digests/signatures verify w rpm -Kvv:
/tmp/kdebindings-3.5.4-6.el5.src.rpm: Header V3 DSA signature: OK, key ID e8562897 Header SHA1 digest: OK (bd47bcf5840446eac55cbf51ef09cc5c8a37a79b) MD5 digest: OK (775978cfa249016a57512534cb005af6)
that pretty much means that the SRPM got packaged okay, and no damage from rdist or other transport occurred. Digests do not lie.
But there is a window between when RPMTAG_FILESIZES is populated in the metadata, and when the file is actually written to the payload that leads me to guess "clobbered while building".
I can likely add a check to close the window if this problem isn't a unique one-time occurrence.
Do you have any more of these flaws?
My 2nd guess is that the SRPM got truncated between building and signing. I fergit (can/will look if my 2nd guess is more plausible than my 1st) whether digests are recalculated during signing. Hmmm, the digests likely are recalculated during signing, that would explain.
Its easy enough to create a reproducer:
1) build some package 2) use dd to truncate some of the payload. 3) sign the package 3) verify the signature.
Procedurally, run rpm -Kvv on the original content before signing if the 2nd guess reproduces the flaw. Reject (and don't sign) any packages that fail initially.
(aside) BTW, the previous "chlorox'ed" problem I alluded too exercises a different window. If you redefine the desired compression using %define in a spec file, then its possible to generate a *.rpm that claims to be compressed but actually is not.
The window is between when rpm decides what payload compression to use, and when the %define override is encountered in the spec file.
Don't do that! is my current "fix", but I can add mandatory/enforcing policy if needed. E.g. (with @rpm5.org) its possible to make macros read-only before parsing the spec file so that they cannot be changed by %define's encountered within a spec file.
hth
73 de Jeff