Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Sorry I'm so far behind on email. Will try to catch up soon. On Fri, 24 Sep 2010 22:05:45 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Sep 11, 2010, at 3:47 AM, Sebastian Hahn wrote: On Sep 10, 2010, at 10:40 AM, Roger Dingledine wrote: In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. it'd be nice if further discussion could be moved to the bug report. Nick had a nice idea how to solve the situation without breaking our controllers. It would be great to get feedback on this (positive or negative) so please do reply with your thoughts. Patches for the documentation are also welcome, if they help to clarify the situation. Thanks Sebastian To let those know who didn't start monitoring the bug report, as of 851255170 we implemented a new feature to allow using multiple lines when specifying a torrc entry. To indicate that a line ends in the torrc but Tor should treat the next line as if it belonged to the current line, use a backslash at the end of the line. Comments inside such a block are ignored. What terminates a comment inside such a block? To provide an example, here is what the new syntax might look like (basically all previously valid torrcs should remain valid): ExcludeNodes \ # I don't like kittens lolcat1, \ Is the lolcat1, part of the comment about kittens? lolcat2 \ # / I also don't like bunnies! I really hate them. \ Is the \ part of the comment? The early comment line about kittens lacks a \. Are both validly continued lines? ,cutebunny, extracutebunny, \ # and this node appeared on my mother's birthday birthdaynode StrictNodes 1 I hope this is an acceptable solution for those who wanted a change, and doesn't upset those that thought the old behaviour was like it should be. Wow. That's the most incredibly *ugly* kluge I've seen in many a year, but if it works, then at least it does provide the functionality. I'll make the required changes to a copy of torrc and then try the upgrade to 0.2.2.17-alpha sometime in the next few days. Answers to the questions above would be helpful, though, in making those modifications. However, I don't understand the need for compatibility for tor controllers on this one. It seems to me that changes to the ExcludeNodes and ExcludeExitNodes lists are the kind of thing that should require rereading torrc, throwing away the previous lists and replacing them with the new ones read from torrc. Controllers should have the ability to trigger rereading of torrc, but not to make this sort of major operational change on the fly directly rather than by through rereading torrc. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Sep 11, 2010, at 3:47 AM, Sebastian Hahn wrote: On Sep 10, 2010, at 10:40 AM, Roger Dingledine wrote: In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. it'd be nice if further discussion could be moved to the bug report. Nick had a nice idea how to solve the situation without breaking our controllers. It would be great to get feedback on this (positive or negative) so please do reply with your thoughts. Patches for the documentation are also welcome, if they help to clarify the situation. Thanks Sebastian To let those know who didn't start monitoring the bug report, as of 851255170 we implemented a new feature to allow using multiple lines when specifying a torrc entry. To indicate that a line ends in the torrc but Tor should treat the next line as if it belonged to the current line, use a backslash at the end of the line. Comments inside such a block are ignored. To provide an example, here is what the new syntax might look like (basically all previously valid torrcs should remain valid): ExcludeNodes \ # I don't like kittens lolcat1, \ lolcat2 \ # / I also don't like bunnies! I really hate them. \ ,cutebunny, extracutebunny, \ # and this node appeared on my mother's birthday birthdaynode StrictNodes 1 I hope this is an acceptable solution for those who wanted a change, and doesn't upset those that thought the old behaviour was like it should be. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Tue, 14 Sep 2010 03:33:33 -0400 grarpamp grarp...@gmail.com wrote: Also, regarding the interaction with HS directory lookups and excludenodes... i would suggest that specification in excludenodes should prevent all contact with such node for all reasons. Or just make another option for how to handle that case as well. This is more important than the above paragraph. As one could have a node that is a 'bad' exit through no fault/intent of its operator... such as being plugged into a non-ideal isp... yet it would still be perfectly useful when acting as a non-exit or directory provider. The following options should do what you want: ExcludeNodes node,node,... A list of identity fingerprints, nicknames, country codes and address patterns of nodes to never use when building a circuit. ExcludeExitNodes node,node,... A list of identity fingerprints, nicknames, country codes and address patterns of nodes to never use when picking an exit node. Note that any node listed in ExcludeNodes is automatically considered to be part of this list. StrictNodes 0|1 If 1 and EntryNodes config option is set, Tor will never use any nodes besides those listed in EntryNodes for the first hop of a normal circuit. If 1 and ExitNodes config option is set, Tor will never use any nodes besides those listed in ExitNodes for the last hop of a normal exit circuit. Note that Tor might still use these nodes for non-exit circuits such as one-hop directory fetches or hidden service support circuits. -- more than just a leitmotif PGP Key ID: 33E22AB1 signature.asc Description: PGP signature
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Well, no rants, but I'm in qualified agreement with Scott [just this once, heh]... that yes, those of us stuck in 80x25 terminals and antique text comment databases could use a multiline format. It the project is concerned about the replace vs. add semantics, one could add two new exclude[exit]nodesmethod options. Where method is replace or add. Yet it is just an ease of use thing, and does have a certain impact on downstream controller code. So as long as the config does what the docs say it does, in whatever mode it ends up taking, that's fine, people will hack and make do either way. Config file and controller interface should act the same though. Also, regarding the interaction with HS directory lookups and excludenodes... i would suggest that specification in excludenodes should prevent all contact with such node for all reasons. Or just make another option for how to handle that case as well. This is more important than the above paragraph. As one could have a node that is a 'bad' exit through no fault/intent of its operator... such as being plugged into a non-ideal isp... yet it would still be perfectly useful when acting as a non-exit or directory provider. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. I have a rather long list of nodes that I have found undesirable in ways that justify (to me, at least, and my opinion rules on my node) their inclusion in one or the other of those lists. After building 0.2.2.15-alpha and installing it, I ran the usual tor --verify-config as a basic test. Surprise! It issued many messages of each of the following types: Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. There is no way that I can fit all of the excluded nodes of each type onto a single line for each type in my torrc. Also, my torrc is full of comment lines documenting the reasons for these exclusions in each case, which allows me to review certain ones from time to time for possible removal from whichever list they are on and also to know which ones should never be removed. Even if an editor were available that could handle line lengths great enough to allow placement of each entire list onto a single line in torrc, the comments would have to be left out or made useless by being separated from the corresponding node identifiers. The upshot is that I cannot upgrade to a version of tor that has this new and seemingly unnecessary change. :-( This is especially irritating at the moment, given that 0.2.2.14-alpha has a bug that causes it from time to time to drastically miscalculate the cutoff time for building new circuits. For example, a couple of days ago, it suddenly changed from cutoff times on the order of 12 to 14 seconds to cutoff times ranging from 130 to 300 seconds. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, Sep 10, 2010 at 01:36:18AM -0500, Scott Bennett wrote: I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. The ChangeLog entry in question is: - Warn when the same option is provided more than once in a torrc file, on the command line, or in a single SETCONF statement, and the option is one that only accepts a single line. Closes bug 1384. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. Can you confirm? --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Sep 10, 2010 at 01:36:18AM -0500, Scott Bennett wrote: I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. The ChangeLog entry in question is: - Warn when the same option is provided more than once in a torrc file, on the command line, or in a single SETCONF statement, and the option is one that only accepts a single line. Closes bug 1384. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Can you confirm? I'm not a tor developer, so no, I cannot confirm. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 10:05:09 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, Sep 10, 2010 at 03:27:01AM -0500, Scott Bennett wrote: Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? This excludenodes thing has been no end of trouble. The root problem is that it's a feature that absolutely none of the developers use. I wonder if that means there are similar problems with other features that no developers use. In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. (I guess the angry rants can stay here. ;) --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Sep 10, 2010, at 10:27 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 10:05:09 +0200 Sebastian Hahn m...@sebastianhahn.net wrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? It is currently tracked as https://trac.torproject.org/projects/tor/ticket/1929. Unfortunately some of our scripts rely on the current behaviour, so just changing it without carefully evaluating our current Tor controllers isn't an option. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, Sep 10, 2010 at 02:57:52AM -0500, Scott Bennett wrote: If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. That bug still does exist (also): https://trac.torproject.org/projects/tor/ticket/1090 but that bug is mainly in edge cases, e.g. where Tor wants to contact a hidden service directory node because that's the place that knows how to rendezvous with the hidden service, but that directory node has been listed in excludenodes. Some users expect one behavior, others expect a different behavior. It's on my todo list to put in some sort of patch for it by 0.2.2.x stable. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, 10 Sep 2010 04:40:02 -0400 Roger Dingledine a...@mit.edu wrote: On Fri, Sep 10, 2010 at 03:27:01AM -0500, Scott Bennett wrote: Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Wow. This is a scandalously bad situation. Is there any chance that it will get a high priority for being corrected *soon*? Please?? This excludenodes thing has been no end of trouble. The root problem is that it's a feature that absolutely none of the developers use. I wonder if that means there are similar problems with other features that no developers use. In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. I'll see if I can do that over the next couple of days. The old system wouldn't let me do anything beyond simply looking at trouble tickets. Meanwhile, a quick tally through my Exclude* lists shows 10 that were reported to be run by a federal agent of some sort and were not listed as a Family at the time, 2 impersonators of blutmagie, 1 that illegitimately claimed to be a directory authority, a group of 10 not listed as a Family that also inserted text into exit streams on port 80, 11 others that inserted text into or substituted their own web pages for port 80 exit streams, 8 that consistently truncated image files, 1 that redirected port 80 streams to a spyware page, 1 that allowed DNS hijacking, 1 that censored exits to certain IP addresses and/or ports instead of defining its ExitPolicy correctly, 3 that falsified SSL certificates into exit streams for MITM attacks, ~90 that ran very obsolete (e.g., 0.1.x.x, 0.2.0.x) tor software lacking oodles of security fixes, and 31 excluded for another reason of my own preference. These last two groups are ones that I do review from time to time to see whether the reason I excluded them has been eliminated, which would allow their removal from the list. All of the others, however, I've excluded for damned good reason, and I have no intention of ever removing them from the lists. As you can see, they aren't going to fit on just one ExcludeNodes line and one ExcludeExitNodes line. (I guess the angry rants can stay here. ;) I'm still in astonishment, wondering how I can actually exclude the nodes that should be excluded. No angry rants from me at this point. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Le Fri, 10 Sep 2010 03:39:44 -0400, Roger Dingledine a...@mit.edu a écrit : On Fri, Sep 10, 2010 at 01:36:18AM -0500, Scott Bennett wrote: I had planned to upgrade my node from 0.2.2.14-alpha this evening to 0.2.2.15-alpha, but there is an unfortunate and apparently gratuitous, new restriction upon ExcludeNodes and ExcludeExitNodes that, for the moment at least, is preventing me from upgrading. Sep 10 01:15:29.753 [warn] Option 'ExcludeExitNodes' used more than once; all but the last value will be ignored. Sep 10 01:15:29.753 [warn] Option 'ExcludeNodes' used more than once; all but the last value will be ignored. The ChangeLog entry in question is: - Warn when the same option is provided more than once in a torrc file, on the command line, or in a single SETCONF statement, and the option is one that only accepts a single line. Closes bug 1384. To the developers: please fix the next release of -alpha to allow the use of multiple ExcludeExitNodes and ExcludeNodes lines again. Thank you. As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. Can you confirm? --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Hi. What i don't get his what do you mean by more than once ? I use for exemple: ExcludeNodes 149.9.0.27,149.9.0.108,89.248.169.109,94.182.58.14,94.41.93.172 ExcludeExitNodes 149.9.0.27,149.9.0.108,89.248.169.109,94.182.58.14,94.41.93.172 and so to how many ip's, fingerprints or what format you want's and i don't have any problems on 0.2.2.15-alpha-dev I use it like you from long times Scott and don't see any bad problems with it, the only thing i don't do , it's to test with tor-verif-config . But if you do like me , be sure that it will work, same with 200 ExludesNodes My best SwissTor *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On 09/10/2010 01:05 AM, Sebastian Hahn wrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Uh oh... F. Fox *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Just a heads up that there *has* been torrc validation in arm for quite some time now. Warnings about this issue (unused entries due to duplicates) have been given since release 1.2.2 (11/8/09, so bit less than a year now). I just tested and it has been giving warnings about ExcludeNodes all this time (root cause is that only entries with LINELIST and LINELIST_S in src/or/config.c can be duplicates). If others have ideas for additional validation I can do on user's torrc files then I'd love to know. Cheers! -Damian On Fri, Sep 10, 2010 at 1:05 AM, Sebastian Hahn m...@sebastianhahn.netwrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On 9/10/2010 5:29 AM, Scott Bennett wrote: Even if an editor were available that could handle line lengths great enough to allow placement of each entire list onto a single line in torrc, I'm still in astonishment, wondering how I can actually exclude the nodes that should be excluded. I'm not really sure I'm seeing what the problem is. You mentioned ~170 nodes; a quick copy and paste of 200 40-bit fingerprints yields an 8400-character line (including $s and commas), which is easily handled by Nano on my Linux machine and Notepad++ on my Windows box. I'm sure Pico under OSX would work just as well. I can see why you would be upset that your comments are rendered useless, and that your nicely-formatted torrc is now has to be a bit uglier, but your overall goal shouldn't be affected: just plop them all on one line and you'll at least get the functionality you've been shooting for. ~Justin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Fri, Sep 10, 2010 at 04:29:38AM -0500, Scott Bennett wrote: I'm still in astonishment, wondering how I can actually exclude the nodes that should be excluded. No angry rants from me at this point. I would recommend a little script which generates the torrc file for you using a template file with your commented nodes on separate lines. Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 pgp7CfU8zi4UB.pgp Description: PGP signature
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
On Sep 10, 2010, at 10:40 AM, Roger Dingledine wrote: In any case, Sebastian started a trac entry for this one: https://trac.torproject.org/projects/tor/ticket/1929 wherein he starts out by listing a reason that we shouldn't fix it. Please add more pros and cons to the trac entry. it'd be nice if further discussion could be moved to the bug report. Nick had a nice idea how to solve the situation without breaking our controllers. It would be great to get feedback on this (positive or negative) so please do reply with your thoughts. Patches for the documentation are also welcome, if they help to clarify the situation. Thanks Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
