[tor-bugs] #1692 [Tor Relay]: No Events for SETCONF
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Sat Dec 18 23:32:38 UTC 2010
#1692: No Events for SETCONF
-------------------------+--------------------------------------------------
Reporter: atagar | Owner: atagar
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Relay | Version: Tor: unspecified
Keywords: | Parent:
-------------------------+--------------------------------------------------
Changes (by atagar):
* milestone: Tor: unspecified => Tor: 0.2.3.x-final
Comment:
Hi Sebastian. Thanks for the help and feedback!
> If you can, referencing a git branch somewhere or attaching a patch
generated with format-patch would be great.
Gotcha.
> Lacks a changes file
Sorry, I don't know what this means.
> introduces a bunch of whitespace errors (run make check-spaces to catch
those)
Where? I've tried to address the blank-lines-are-empty convention while
writing and neither I, nor 'make check-spaces', are spotting them.
However, it did complain about a couple lines being wide:
Wide:src/or/config.c:676
Wide:src/or/config.c:677
Wide:src/or/rephist.c:1697
I've wrapped them at eighty characters as you guys like, and left
rephist.c alone.
> AttributeList looks a little ill-defined...
As per this and the irc discussion I'm switching to use newline dividers.
I'm not understanding the concern with respect to configuration values
possibly containing newlines - if this happened then wouldn't torrc
parsing and the config_dump function (which I'm basing this off) be
broken? I've refined the spec description a bit too.
I'm tempted to emit an event for each config value that changes, otherwise
this would seem to be the first event type that includes newlines (and
this breaks TorCtl). However, doing separate events for each value would
make config bundles (like hidden services) more confusing for controllers
to process. Thoughts?
If we do decide to keep with a newline separated listing then I'd
appreciate some suggestions from Mike for how we'll fix _read_reply (it
stops processing the event at the newline, then gets confused by the
following input):
File "/home/atagar/Desktop/arm/src/TorCtl/TorCtl.py", line 844, in
_read_reply
raise ProtocolError("Badly formatted reply line: unknown type %r"%tp)
ProtocolError: Badly formatted reply line: unknown type 't'
> what happens when the value contains a space
I don't believe that this is a concern. A space is the divider between the
key and value only. If the key had spaces, then we'd need a scheme to
handle this but that isn't the case.
> Just giving an example will not be enough, you need to be precise in the
specification.
I agree. The example was just meant to help clarify, not be a
specification in itself. We don't tend to provide examples in the spec
which I think is unfortunate, but if you want to take it out then that's
fine.
> you can replace the XXX with 0.2.3.1-alpha, if that version gets
released without this patch we can still update it later.
Hm, I'm thinking that this should be filled in by the committer when being
applied. Having a guessed value here risks confusion - if it's committed
with XXX then it's obvious that this was a bug.
I'm setting the bug's milestone to 0.2.3.x-final since that's what nickm
set my previous patch to.
> IIRC arma told me that we don't use // comments
Changed.
> the if (old_options) check should probably have a comment explaining
that old_options isn't set during first start of Tor
Added, also I was emitting an event in this case which wasn't a good idea.
> You are also leaking memory: smartlist_join_strings(),
smartlist_create() and tor_asprintf() allocate new memory that you have to
free.
I've added a free for the elements and results. I'm pretty sure that
smartlist_join_strings is freeing the temporary strings from tor_asprintf
(if it isn't then we have a memory leak in config_dump too).
Cheers! -Damian
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1692#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list