[tor-dev] Response on adding extra torrc fields

Damian Johnson atagar at torproject.org
Sat Jul 5 00:41:00 UTC 2014

> Hi Damian!  I'm trying to make this work under your suggestions, but I'm not
> entirely clear how.  Can you help me get this in shape to pass your muster?

Hi Virgil, I'd be glad to! Adding tor-dev@ back in case others have
thoughts on the details. I like your idea, what I was trying to hint
by asking about the motivation was that the proposal should clearly
explain why we're doing this (with example use cases).

As for detail, I mean the proposal should have text we can copy and
paste into the dir-spec. Maybe something like...


The following would be added to section 2.1.2 of the dir-spec
(Extra-info document format):

"X-" CustomKey SP CustomValue NL

CustomKeyChar = ALPHA / DIGIT / "_" / "-"
CustomKey = 1*20 CustomKeyChar

CustomValueChar = atext / SP
CustomValue = 1*200 CustomValueChar

Custom field that can appear multiple times, for example...

X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
X-favoritequote Be excellent to each other.  Party on dudes!
X-foo bar

A CustomKey cannot appear more than once, and there cannot be more
than ten of these entries.


As a controller library author what I want from proposals is enough
detail so I know *exactly* how to parse new additions. There's lot of
potential edge cases. Can values be an empty string? How about keys?
What should we do if a key appears multiple times? Is that valid? You
mentioned a 5 KB limit, is that per option or for all custom fields?

Rather than a size threshold, in the above I'm proposing a limit of
ten entries each of which can be at most 220 characters. That would
only be 2 KB so feel free to tweak these limitations.

I'm not entirely sure 'atext' is what we want here. This would exclude
tabs, but maybe that's not such a bad thing. You can look it up on...


Cheers! -Damian

More information about the tor-dev mailing list