Re: [tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"

2020-06-18 Thread c
On Mon, 15 Jun 2020 14:06:37 -0400 Nick Mathewson wrote: > This seems plausible, though 0.0.0.0:x will just be the local computer as > well. > > Maybe you could try routing to a known-unassigned address, or one that > Tor simply won't support, like the one from RFC ? >From my understandin

[tor-dev] Reproducing #33598 "chutney does not fail on some SOCKS errors"

2020-06-15 Thread c
I asked on ticket https://bugs.torproject.org/33598 how to reliably reproduce SOCKS errors so that it would be easier to determine when the underlying issue is properly fixed, rather than running into the possibility of race conditions (as the current workaround depends on "waiting long enough" for

[tor-dev] #32888 IPv6 and 'Address' option

2020-06-14 Thread c
Trac describes that "we should also log [for] IPv4 and IPv6: the Address torrc option" and as tor(1) states, 'Address' takes only an IPv4 address and port. So what is suggested here? Make 'Address' support IPv6 to be consistent with other opt

Re: [tor-dev] Chutney code refactoring

2020-05-16 Thread c
On Fri, 15 May 2020 11:20:54 +1000 teor wrote: > You could try deleting functions, and then running tor's > "make test-network-all". If that test still passes, then the code is probably > unused (in practice). > > Chutney's CI does a few more tests for different tor versions, but I'm pretty > su

Re: [tor-dev] Chutney code refactoring

2020-05-16 Thread c
On Thu, 14 May 2020 19:58:45 -0400 Nick Mathewson wrote: > isInExpectedDirInfoDocs looks like it might once have done something useful. My impression is to remove it unless we anticipate needing it in the near future. > configure and restart and wait_for_bootstrap are all in use; they are > inv

Re: [tor-dev] Chutney code refactoring

2020-05-14 Thread c
On Sat, 18 Apr 2020 11:02:03 + c wrote: > I came across Node.specialize() which does not seem to be called > elsewhere, and I cannot guess at its purpose. I ran vulture (a static analyzer for dead code), trimmed the output to omit things I know were being used (some functions/attribut

Re: [tor-dev] Chutney code refactoring

2020-04-18 Thread c
On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who _have_

Re: [tor-dev] Chutney code refactoring

2020-04-17 Thread c
On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who _have_

Re: [tor-dev] Chutney code refactoring

2020-04-16 Thread c
On Thu, 16 Apr 2020 20:12:18 +0400 meejah wrote: > As to the specific DictWrapper issue, I also found this confusing. It's > kind of tied into a custom templating system too. I would question > whether this is a good idea; there are many templating systems already > for Python -- what does Chutne

[tor-dev] Chutney code refactoring

2020-04-15 Thread c
I was going to mention this on my pull request but I figured it would be much more fitting to have a more-general thread here. In the PR I mentioned how I believe that, if it quacks like a dict, it should be implemented as a dict. That way we (hopeful

Re: [tor-dev] Chutney tests fail for tor/maint-0.3.5 (bug #33677)

2020-04-02 Thread c
(Forgot to hit "reply all" in my mail client) On Mon, 30 Mar 2020 13:22:21 +1000 teor wrote: > This ticket is a cleanup ticket, after some other changes have been made. > I've edited the ticket description to make that clearer. Understood, thank you for clarifying. > Check for onion service

[tor-dev] Chutney tests fail for tor/maint-0.3.5 (bug #33677)

2020-03-29 Thread c
success', 'check-24': 'success'}: 2/2/0 DEBUG: Test status: {'send-data-21': 'not done', 'check-22': 'not done', 'send-data-23': 'success', 'check-24': 'success'}: 2/2/0 DEBUG: Done with run(); all

Re: [tor-dev] How to inform support of user-relevant issues?

2014-12-06 Thread Colin C.
On Sat, Dec 06, 2014 at 02:57:19PM -0800, David Fifield wrote: > What's a good way to inform support of issues that users might run into? > Should I just send email to h...@rt.torproject.org, or is there a better > way? > > I was thinking about this today because meek is broken in the 4.5-alpha >

Re: [tor-dev] [tor-reports] Help desk report for November 2014

2014-12-06 Thread Colin C.
On Sat, Dec 06, 2014 at 02:50:56PM -0800, David Fifield wrote: > > 5 | Set Country > ... > (Replied to from > https://lists.torproject.org/pipermail/tor-reports/2014-December/000711.html.) > > Colin, is it possible to see what's in the answer templates? At the 2014 > dev meeting, a note in

[tor-dev] Translation priority

2014-02-28 Thread Colin C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, Our contact at OpenITP has requested a list of resources / strings that we would like to potentially give priority to. If anyone has a project that is currently on our Transifex (or one that isn't and should be), and would like to see

[tor-dev] [Otter/Buoyant] Tor Documentation Pad

2013-10-29 Thread Colin C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, At today's Buoyant Otter meeting, it was determined that we needed a pad to organize our thoughts regarding the current documentation we have, and what we need. I have created a pad at https://zugzug.titanpad.com/3 for this purpose,

[tor-dev] [Otter/Buoyant] Tor documentation list

2013-10-21 Thread Colin C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 At the last Buoyant Otter meeting, it was determined that we required a list of the documentation that we currently provide. Runa and I have put together a list, and it is now available on the wiki[1]. If anyone notices something missing, please fee

[tor-dev] [Otter/Boisterous] WebChat report

2013-10-10 Thread Colin C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The Boisterous Otter project requires us to offer assistance to users through instant messaging. Current plan: use an XMPP server allowing anonymous connections from a web interface on one side, and have the support team use an authorized account fo

Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]

2013-09-30 Thread Colin C.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/09/13 09:13 PM, Tom Lowenthal wrote: > Today, at 1100 Pacific, we spent more than 90 minutes discussing > [Sponsor F][]. Here's the summary. > > **READ THIS**: The next Sponsor F meeting will be held in a mere > two weeks on **2013-10-14, at