[CentOS-devel] kdebindings-3.5.4-6.el5.src.rpm seems to be wrong

[Jeff Johnson]

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