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.0 +0200
+++ jte.c 2004-10-06 11:43:58.0 +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;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Error in sid-powerpc-1.template of 2004-09-25
I tried to download the current sid-powerpc-1 with jigdo, but the current template file seems boken on all mirrors I have tested. Do I have to wait until next week ? -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error in sid-powerpc-1.template of 2004-09-25
G. Klein wrote: I tried to download the current sid-powerpc-1 with jigdo, but the current template file seems boken on all mirrors I have tested. Do I have to wait until next week ? Hi, I have the same problem (checksum not the same) for sarge i386 Cheers, Jesse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#123436: FW: Global job vacancy-apply now
Hello, My name is Professor Brooke Wagner Here is a short message to tell you about an exciting new academic qualification program which is open to students worldwide. Your hard work and experience is equal to valuable college credits, and if you are experienced enough we will award you with the degree that suits you the most. If you are a qualified professional in your field. You have all the training, the knowledge and the life experience, and the only thing now you are lacking is the degree itself we can help you to gain the correct academic qualification to meet your life experience and put you in a better position in your professional career. The degrees we award are non-accredited from an academic point of view, you will however be able to use them in your chosen career field. For more information go to the following website http://www.neverstoplearning.info/fasttrack/ft, and you will be able to leave all of your details so that one of our qualified registrars can call you back with a response to your evaluation. Regards, Professor Brooke Wagner If you prefer not to receive such offers please go here: http://www.neverstoplearning.info/fasttrack/optout.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FIXED: Re: jigdo-lite Error: ... does not match checksum in template data
On Wed, Oct 06, 2004 at 11:49:45AM +0200, Richard Atterer wrote: >On Wed, Oct 06, 2004 at 01:50:32AM +0100, Steve McIntyre wrote: > >> 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. :-/ ... >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. Correct. Your patch fixes it. A base64 algorithm is always going to be rather similar... :-) >> 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... :-/ The problem is that the rest of the world outputs large binary data into text format by using hexadecimal; it's easy to understand and much easier to output and (more importantly) parse in a variety of languages. The only reason I can see in favour of the base64 encoding is a reduction in output size, and I'm not convinced that the small gains are worth the hassle. Please consider moving to the more standard format... :-P -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? signature.asc Description: Digital signature
