GNOME Bugzilla – Bug 670698
bluez: mismatching checksum
Last modified: 2012-02-24 16:18:44 UTC
I get this: *** Checking out bluez *** [46/230] wget --continue http://www.kernel.org/pub/linux/bluetooth/bluez-4.87.tar.gz -O /home/wena/src/bluez-4.87.tar.gz --2012-02-23 19:07:45-- http://www.kernel.org/pub/linux/bluetooth/bluez-4.87.tar.gz Resolving www.kernel.org (www.kernel.org)... 149.20.4.69 Connecting to www.kernel.org (www.kernel.org)|149.20.4.69|:80... connected. HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable The file is already fully retrieved; nothing to do. *** Error during phase checkout of bluez: file hash is incorrect (expected 86afb988935e5385fb22ea0893f269f870d6f78b18aaccea6d4d0e253e2f241b, got 04d423681836ea8e9daf48f89e6215fde0fbd45ebe2b7f103579f4b78a26e799) *** [46/230] On another note, how about using the xz tarball instead? Is JHBuild able to extrac that format?
Same.
This is quite suspicious considering the last time our moduleset was changed was in September. I wonder if something odd happened on kernel.org...
<speculation> Maybe the tarballs were rebuilt. That's because I saw some xz tarballs, so any of you guys can confirm if you have seen such tarballs back then (September 2011). </speculation>
I managed to grab an old version of the tarball from fedora's servers that seem to agree with our checksum. I compared it to the one that kernel.org is currently serving up and the difference is quite trivial: -00000000 1f 8b 08 00 3a 04 3f 4d 02 03 ec fd 7b 5f 1b 47 |....:.?M....{_.G| +00000000 1f 8b 08 00 61 bd f3 4e 02 03 ec fd 7b 5f 1b 47 |....a..N....{_.G| I doubt there are any security implications here, but something strange is going on. I wonder if this is caused by the fact that we were using fedora as a kernel.org mirror while the site was down and recently switched back. fedora could have had a corrupted package all along and only now are we seeing the true original. I'm not sure if this was the case for bluez or only for gudev, though...
It could be the case. The signature is made against the uncompressed .tar file and both the old and new versions decompress to exactly the same content. My theory about fedora is definitely incorrect -- non-fedora mirror sites are also showing the old data.
If it's a very small difference, it could be in the gzip timestamp. (gzip timestamps were a *terrible* idea. Fix the world to use gzip -n)
assuming the changed 4 bytes are a timestamp in little endian: >>> datetime.datetime.fromtimestamp(0x4d3f043a) datetime.datetime(2011, 1, 25, 12, 11, 22) >>> datetime.datetime.fromtimestamp(0x4e3fbd61) datetime.datetime(2011, 8, 8, 6, 41, 37) looks pretty plausible.
>>> datetime.datetime.fromtimestamp(0x4ef3bd61) datetime.datetime(2011, 12, 22, 18, 29, 37) sorry. transposed some digits in the hex. December 22 2011 is indeed the date on the files currently on the server...
Created attachment 208360 [details] [review] core-3.4: switch bluez to using tar.xz kernel.org's standard operating procedures sometimes involve compressed tarballs being regenerated from the uncompressed form. gzip, by default, stores a timestamp of when this happened. This can cause the checksum of the .tar.gz file to spuriously change (as just happened with bluez-4.87). xz doesn't share this behaviour, so switch to using the .tar.xz file instead. I talked to the kernel.org sysadmin and he said that this was probably caused by the re-uploading that has been going on lately. It is to be expected and it may happen again (for example, their policies require that packages are reuploaded if the maintainer's key is revoked). The best way for us to avoid future problems is to not use .tar.gz.
Attachment 208360 [details] pushed as 9fcb44f - core-3.4: switch bluez to using tar.xz