On 4/3/19, Iain Learmonth irl@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/