Hi Nick, thanks for the feedback!<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I'm fine with most of these, but the names are no good. *Everything*<br>
that's returned from GETINFO is "info" after all<br></blockquote><br>Heh, good point. Changed.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
The only one I wouldn't want to add as-is the ns/authorities option,<br>
since it says that it uses the v2 directory format.<br></blockquote><br>I chose the v2 directory format since that's what all the other "ns" entries use and it seems weird to have this be a black sheep. If this is really a problem I'm happy to change it, though conformity to the rest of the spec struck me as being important.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Three reasons off the top of my head. First: That's the format that<br>
RFCs use. Second: we like to be able to use diff to compare different<br>
versions of a spec, and making every paragraph a single line makes<br>
diff's output much less useful. Third: we like to version-control our<br>
specs, and it's a lot easier to resolve conflicts when every paragraph<br>
is not a single line.<br></blockquote><br>I don't want to dwell on this too much since it's a pretty trivial issue, but I disagree with points two and three. If you add or remove words, the rewrapping throws off the diff and version control resolution for any text following it anyway. That said, "conformity with the other specs, and since most people here prefer it" strike me as perfectly fine reasons. ;)<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Do you mean their IDs, or their entries in the format specified above, or what?<br></blockquote>
<br>I was tempted to go with just the IDs, but it seems like the other "/all" getinfo options provide all the content so going with that to try and fit in.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Probably a "process-owner" notion is closer to what you want here.<br>
Also remember that it needs to work on Windows. ;)<br></blockquote>
<br>Yup, that's why the user entry states that an empty string is provided if none exists. I'm not yet sold on the usefulness of the uid, euid, gid, and egid but happy to include them if others think it would be handy.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">At this point we're probably ready for another proposal revision<br></blockquote><br>
Your wish is my command! I've split it up into two proposals (see attached), one concerning the circ options and the other listing the expansion of relay/process getinfo options. Other changes include:<br>- added "relay/flags" and "desc/time" getinfo options<br>
- changed the bandwidth entries to be both inbound and outbound (not sure how it would make sense otherwise...)<br>- changed the circ results to have a unix timestamp for when the circuit was created rather than the uptime (more generally useful and avoids the question of when the results were last updated)<br>
<br>Cheers! -Damian<br><br><div class="gmail_quote">On Tue, Jun 1, 2010 at 8:47 AM, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@freehaven.net" target="_blank">nickm@freehaven.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'll try to follow up to this whole thread and push things forward even more.<br>
<br>
On April 14, Damian wrote:<br>
[...]<br>
<div>>Also, could we move forward on the other (less controversial) items? For instance, bandwidth totals tend to be a very highly requested piece of information and pipe's already provided a nice patch to get it (<a href="http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html" target="_blank">http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html</a>). For reference, here's the not-so-controversial GETINFO options I proposed:<br>
<br>
</div>I'm fine with most of these, but the names are no good. *Everything*<br>
that's returned from GETINFO is "info" after all, so prefixing all of<br>
these with "info" is redundant; they need to be put into a grouping<br>
that actually says what they mean.<br>
<br>
The only one I wouldn't want to add as-is the ns/authorities option,<br>
since it says that it uses the v2 directory format. That format is<br>
obsolescent; we shouldn't be adding new things that use it. A<br>
non-deprecated format would be fine.<br>
<br>
[...]<br>
<div>>I'm not planning on converting the following to the customary 80-character width until it's at<br>
> least past being a first draft for a couple reasons:<br>
>1. I find editing fixed-width documents to be a time consuming pain in the ass.<br>
<br>
</div>Maybe use a text editor that will re-wrap paragraphs for you? There<br>
are dozens of them.<br>
<div><br>
> 2. I've yet to hear why we do this. Is it just to cater to mail clients too dumb to know how to line wrap?<br>
<br>
</div>Three reasons off the top of my head. First: That's the format that<br>
RFCs use. Second: we like to be able to use diff to compare different<br>
versions of a spec, and making every paragraph a single line makes<br>
diff's output much less useful. Third: we like to version-control our<br>
specs, and it's a lot easier to resolve conflicts when every paragraph<br>
is not a single line.<br>
<br>
There may be more benefits too.<br>
<div><div></div><div><br>
<br>
On Fri, Apr 16, 2010 at 3:17 PM, Jacob Appelbaum <<a href="mailto:jacob@appelbaum.net" target="_blank">jacob@appelbaum.net</a>> wrote:<br>
> Damian Johnson wrote:<br>
>> Yesterday Jake met with me to discuss this proposal, making the very<br>
>> good points that both:<br>
>> 1. It's completely ineffectual for the auditing purposes I've<br>
>> mentioned since either (a) these results can be fetched from netstat<br>
>> already or (b) the information would only be provided via tor and<br>
>> can't be validated.<br>
>> 2. The things I'm really interested in can be fetched with much less<br>
>> (and safer) information.<br>
><br>
> I still think that anything that can be used to track circuits (and the<br>
> clients associated with them) is not a good idea - in Tor or using arm.<br>
> We shouldn't encourage people to log, look or otherwise track Tor.<br>
><br>
>><br>
>> In particular we discussed making the proposal circuit based rather<br>
>> than connection based, being something like the following:<br>
>><br>
>> "circ/<Circuit identity>" -- Provides entry for the associated circuit,<br>
>> formatted as:<br>
>> CIRC_ID IN_TYPE OUT_TYPE READ WRITE UPTIME<br>
>><br>
>> none of the parameters contain whitespace, and additional results must be<br>
>> ignored to allow for future expansion. Parameters are defined as follows:<br>
>> CIRC_ID - Unique identifier for the circuit this belongs to.<br>
>> IN_TYPE/OUT_TYPE - Single character flags indicating the purpose of the<br>
>> inbound or outbound connection. If no connection is established then<br>
>> this provides an empty string. Otherwise, it consists of one from each<br>
>> of the following categories (this may become longer in future<br>
>> expansion):<br>
>> Usage Type:<br>
>> C: client traffic, R: relaying traffic,<br>
>> X: control, H: hidden service, D: directory<br>
>> Destination:<br>
>> I: inter-tor connection, O: outside the tor network, L: localhost<br>
>> For instance, "RO" would indicate that this was an established<br>
>> 1st-hop (or bridged) relay connection.<br>
>> READ/WRITE - Total bytes read/written over the life of this connection.<br>
>> UPTIME - Time the connection's been established in seconds.<br>
<br>
</div></div>This looks a lot better; I don't see a good way to cause problems with this.<br>
<div><br>
>> "circ/all" -- Newline separated listing of all current circuits.<br>
<br>
</div>Do you mean their IDs, or their entries in the format specified above, or what?<br>
<br>
[...]<br>
<div>>> SafeControlPort 0|1<br>
>> Restricts access of the control port to only include read-only operations.<br>
>> (Default: 0)<br>
>><br>
>> Making this the default would be a no-go due to vidalia (though still<br>
>> a nice option to have...). If this is implemented its setting should<br>
>> be part of the PROTOCOLINFO response.<br>
<br>
</div>I agree with Jake that this probably wants to be another proposal of<br>
its own, and get implemented independently.<br>
<div><br>
>> Finally, the other proposed GETINFO options still seem useful (with<br>
>> the possible exception of "info/uptime-reset"), and could be improved<br>
>> with the addition of:<br>
>><br>
>> "info/user" -- User under which the tor process is running, providing an<br>
>> empty string if none exists.<br>
>><br>
><br>
> You may also want something like the following:<br>
><br>
> "info/uid"<br>
> "info/euid"<br>
> "info/gid"<br>
> "info/egid"<br>
<br>
</div>Probably a "process-owner" notion is closer to what you want here.<br>
Also remember that it needs to work on Windows. ;)<br>
<br>
Also see above caveat on the "info/" prefix.<br>
<div><br>
>> "info/pid" -- Process id belonging to the tor process, -1 if none exists for<br>
>> the platform.<br>
>><br>
>> * this one is both useful and surprisingly difficult for me to<br>
>> retrieve at present (arm attempts to get it from pidof, ps, and<br>
>> netstat yet still fails on some systems...)<br>
><br>
> The good news is that it's pretty easy to do in C:<br>
><br>
> pid_t pid;<br>
> pid = getpid(); // see also getppid();<br>
> printf("PID is: %d\n", pid);<br>
<br>
</div>Fine by me, modulo calling it "info".<br>
<br>
At this point we're probably ready for another proposal revision, and<br>
a draft patch to implement all of the above. :)<br>
<br>
--<br>
<font color="#888888">Nick<br>
</font></blockquote></div><br>