I observed that the code in reprepro appears to share common ancestry with that in glibc (I later also discovered http://people.redhat.com/drepper/SHA-crypt.txt), and furthermore that the code in glibc calculated the correct hash. Comparing the two, I isolated a minimal fix as follows:
--- a/sha256.c Sun Nov 23 22:19:17 2008 +0000 +++ b/sha256.c Sun Nov 23 22:30:49 2008 +0000 @@ -186,7 +186,7 @@ memcpy (&ctx->buffer[bytes], fillbuf, pad); /* Put the 64-bit file length in *bits* at the end of the buffer. */ - *(uint32_t *) &ctx->buffer[bytes + pad + 4] = SWAP (ctx->total << 3); - *(uint32_t *) &ctx->buffer[bytes + pad] = SWAP (ctx->total >> 29); + *(uint32_t *) &ctx->buffer[bytes + pad + 4] = SWAP ((uint32_t)(ctx->total << 3)); + *(uint32_t *) &ctx->buffer[bytes + pad] = SWAP ((uint32_t)(ctx->total >> 29)); /* Process last bytes. */ i.e. the bug is that the current code is passing a 64-bit integer to the SWAP macro, which is designed to byteswap a 32-bit integer. The code in glibc or at http://people.redhat.com/drepper/SHA-crypt.txt does not suffer from this bug because it explicitly uses two separate 32-bit integers as low and high words, unlike reprepro's actual 64-bit integer. Max. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
