Re: FIXED: Re: jigdo-lite Error: ... does not match checksum in template data
On Wed, Oct 06, 2004 at 01:50:32AM +0100, Steve McIntyre wrote:
> I've found the cause of this bug:
Cool, thanks!
> I'm now seeing another minor issue. "jigdo-file ls" shows
> adduser_3.59_all.deb to have rsyncsum kRjI35yjRzk whereas my own debug
> tools show it to be kRjI35yjRz5 - note the last character is
> changed.
Hmm, I believe your base64 implementation might be buggy. :-/
The base64 checksum is 11 characters long, each character stands for 6
bits. So there are two spare, unused bits (11*6=66). The "k" stands for 36
(binary 100100), the "5" for 57 (binary 111001).
Base64 is "big-endian per byte". In other words, 3*8 input bits in
big-endian order are subdivided into 4*6 output bits, like this:
07 06 05 04 03 02 01 00|15 14 13 12 11 10 09 08|23 22 21 20 19 18 17 16
07 06 05 04 03 02|01 00 15 14 13 12|11 10 09 08 23 22|21 20 19 18 17 16
jigdo-file: 1 0 0 1 0 0
JTE: 1 1 1 0 0 1
In this case, input bits 16..23 are non-existent (because the input is not
a multiple of 3 bytes). The unused bits 22 and 23 are set to 0 by
jigdo-file. For jigdo-file, bits 8..11 are set to 1001, which matches the
last hex character of the hex checksum 9118c8df9ca34739.
I just compared our two implementations of base64. Did you use my code as a
reference for your work or is there only one way to implement it?? Anyway,
the algorithm is almost exactly the same except for some tiny differences.
Applying the patch below (untested, sorry) might make a difference.
IIRC, when I implemented my base64, I checked whether the above
interpretation of the RFC was correct by encoding binary data with some
mail client.
> Richard, PLEASE for future versions of jigdo drop this silly bastardised
> base64 encoding that you're using. It makes life _very_ difficult when
> debugging things if the checksum output format is not simple. Base 16
> good, base 64 bad.
Um, I'll think about it, but I don't see a problem here. IMHO the only
thing that's more difficult is the implementation of the binary->baseX
conversion, so if /that/ is correct, everything should be fine... :-/
Cheers,
Richard
--
__ _
|_) /| Richard Atterer | GnuPG key:
| \/¯| http://atterer.net | 0x888354F7
¯ '` ¯
--- jte.c.orig 2004-10-06 11:34:55.000000000 +0200
+++ jte.c 2004-10-06 11:43:58.000000000 +0200
@@ -765,15 +765,15 @@
value = (value << 8) | buf[i];
bits += 2;
p += sprintf(p, "%c", b64_enc[(value >> bits) & 63U]);
- if (bits >= 8) {
+ if (bits >= 6) {
bits -= 6;
p += sprintf(p, "%c", b64_enc[(value >> bits) & 63U]);
}
}
if (bits > 0)
{
- value <<= 8 - bits;
- p += sprintf(p, "%c", b64_enc[(value >> bits) & 63U]);
+ value <<= 6 - bits;
+ p += sprintf(p, "%c", b64_enc[value & 63U]);
}
return output_buffer;
}
Reply to: