BlueZ old releases have new checksums
All,
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
I pinged the upstream, but I doubt it will be changed or fixed in any way. So the proper solution for us would be to upgrade recipes to the latest released versions - bluez-4.97, obexd-0.43 and bluez-hcidump-2.2.
Are there any other suggestions?
[1] http://www.kernel.org/pub/linux/bluetooth/
Signature · 1 line
Denys
Quoted 5 lines · Denys Dmytriyenko
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
Signature · 1 line
Christopher Larson
Temporaly i've manually changed md5 and sha256sum. If needed i can prepare a patch
Adriano Pallavicino
Il giorno 04/gen/2012, alle ore 21:14, Chris Larson <[email protected]> ha scritto:
Quoted 17 lines · Denys Dmytriyenko
Quoted 5 lines
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
Signature · 6 lines
Christopher Larson _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Quoted 2 lines · Adriano Pallavicino
Temporaly i've manually changed md5 and sha256sum. If needed i can prepare a patch
That wouldn't work reliably, as some people have an old copy saved locally, while others can still download the same old copy from one of the mirrors...
Signature · 1 line
Denys
Quoted 24 lines
Il giorno 04/gen/2012, alle ore 21:14, Chris Larson <[email protected]> ha scritto:
Quoted 7 lines · Denys Dmytriyenko
Quoted 5 lines
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Quoted 10 lines
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
Signature · 6 lines
Christopher Larson _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Quoted 10 lines · Chris Larson
Quoted 5 lines · Denys Dmytriyenko
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
exactly. Make sure the tars are sane
Quoted 7 lines
--
Christopher Larson_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 8 lines · Khem Raj
Quoted 7 lines · Chris Larson
Quoted 5 lines · Denys Dmytriyenko
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Quoted 5 lines
Quoted 3 lines
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
exactly. Make sure the tars are sane
Well, according to BlueZ maintainer[1], he gave the correct tarballs to kernel.org people, but for some reason they untarred and re-packed them. There's only 4 bytes difference, presumably timestamp...
[1] http://thread.gmane.org/gmane.linux.bluez.kernel/20040/focus=20041
Signature · 1 line
Denys
Quoted 13 lines · Denys Dmytriyenko
Quoted 12 lines · Khem Raj
Quoted 10 lines · Chris Larson
Quoted 5 lines · Denys Dmytriyenko
The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time...
Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something.
Quoted 5 lines
Quoted 1 line
exactly. Make sure the tars are sane
Well, according to BlueZ maintainer[1], he gave the correct tarballs to kernel.org people, but for some reason they untarred and re-packed them. There's only 4 bytes difference, presumably timestamp...
/me thinks maintainers should tar -cvO | gzip -n if they're going to use gzip ;)
But then, we see it from a rather different perspective than upstreams tend to..
Signature · 1 line
Christopher Larson