Re: Failed to decode requested authority digest

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

> Quoth Nick Mathewson <nickm@xxxxxxxxxxxxxx>, on 2010-01-14 21:49:33 -0500:

Nevermore!

>> > Jan 12 08:57:59.119 [warn] Failed to decode requested authority digest
>> > 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4.
>> > Jan 14 11:40:05.641 [warn] Failed to decode requested authority digest
>> > 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4.
>>
>> This looks like some kind of broken client to me. =A0Look at all those
>> %20s in the string: that looks like http encoding of a space (" ")
>> character, so somebody's program is requesting "14C131 27B6B5 585769
>> 81349F E2A2AF E8A9C4" with the spaces HTTP-encoded. =A0Unless I'm
>> mistaken, the proper format is using + signs, not spaces.
>
> If you mean URI-encoded (or URL-encoded), which HTTP uses, then %20 is
> a valid encoding of a 0x20 (ASCII space) character. =A0+ is a secondary
> convention that's used in query strings only, which can also mean a
> space character. =A0Does the Tor directory request protocol specify
> something else?

For this URL, dir-spec.txt specifies:

     http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z

  Where F1, F2, etc. are authority identity fingerprints the client trusts=
.
  Servers will only return a consensus if more than half of the requested
  authorities have signed the document, otherwise a 404 error will be sent
  back.  The fingerprints can be shortened to a length of any multiple of
  two, using only the leftmost part of the encoded fingerprint.  Tor uses
  3 bytes (6 hex characters) of the fingerprint.

The last sentence should probably start "The Tor client uses..."

The plus signs have been required as long as I can remember, though I
agree that a more standards-friendly use of HTTP would accept any
equivalent URI-encoded string. I'd welcome a patch or two to handle
proper URI-encoding better, or alternatively a patch to dir-spec.txt
to be more explicit about anything at all.

>  The dir-spec.txt document from Tor 0.2.1.20 doesn't
> seem to be clear on how <fp> is interpreted in URIs.

Agreed.  The closest it comes is saying,

]      http://<hostname>/tor/status-vote/next/<fp>.z
]   where <fp> is the fingerprint of the other authority's identity key.

From this, the reader is presumably meant to infer that <fp> means an
arbitrary-length hexadecimal string, with current lengths of 160 bits
(or 20 bytes, or 40 hex characters) , encoding a SHA1 digest of the
public identity key of the corresponding authority.  If any reader
really infers this... that's some reader!  Somebody should clean this
up.  Let me know if anyone has got a  patch I can apply here.

--=20
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/