Summary: | dev-libs/glib-2.16.3 digest verification failed proven with multiple mirrors | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juan Luis <Skirmitch> |
Component: | [OLD] Unspecified | Assignee: | Mirror Admins <mirror-admin> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Juan Luis
2008-07-31 19:03:12 UTC
*** Bug 233518 has been marked as a duplicate of this bug. *** Just merging an ebuild when the hash doesn't match isn't really careful. Especially in these days of unsafe dns servers. A malicious attack aside, this may just be a mirror issue, which seems to be likely, given that the Michigan Univerity mirror isn't even reachable for me. The expected hash is correct. Just FYI: Fetching the file from http://mirrors.cs.wmich.edu/gentoo/distfiles/glib-2.16.3.tar.bz2 worked here, and the resultant file was identical to the one fetched about a month ago up to the timestamp, 2008-04-10 04:24:08 UTC. Both files have the expected RIPEMD160 hash: /tmp $ openssl dgst -rmd160 /usr/portage/distfiles/glib-2.16.3.tar.bz2 /tmp/glib-2.16.3.tar.bz2 RIPEMD160(/usr/portage/distfiles/glib-2.16.3.tar.bz2)= 72260f5f9022ee3f97b79b5705ad6117adc279fd RIPEMD160(/tmp/glib-2.16.3.tar.bz2)= 72260f5f9022ee3f97b79b5705ad6117adc279fd To me it would seem that either 1) the problem was in the mirror and has now been corrected or 2) the hash calculation routine was broken by something in the monodevelop dependencies Can you still reproduce, and, can you tell us from what mirror do you sync? (In reply to comment #4) > Can you still reproduce, and, can you tell us from what mirror do you sync? > Tomorrow i'll try to reproduce it but i replaced the mirrors for working ones, the sync info is easy: sync'ed with every single sync mirror i know. |