[tor-dev] Tor Directory Meta-Format + Line Wrapping?

[grarpamp]

On 4/3/19, Iain Learmonth <irl at torproject.org> wrote:
>> When line wrapping, implementations MUST wrap lines
>> at 64 characters.  Upon decoding, implementations MUST
>> ignore and discard all linefeed characters.

The sectiion quoted is here...

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n193


> I can't work out how an implementation is meant to know if a linefeed
> character is meant to be for line-wrapping or if it's meant to be the
> end of a keyword line.

Every "line" of the Document ends in "NL", the meaning of "NL"
depends, line buffer and matching is required for determination.

One distinction is if Keyword is only of KeywordChar+NL without WS.
If so, then thinking could be that you're into optional wrapped Objects.

However... where it can get dicey for third party parsers is
they might start interpreting '^-----BEGIN<WS>' as another
KeywordLine with Argument, not least because KeywordChar
can contain '^-', and such parser won't necessarily know the
keyword dictionary (it would need to inherit that from tor library)
And for them to interpret say, '^[A-Za-z0-9]{64}$', as KeywordLine's
as well. Here is the tor specific magic regarding such knowledge...

228: When interpreting a Document, software MUST ignore
any KeywordLine that starts with a keyword it doesn't recognize;

And 224 is there meant to remove knowledge or confusion by
defining that case and triggering an Object at that moment
since it cannot be a KeywordLine...

224: A Keyword may not be "-----BEGIN".

And even though "220: MAY wrap" may seem to allow otherwise
by appending *in-the-line* the "EndLine" string, it alone being the
end of Object trigger, "Document" writers should probably ensure
that any of their "NOT wrapped" "Base64-encoded-data" strings
have an NL at the end of it, so no inefficient char parsing required.


Perhaps some above is part of what you may be experiencing.


Nit
226: s/keyword/Keyword/