On Wed, Apr 18, 2012 at 18:07, David Kalnischkies <kalnischkies+debian@gmail.com> wrote: > It seems to be indeed the way the sha256 and sha512 checksums are > calculated. To make it a bit obscure: we have a testcase checking them > and they run successfully producing the correct output. > (for reference: test/libapt/hashsums_test.cc) > > The bug seems only to be triggered if a checksum is "slowly" build > as it is the case in the http transport while downloading. /me can't see the forest for the trees… While our testcase as well as other places in the library use well-aligned buffers which can be casted from byte to word (or double-word) the http transport is with its circle buffer implementation an exception to this as it usually reads full words, but writes them to "random" places which do not care for word boundaries… More as a workaround than a completely proper fix i changed the only place in which the input buffer is directly passed into Transform (which was somehow not in the path gdb claimed it is used) to memcpy it instead into a local buffer to ensure that the cast later will work. The alternative would have been to change the http method, but given the high debugging cost in case someone uses these methods on unaligned buffers and that the calculations aren't that time-critical we can life with that for now. A more interesting fix would it be to make the Transform methods work with bytes instead of words, but i guess we can better think about that without blocking a transition… (Michael will upload that soon together with a few more fixes. As of writing this should make apt new-serious-bug-free… yeah! We will see how long this will last… :) ) Best regards David Kalnischkies
Attachment:
apt-669061-unaligned-http-buffer-sigbus-on-sparc.diff
Description: Binary data