Bugzilla Bug 121182

What you see here is the first 6 digits of the RMD160 sum for
dev-python/pycrypto/metadata.xml generated on different platforms:

          alpha   amd64   ia64    x86
2.0       b0aeda  11aff8  11aff8  b0aeda
2.0-r1    b0aeda  11aff8  11aff8  b0aeda
2.0.1     b0aeda  b0aeda  11aff8  b0aeda
2.0.1-r1  b0aeda  b0aeda  11aff8  b0aeda

So it appears that alpha is fine, amd64 was fixed in 2.0.1, and ia64 is still
broken.  Looking at RIPEMD.c, I think the programmers don't realize that "int"
means 32-bits according to the C standard, and "long" means native size of a
pointer:

#ifdef __alpha__
typedef    unsigned int        word;   /* unsigned 32-bit integer */
#elif defined(__amd64__)
typedef    uint32_t            word;   /* unsigned 32-bit integer */
#else
typedef    unsigned long        word;   /* unsigned 32-bit integer */
#endif

IMHO this should simply be:

typedef    unsigned int        word;   /* unsigned 32-bit integer */

For the moment, rather than rock the boat, I've added a patch to make ia64 work
correctly, see pycrypto-2.0.1-r2.  However I think the existing code is going
to have problems on any 64-bit architectures not specifically handled.

Btw, I assigned this to dev-portage because it affects Manifest generation. 
Feel free to reassign it as appropriate.  Mainly I'm looking for somebody to
agree or disagree with my assessment, then push it upstream

> Looking at RIPEMD.c, I think the programmers don't realize that "int"
> means 32-bits according to the C standard, and "long" means native size of a
> pointer:

it is usually safe to assume int is 32bits, but that isnt good programming imho

> IMHO this should simply be:
> 
> typedef    unsigned int        word;   /* unsigned 32-bit integer */

if you want 32bits, then you should use the uint32_t def

The proper fix ought to be to use uint32_t for all architectures.

I can confirm the bug on my ia64 machine:

# emerge -uD world
Calculating world dependencies ...done!
>>> emerge (1 of 3) sys-libs/timezone-data-2006a to /

!!! Digest verification Failed:
!!!    /usr/portage/sys-libs/timezone-data/timezone-data-2006a.ebuild
!!! Reason: Failed on RMD160 verification
!!! Got:      76142fd7417cdb675bc0a6f5d34b4979ed451237
!!! Expected: 688734ae4535c63334dabac100df4faef08ee990

BTW: Is there any way to get portage to ignore RMD160 sums?

> BTW: Is there any way to get portage to ignore RMD160 sums?

remove the RMD160 line from the digest file

> > BTW: Is there any way to get portage to ignore RMD160 sums?
> 
> remove the RMD160 line from the digest file

... and the Manifest file, and update all the other sums since the files have
changed...

That's doable for an ebuild or two, but not much more.

(In reply to comment #3)
> The proper fix ought to be to use uint32_t for all architectures.
> 
> I can confirm the bug on my ia64 machine:
> 
> # emerge -uD world
> Calculating world dependencies ...done!
> >>> emerge (1 of 3) sys-libs/timezone-data-2006a to /
> 
> !!! Digest verification Failed:
> !!!    /usr/portage/sys-libs/timezone-data/timezone-data-2006a.ebuild
> !!! Reason: Failed on RMD160 verification
> !!! Got:      76142fd7417cdb675bc0a6f5d34b4979ed451237
> !!! Expected: 688734ae4535c63334dabac100df4faef08ee990
> 
> BTW: Is there any way to get portage to ignore RMD160 sums?
> 

Not to be recommended lightly, but FEATURES="-strict" should do it also.

(In reply to comment #6)
> (In reply to comment #3)
> > BTW: Is there any way to get portage to ignore RMD160 sums?
> > 
> 
> Not to be recommended lightly, but FEATURES="-strict" should do it also.

and or.. emerge --digest foo

(In reply to comment #3)
> BTW: Is there any way to get portage to ignore RMD160 sums?

Editing /usr/lib/portage/pym/portage_checksum.py, and commenting out the line

       hashfunc_map["RMD160"] = rmd160hash

seems to do the trick.

So, we have a universal fix and now the question is who's going to fix the
package?

if Aron doesnt commit a "final" fix, i'll take care of it ...

It's in as 2.0.1-r3