PDA

View Full Version : Broken RPM packages in SLE11-SDK-SP3-Pool



ihopenscape
23-Feb-2016, 15:51
Hi,

we encounterd an error with a few RPM Signatures on the SDK Repo. Hope i am right here.

When we try to install the following packages:

1/6 : gnome-libs-1.4.2-11.23-0.x86_64
2/6 : libXiterm-devel-0.5.20040304-259.27-0.x86_64
3/6 : libunwind-0.98.6-26.6-0.x86_64
4/6 : libgladeui-1-8-3.5.2-8.17-0.x86_64
5/6 : perl-HTML-Template-JIT-0.05-2.6-0.x86_64
6/6 : python-ply-doc-2.5-1.17-0.x86_64

i get an error with the Signatures of the RPMs.

Download and verify the Files from https://nu.novell.com/repo/$RCE/SLE11-SDK-SP3-Pool/sle-11-x86_64/rpm/x86_64/
with rpm -K shows (Example):
>rpm -K python-ply-doc-2.5-1.17.x86_64.rpm
error: python-ply-doc-2.5-1.17.x86_64.rpm: rpmReadSignature failed: sigh load: BAD

Thanks in advance,
Robin

ihopenscape
23-Feb-2016, 16:04
Seems like it is related to rpm version.

it works just fine with version 4.4.2.3
and won't work with version 4.8.0

Maybe its related to:
https://bugzilla.redhat.com/show_bug.cgi?id=822255

Regards,
Robin

ab
23-Feb-2016, 16:34
I do not know how to verify the RPM other than by testing. On my openSUSE
box, which has RPM 4.11.1, I do not get any errors coming from this package:



> rpm -K ./python-ply-doc-2.5-1.17.x86_64.rpm
../python-ply-doc-2.5-1.17.x86_64.rpm: rsa sha1 (md5) pgp md5 OK


My SLES 12 SP1 (rpm 4.11.2) box also shows no signature errors, though I
do not have the key imported to be trusted there:



python-ply-doc-2.5-1.17.x86_64.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK
(MISSING KEYS: (MD5) PGP#307e3d54)


After I import the key from the repo, things seem to be fine on that
system too:



python-ply-doc-2.5-1.17.x86_64.rpm: rsa sha1 (md5) pgp md5 OK


As a result, I'd verify you have the correct file, not corrupted, and the
correct key trusted.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

ihopenscape
24-Feb-2016, 13:10
On my centos 7 box with rpm 4.11.3 and on RHEL with rpm 4.8.0 I've got the same error:

[color=blue]
> rpm --version
RPM-Version 4.11.3
> rpm -K python-ply-doc-2.5-1.17.x86_64.rpm
error: python-ply-doc-2.5-1.17.x86_64.rpm: rpmReadSignature failed: sigh load: BAD


In my working example i also used a SLES box and in the broken example i used centos.
So it seems like only the RPM shipped with centos is affected. I try to do further research to be clear under which cirumstaces the Problem appears.

Regards,
Robin

ihopenscape
24-Feb-2016, 13:49
Ok it seems like the Problem is clearly related to the rpm-4.8.x-region-size.patch which is included in centos .src.rpm.
I try to rebuilding and installing the RPM without the specified patch and the verification works.

the patch is not included (at least in opensuse repos .src.rpm 4.8.0 and 4.10.2)


>cat rpm-4.8.x-region-size.patch
commit 74c98b038b24f46bed7e961225d2b11b56a699ae
Author: Panu Matilainen <pmatilai@redhat.com>
Date: Thu Jan 19 11:03:12 2012 +0200

Fix region length calculation and sanity check against header size

- When calculating length of dribbles, we need to take into account the
size up to that point, otherwise the alignment can be wrong causing
the sizes not to add up.
- With the sizes now correctly calculated, verify the sizes match up

diff --git a/lib/header.c b/lib/header.c
index 2d68854..4ef7564 100644
--- a/lib/header.c
+++ b/lib/header.c
@@ -853,13 +853,12 @@ Header headerLoad(void * uh)
indexEntry newEntry = entry + ril;
int ne = (h->indexUsed - ril);
int rid = entry->info.offset+1;
- int rc;

/* Load dribble entries from region. */
- rc = regionSwab(newEntry, ne, 0, pe+ril, dataStart, dataEnd, rid);
- if (rc < 0)
+ rdlen = regionSwab(newEntry, ne, rdlen, pe+ril,
+ dataStart, dataEnd, rid);
+ if (rdlen < 0)
goto errxit;
- rdlen += rc;

{ indexEntry firstEntry = newEntry;
int save = h->indexUsed;
@@ -881,6 +880,11 @@ Header headerLoad(void * uh)
h->indexUsed += ne;
}
}
+
+ rdlen += REGION_TAG_COUNT;
+
+ if (rdlen != dl)
+ goto errxit;
}

h->flags &= ~HEADERFLAG_SORTED;

Question is if the patch is broken or if the signature is broken :/

ab
24-Feb-2016, 15:46
If there is something I can do to test specifically, please let me know.
So far I cannot detect the problem, or work out how to do manual
verification of the package in a way that makes sense, so I'm kind of suck
assuming things are working since much-later versions of 'rpm' are
reporting a proper package. The bug you mentioned originally was from
2012, and I see much newer code in my 'rpm' package's changelog.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

ihopenscape
16-Mar-2016, 14:07
Thanks for your help so far and sorry for my late Response :)

No more need to test since I can clearly relate the Problem to the patch I mention before. Since we are switching to SP3 in the near future we can live with the behavior of rpm. (Problem not appear with packages in SP3 repo)

The question is if the patch is broken or if the signatures are broken. I cannot tell and I am not sure where to fill a bug report :/

Regards,
Robin

ab
16-Mar-2016, 14:45
On 03/16/2016 07:14 AM, ihopenscape wrote:
>
> No more need to test since I can clearly relate the Problem to the patch
> I mention before. Since we are switching to SP3 in the near future we
> can live with the behavior of rpm. (Problem not appear with packages in
> SP3 repo)

Maybe they were broken back then, which would make a little sense I
suppose. Since I cannot duplicate it with old or new systems, I cannot tell.

> The question is if the patch is broken or if the signatures are broken.
> I cannot tell and I am not sure where to fill a bug report :/

If the problem only exists prior to SP3 you'll likely not get a fix unless
on SP3 LTSS or SP4, and in those cases you already do not see the problem.
At this point I'd continue moving there and stick with the workaround in
the meantime.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...