[tor-bugs] #30887 [Internal Services/Service - lists]: Make new network-hea...@lists.tpo list

[Tor Bug Tracker & Wiki]

#30887: Make new network-hea...@lists.tpo list
---+-
 Reporter:  arma   |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 There is no 'network health' team yet, but there are plenty of tasks that
 need doing, so let's make a mailing list so we can stay synchronized.

 For context, the task areas for this team are in this mail:
 https://lists.torproject.org/pipermail/tor-
 project/2018-December/002138.html

 I would like this list to have public archives. I can configure it once it
 exists. I plan to make listowner (i.e. including me) and dgoulet be the
 list owners.

 I'm going to start out using it as the cc for a whole bunch of mails to
 relay operators to ask how things are going and to tell them they're
 running an abandoned version of Tor.

 If we need a short description of the list, we could use something like
 "Tor Network Health Team coordination list".

 Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30691 [Core Tor/Tor]: Refactor decoding outside the if expression in dirserv_load_fingerprint_file()

[Tor Bug Tracker & Wiki]

#30691: Refactor decoding outside the if expression in
dirserv_load_fingerprint_file()
+--
 Reporter:  teor|  Owner:  neel
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  #22029  | Points:
 Reviewer:  teor|Sponsor:
+--
Changes (by teor):

 * status:  needs_review => closed
 * reviewer:   => teor
 * resolution:   => fixed


Comment:

 I'm going to review this code in #22029.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29024 [Core Tor/Chutney]: Add pluggable-transport support to Chutney

[Tor Bug Tracker & Wiki]

#29024: Add pluggable-transport support to Chutney
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 041-accepted-20190115,   |  Actual Points:  1
  network-team-roadmap-2019-Q1Q2, tor-ci,|
  041-deferred-20190530  |
Parent ID:   | Points:  2
 Reviewer:  teor |Sponsor:
 |  Sponsor19
-+-
Changes (by teor):

 * reviewer:   => teor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Let me know when the child tickets are all done, and I'll do a review.

 Some of the child tickets are independent, and we can review them
 separately, I'm happy to make pull requests once I see the code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30235 [Core Tor/Stem]: Stem hangs waiting for control port data

[Tor Bug Tracker & Wiki]

#30235: Stem hangs waiting for control port data
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.5
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:  Sponsor31-can
---+---

Comment (by teor):

 Hopefully one of the pull requests in #30591 will fail, if they do, I'll
 paste the logs here:
 https://trac.torproject.org/projects/tor/ticket/30591#comment:20

 (We don't want the logs from the deliberate failure pull request.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30591 [Core Tor/Tor]: Make tor's Travis stem job log controller messages from stem and tor

[Tor Bug Tracker & Wiki]

#30591: Make tor's Travis stem job log controller messages from stem and tor
-+-
 Reporter:  teor |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, stem, |  Actual Points:  0.6
  041-should |
Parent ID:  #29437   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * actualpoints:  0.4 => 0.6


Comment:

 Replying to [comment:19 catalyst]:
 > Replying to [comment:17 teor]:
 > > Replying to [comment:6 teor]:
 > > > Replying to [comment:1 teor]:
 > > > > I based these branches on #30234, because it hasn't been
 backported to 0.3.5 yet.
 > > > ...
 > > This should reduce the TRACE output, but maybe not by enough (we might
 need to tail the output once #30675 is implemented).
 > It looks like the repetitive log messages are still quite numerous, and
 might obscure useful information. Maybe we want to do the `grep -v` for
 now?

 See my pull request:
 * 0.3.5: https://github.com/torproject/tor/pull/1044

 And test requests:
 * 0.4.0: https://github.com/torproject/tor/pull/1110
 * 0.4.1: https://github.com/torproject/tor/pull/
 * master: https://github.com/torproject/tor/pull/1045

 And a deliberate fail:
 * master: https://github.com/torproject/tor/pull/1112

 Let's deal with other logging fixes in other tickets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30700 [Core Tor/Tor]: Tor's Travis stem job shows debug logs from 10 minutes after the hang

[Tor Bug Tracker & Wiki]

#30700: Tor's Travis stem job shows debug logs from 10 minutes after the hang
--+---
 Reporter:  teor  |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29437| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * keywords:  tor-ci-fail-sometimes =>
 * component:  Core Tor/Stem => Core Tor/Tor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29437 [Core Tor/Stem]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
---+
 Reporter:  rl1987 |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:  0.4
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:  Sponsor31-can
---+
Changes (by teor):

 * keywords:  tor-ci-fail-sometimes =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29645 [Core Tor/Tor]: test.exe hangs on Appveyor CI

[Tor Bug Tracker & Wiki]

#29645: test.exe hangs on Appveyor CI
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, tor-ci, tor-windows,  |  Actual Points:  0.4
  tor-test, hang, 035-backport, 040-backport,|
  041-should |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * keywords:
 asn-merge, tor-ci, tor-windows, tor-test, hang, tor-ci-fail-sometimes,
 035-backport, 040-backport, 041-should
 =>
 asn-merge, tor-ci, tor-windows, tor-test, hang, 035-backport,
 040-backport, 041-should


Comment:

 I haven't seen this issue for a while, should we assume it's not a problem
 any more?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30886 [Core Tor/Chutney]: Add pluggable transport support to chutney's tools/test-network.sh

[Tor Bug Tracker & Wiki]

#30886: Add pluggable transport support to chutney's tools/test-network.sh
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:
  Tor/Chutney|   Keywords:  tor-pt, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2, chutney-ci, tor-ci
Actual Points:   |  Parent ID:  #29024
   Points:  1|   Reviewer:
  Sponsor:   |
  Sponsor19-can  |
-+-
 We have basic PT support in chutney, but we need a nicer interface to it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29024 [Core Tor/Chutney]: Add pluggable-transport support to Chutney

[Tor Bug Tracker & Wiki]

#29024: Add pluggable-transport support to Chutney
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 041-accepted-20190115,   |  Actual Points:  1
  network-team-roadmap-2019-Q1Q2, tor-ci,|
  041-deferred-20190530  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-

Comment (by teor):

 I opened #30884, #30885, and #30886 for follow up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30885 [Core Tor/Tor]: Add pluggable transports to Tor's chutney CI job

[Tor Bug Tracker & Wiki]

#30885: Add pluggable transports to Tor's chutney CI job
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-pt, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2, tor-ci
Actual Points:   |  Parent ID:  #29024
   Points:  1|   Reviewer:
  Sponsor:   |
  Sponsor19-can  |
-+-
 We added PT support to chutney in #29024, now we need to make sure tor
 changes don't break PTs.

 We should probably get chutney CI merged into Tor first, see #29280.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30884 [Core Tor/Chutney]: Test pluggable transports in chutney's CI

[Tor Bug Tracker & Wiki]

#30884: Test pluggable transports in chutney's CI
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:
  Tor/Chutney|   Keywords:  tor-pt, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2, chutney-ci, tor-c
Actual Points:   |  Parent ID:  #29024
   Points:  1|   Reviewer:
  Sponsor:   |
  Sponsor19-can  |
-+-
 We added PT support to chutney in #29024, now we need to make sure it
 keeps on working.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30455 [Core Tor/Tor]: Improve documentation for chutney warnings in "make test-network-all"

[Tor Bug Tracker & Wiki]

#30455: Improve documentation for chutney warnings in "make test-network-all"
-+-
 Reporter:  nickm|  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  chutney, easy, doc, tor-ci,  |  Actual Points:  0.1
  041-should |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor19-can
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * version:   => Tor: 0.3.0.4-rc
 * sponsor:   => Sponsor19-can
 * actualpoints:   => 0.1


Comment:

 I think we discovered this issue during Sponsor 19 work.

 See my pull request:
 * 0.4.1: https://github.com/torproject/tor/pull/1108

 Test merges:
 * master: https://github.com/torproject/tor/pull/1109

 > Any other fixes here should probably come after we merge our other "use
 chutney for CI" tickets, since they are likely to touch this part of the
 makefile as well.

 We decided to use "make test-network-all" without any modifications, so
 there shouldn't be any conflicts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.5
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * actualpoints:  1.0 => 1.5


Comment:

 Replying to [comment:5 teor]:
 > Replying to [comment:4 catalyst]:
 > > * Maybe add unit tests to ensure that IPv4 addresses with square
 brackets get rejected?
 >
 > Hmm yeah the unit tests are not in a great state. I'm working on them.

 So I found two bugs while improving the unit tests:
 * ambiguous IPv6:port without brackets were allowed, now they are banned
 in the address-port parsing functions only (1b39bde)
 * sometimes the port was set on failure, now it is always zero (679cce7)

 I rewrote the tests and added a lot of tests cases, to make sure we
 covered all these changes.

 Some of the ambiguous test cases may fail on Linux or Windows (I only
 tested on macOS), so I'll check CI in an hour or so to make sure.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30883 [Metrics/Website]: I miss the old relay capacity / load graph

[Tor Bug Tracker & Wiki]

#30883: I miss the old relay capacity / load graph
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We have this page to show us the overall network capacity and load:
 https://metrics.torproject.org/bandwidth-flags.html

 but the old version of the graph was much more readable, and more clearly
 showed both the trends and also the comparison between capacity and load.
 See for example slide 19 of
 https://freehaven.net/~arma/slides-know19.pdf

 So: can we have the old version of the graph back? I don't object to
 keeping the current bandwidth-flags version too if we like it.

 Karsten has offered to run scripts manually for me when I want to update
 my slides for a talk, but that doesn't seem as good as letting everybody
 see the graph when they want to.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  If some folks prefer GitLab that's great! But migrating us away from
 Trac is not a decision to be taken lightly, and requires community buy-in.

 I totally agree. I consider we're at the "feasability study" stage. :)

 >  I was around a decade ago for our migration to Trac, and what you're
 proposing is a big move that impacts us all. Especially if you want to
 propose shutting Trac down without redirects. As I see it there's three
 open questions...

 For the record, I really, really want to have redirects, if we can't
 archive the entire website. I understand it's a solid requirement.

 > 1. Do we want to migrate away from Trac at all?
 > 2. If so, what would we prefer to move to? GitHub? GitLab? Something
 else?
 > 3. What will happen with Trac's ticket and wiki data?

 I think there are some answers to this above, from my perspective, but
 this should definitely be discussed more widely, once we have a clearer
 idea of a possible way forward.

 > This ticket is not the proper place develop consensus on such a large
 move. If you'd care to pursue this I'd suggest...
 >
 > 1. Open the GitLab instance up. I tried to look at
 ​https://dip.torproject.org/ to see what my projects look like on it but
 I'm presented with a login page. As an open source developer this makes it
 DOA right from the starting gate. :)

 It's already kind of open, here: https://dip.torproject.org/explore

 We could improve the splash page, for sure.

 > 2. Begin a thread on tor-project@ to see how the community feels about
 this. I suspect if we move at all folks will prefer GitHub to GitLab, but
 I'm definitely curious to see what people think.

 Hear hear. I'm all for discussing this more widely, but I also think it's
 a good idea to have a plan first.

 I intend to research the topic a little more, maybe do a few actual tests
 (archiving trac into HTML, testing a migration to a test gitlab project or
 fake instance) to see how a migration could look like and/or how much time
 it would take. Then we can come up with something more concrete that
 people will understand better than the current vague idea of where we're
 going. :)

 More concretely, I'm thinking of writing a
 [http://opsreportcard.com/section/9 design doc] for the migration,
 hopefully it will make everything and the options a little more concrete.
 Trac was one of the first thing added to my priority list when I was hired
 at TPI, three months ago, and it's still high on my radar. I haven't had
 any concrete bug reports other than the occasional "trac is slow" which is
 generally transient, so it's hard to figure out what the next step is. But
 people are getting more and more aggravated about the service and I think
 we need to start to think about the exit strategy...

 How does that sound?

 One thing I don't really want is a huge flamewar/bikeshed on this, so i
 think doing this research is definitely useful.

 Also note that this ticket is part of #29400 which explicitely says:

 > We are going to evaluate Gitlab as a replacement for trac, gitweb.tpo,
 git-rw.tpo, github.com.

 Then it is mentioned,
 
[https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsAdminTeamMinutes#gitlabservice
 in the brussels admin meeting minutes] that:

 > Some team (snowflake?) to use gitlab exclusively. move (copy + add link
 to gl) existing tickets to gitlab service (not by tsa but by gitlab team)
 >
 > Runners could be provided by anyone. so, it could be done outside of
 tpa/tpo for evaluation, and if we like it in the end we can add some
 runners later.

 So there's a precedent in the idea of migrating at *least* some teams to
 GitLab permanently. I'm taking the next step and asking what's going to
 happen with the rest of trac, because I certainly don't want to keep that
 technical debt around too long. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org

[tor-bugs] #30882 [Core Tor/Stem]: Stem python 3.8 RuntimeError: dictionary keys changed during iteration

[Tor Bug Tracker & Wiki]

#30882: Stem python 3.8 RuntimeError: dictionary keys changed during iteration
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 python 3.8 doesn't seem to like dictionary keys changing during iteration.
 This is on python nightly, so it might be a new python feature (or even a
 python bug).

 It is reproducible: I've seen it in at least two runs so far.

 {{{
   Jun 13 15:02:32.725 [notice] Bootstrapped 100% (done): Done
   done (17 seconds)
 Shutting down tor... done
 Traceback (most recent call last):
   File "./run_tests.py", line 479, in 
 main()
   File "./run_tests.py", line 306, in main
 integ_runner.start(target, args.attribute_targets, args.tor_path)
   File "/home/travis/build/torproject/stem/test/runner.py", line 262, in
 start
 self._owner_controller = self.get_tor_controller(True)
   File "/home/travis/build/torproject/stem/test/runner.py", line 482, in
 get_tor_controller
 controller.authenticate(password = CONTROL_PASSWORD, chroot_path =
 self.get_chroot())
   File "/home/travis/build/torproject/stem/stem/control.py", line 1110, in
 authenticate
 stem.connection.authenticate(self, *args, **kwargs)
   File "/home/travis/build/torproject/stem/stem/connection.py", line 596,
 in authenticate
 controller._post_authentication()
   File "/home/travis/build/torproject/stem/stem/control.py", line 3993, in
 _post_authentication
 owning_pid = self.get_conf('__OwningControllerProcess', None)
   File "/home/travis/build/torproject/stem/stem/control.py", line 2261, in
 get_conf
 entries = self.get_conf_map(param, default, multiple)
   File "/home/travis/build/torproject/stem/stem/control.py", line 2364, in
 get_conf_map
 for key in reply:
 RuntimeError: dictionary keys changed during iteration
 The command "./run_tests.py --integ $TARGET" exited with 1.
 }}}
 https://travis-ci.org/torproject/stem/jobs/545118990

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #27539 [Applications/Tor Browser]: Create plan for releasing on F-Droid

[Tor Bug Tracker & Wiki]

#27539: Create plan for releasing on F-Droid
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5, |  Actual Points:
  TorBrowserTeam201906   |
Parent ID:  #26318   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sabret00the):

 Cc: me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30872 [Circumvention/Censorship analysis]: Test BridgeDB's distribution channels in controlled experiment

[Tor Bug Tracker & Wiki]

#30872: Test BridgeDB's distribution channels in controlled experiment
---+---
 Reporter:  phw|  Owner:  dcf
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw|  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
   |  Sponsor30-can
---+---

Comment (by phw):

 Replying to [comment:1 cohosh]:
 > Can we also do a finer-grained analysis? I'm not completely familiar
 with BridgeDB, but if we have any partitions within the three main
 distribution channels, perhaps we can record data on which partition
 bridges belong to as well. So for example, if bridges distributed to yahoo
 email addresses get blocked, but riseup email addresses don't, then that
 tells us something interesting.
 [[br]]
 Yes, that would be very helpful but will require some additional trickery.
 Off the top of my head, I don't know how BridgeDB handles this. I'll have
 to look into it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 I left a number of minor comments in the GitHub pull request.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30881 [Internal Services/Tor Sysadmin Team]: answer the opsreportcard questionnaire, AKA the "limoncelli test"

[Tor Bug Tracker & Wiki]

#30881: answer the opsreportcard questionnaire, AKA the "limoncelli test"
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Tom Limoncelli is the reknowned author of [https://www.tomontime.com/ Time
 management for sysadmins] and [https://the-sysadmin-book.com/ practice of
 network and system administration], two excellent books I recommend every
 sysadmin reads attentively.

 He made up a [https://everythingsysadmin.com/the-test.pdf 32-question
 test] (PDF, website version on [http://opsreportcard.com/
 opsreportcard.com] or the
 [http://web.archive.org/web/20120827040816/http://everythingsysadmin.com:80
 /the-test.html previous one-page HTML version]) that covers the basic of a
 well-rounded setup. I believe we will get a good score, but going through
 the list will make sure we don't miss anything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30880 [Internal Services/Tor Sysadmin Team]: document backup/restore procedures

[Tor Bug Tracker & Wiki]

#30880: document backup/restore procedures
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Backup system design and restore procedures are currently not well
 documented in our wiki. Try a few restores and document the heck out of
 this. The [http://opsreportcard.com/section/11 ops report card] recommends
 services be documented with a template like this:

  1. Overview: Overview of the service: what is it, why do we have it, who
 are the primary contacts, how to report bugs, links to design docs and
 other relevant information.
  2. Build: How to build the software that makes the service. Where to
 download it from, where the source code repository is, steps for building
 and making a package or other distribution mechanisms. If it is software
 that you modify in any way (open source project you contribute to or a
 local project) include instructions for how a new developer gets started.
 Ideally the end result is a package that can be copied to other machines
 for installation.
  3. Deploy: How to deploy the software. How to build a server from
 scratch: RAM/disk requirements, OS version and configuration, what
 packages to install, and so on. If this is automated with a configuration
 management tool like cfengine/puppet/chef (and it should be), then say so.
  4. Common Tasks: Step-by-step instructions for common things like
 provisioning (add/change/delete), common problems and their solutions, and
 so on.
  5. Pager Playbook: A list of every alert your monitoring system may
 generate for this service and a step-by-step "what do to when..." for each
 of them.
  6. DR: Disaster Recovery Plans and procedure. If a service machine died
 how would you fail-over to the hot/cold spare?
  7. SLA: Service Level Agreement. The (social or real) contract you make
 with your customers. Typically things like Uptime Goal (how many 9s), RPO
 (Recovery Point Objective) and RTO (Recovery Time Objective).

 While we don't use that template anywhere yet (and it somehow conflicts
 with the [https://www.divio.com/blog/documentation/ documentation best
 practices], we can probably find a middle ground of some sort...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30877 [Core Tor/Stem]: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30877: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that 
stable is
now 0.4.0
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Stem |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  041-should, stem-ci-fail  |  Actual Points:  0.1
Parent ID:  #30827| Points:  0.1
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by atagar):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks teor, merged.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23888 [Circumvention/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
-+-
 Reporter:  oarel|  Owner:  arlolra
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-pt, ex-sponsor-19   |  Actual Points:
  ,anti-censorship-roadmap   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by arlolra):

 > do you have a good idea of when you'll be able to work on this?

 I will have lots of time starting July 1, leading up to the meeting in
 Stockholm.  Before then I will continue to make steady progress though ...
 but keep me honest about that.

 > I'm happy to jump in and help if you're running low on time, but I don't
 want to step on your toes.

 It would be helpful if you tried it out in its current state and provided
 feedback.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 > I must admit that I was assuming that, by setting up the GitLab
 instance, a decision had been made to migrate as well, but you are right
 that this decision hasn't been clearly made yet either.
 >
 > Therefore, this is also a space to have that discussion. I have heard
 rumours of concern about GitLab, but nothing clearly substanciated yet.

 Ahhh! Thank you anarcat, this makes a lot more sense.

 If some folks prefer GitLab that's great! But migrating us **away** from
 Trac is not a decision to be taken lightly, and requires community buy-in.

 I was around a decade ago for our migration to Trac, and what you're
 proposing is a big move that impacts us all. Especially if you want to
 propose shutting Trac down without redirects. As I see it there's three
 open questions...

 1. Do we want to migrate away from Trac at all?
 2. If so, what would we prefer to move to? GitHub? GitLab? Something else?
 3. What will happen with Trac's ticket and wiki data?

 This ticket is not the proper place develop consensus on such a large
 move. If you'd care to pursue this I'd suggest...

 1. Open the GitLab instance up. I tried to look at
 https://dip.torproject.org/ to see what my projects look like on it but
 I'm presented with a login page. As an open source developer this makes it
 DOA right from the starting gate. :)

 2. Begin a thread on tor-project@ to see how the community feels about
 this. I suspect if we move at all folks will prefer GitHub to GitLab, but
 I'm definitely curious to see what people think.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:1 alsmith]:
 > Another issue I'm noticing: When I download a document (.xlxs and .docx
 so far) from NextCloud, I get a many-days-old version of the document
 instead of what is in the collaborative editing version of the document.

 Oh hey, I saw an issue with nc.riseup.net that matches this behavior: Gaba
 pointed me to an xlsx hosted there, and the online version worked (after
 spending a few minutes loading), but the downloaded version was just a
 blank xlsx file. I was confused, but maybe it was giving me the many-days-
 old version, i.e. back when it first started.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alsmith):

 Another issue I'm noticing: When I download a document (.xlxs and .docx so
 far) from NextCloud, I get a many-days-old version of the document instead
 of what is in the collaborative editing version of the document.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23888 [Circumvention/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
-+-
 Reporter:  oarel|  Owner:  arlolra
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-pt, ex-sponsor-19   |  Actual Points:
  ,anti-censorship-roadmap   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by cohosh):

 We now have a final deadline (July 26) for getting this done in time for
 Roger's Defcon talk from which we will try to get volunteers.

 @arlolra: do you have a good idea of when you'll be able to work on this?
 I'm happy to jump in and help if you're running low on time, but I don't
 want to step on your toes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling it

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
it
-+-
 Reporter:  Rezonansowy  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-parity, ux-team,   |  Actual Points:
  TorBrowserTeam201906, GeorgKoppen201906|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 9cf79bcf222cfb1ca47f2cd6f119ac1f19b2f54d -- looks good (modulo what I said
 for 2a501682217eff74df47f45c60618b71f2a38353)

 02c91349acdb2a493fe0089139ae765b64250a77 -- okay
 f7238d222fe4803070f65638cd5bbd4f778a477a -- okay
 5426045ea02fb077b1d3c35f5c9f92c2f07facc3 -- okay

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30879 [Metrics/Onionperf]: Log file reprocessing shouldn't abort at first encountered line parsing error

[Tor Bug Tracker & Wiki]

#30879: Log file reprocessing shouldn't abort at first encountered line parsing
error
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I just reprocessed a bunch of log files, some of which apparently
 containing lines that cannot be parsed. Here's the output:

 {{{
 2019-06-13 15:06:47 1560431207.323223 [onionperf] [INFO] parsing log file
 at /home/karsten/op-logs/op-nl/onionperf-data/tgen-
 client/log_archive/onionperf_2019-01-03_23:59:59.tgen.log
 2019-06-13 15:06:47 1560431207.668200 [onionperf] [INFO] parsing log file
 at /home/karsten/op-logs/op-nl/onionperf-data/tor-
 client/log_archive/onionperf_2018-05-18_23:59:59.torctl.log
 2019-06-13 15:06:47 1560431207.929735 [onionperf] [INFO] parsing log file
 at /home/karsten/op-logs/op-nl/onionperf-data/tor-
 client/log_archive/onionperf_2018-10-25_23:59:59.torctl.log
 2019-06-13 15:06:47 1560431207.971164 [onionperf] [WARNING] TGenParser:
 skipping line due to parsing error: 2018-04-14 21:10:04 1523740204.809894
 [message] [shd-tgen-transfer.c:803] [_tgentransfer_log] [transfer-error]
 transport
 
TCP,17,NULL:37.218.247.40:26006,NULL:0.0.0.0:0,146.0.73.4:146.0.73.4:1313,state=SUCCESS,error=NONE
 transfer (null),26847,op-nl,NONE,0,(null),0,state=ERROR,error=AUTH total-
 bytes-read=1 total-bytes-write=0 payload-bytes-write=0/0 (-nan%) usecs-to-
 socket-create=0 usecs-to-socket-connect=8053676879205 usecs-to-proxy-
 init=-1 usecs-to-proxy-choice=-1 usecs-to-proxy-request=-1 usecs-to-proxy-
 response=-1 usecs-to-command=-1 usecs-to-response=-1 usecs-to-first-
 byte=-1 usecs-to-last-byte=-1 usecs-to-checksum=-1

 2019-06-13 15:06:47 1560431207.971545 [onionperf] [INFO] Analysing pair
 for date 2018-01-27 00:00:00
 2019-06-13 15:06:47 1560431207.971635 [onionperf] [INFO] parsing log file
 at /home/karsten/op-logs/op-nl/onionperf-data/tgen-
 client/log_archive/onionperf_2018-01-27_23:59:59.tgen.log
 }}}

 It seems like commenting out a `raise` statement fixes this:

 {{{
 diff --git a/onionperf/analysis.py b/onionperf/analysis.py
 index 0bc1811..08f4e81 100644
 --- a/onionperf/analysis.py
 +++ b/onionperf/analysis.py
 @@ -532,7 +532,7 @@ class TGenParser(Parser):
  break
  except:
  logging.warning("TGenParser: skipping line due to parsing
 error: {0}".format(line))
 -raise
 +#raise
  continue
  source.close()
 }}}

 Is this the correct fix? If so, would it make sense to add a unit test to
 test this behavior?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25483 [Circumvention/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
-+-
 Reporter:  arlolra  |  Owner:  cohosh
 Type:  project  | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201805, ex-|  Actual Points:
  sponsor-19, anti-censorship-roadmap|
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-

Comment (by cmm323):

 Replying to [comment:55 cohosh]:
 > Okay I've been trying to use libc++ with mingw-w6 as described
 [https://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-on-linux here]
 but I can't get it to work. I'm not even sure it will solve all of the
 linking problems.
 >
 > It looks like there are three paths forward from here:
 > 1. Write C wrappers as described in comment:39, or
 The wrapper already exists: https://github.com/asicerik/go-webrtc

 The issue is that it should be build with the right toolchain (probably
 the same toolchain used to build `webrtc`) so that it can be linked with
 `webrtc` library.


 > 2. Find a different webrtc library

 There's a golang implementation of WebRTC here :
 https://github.com/pion/webrtc

 Wondering if we can replace the implementation we are using with this one?

 > 3. Get CGO to compile with mingw-w64/clang on windows

 As you mentioned, these issues have not been fixed in golang. This one is
 also related: https://github.com/golang/go/issues/20982

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling it

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
it
-+-
 Reporter:  Rezonansowy  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-parity, ux-team,   |  Actual Points:
  TorBrowserTeam201906, GeorgKoppen201906|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 AffectsTails, tbb-parity, ux-team, TorBrowserTeam201906R,
 TorBrowserTeam201906, GeorgKoppen201906
 =>
 AffectsTails, tbb-parity, ux-team, TorBrowserTeam201906,
 GeorgKoppen201906
 * status:  new => needs_revision


Comment:

 Replying to [comment:53 acat]:
 > > with the corresponding ones from DTD in securityLevel.js
 (​https://github.com/acatarineu/tor-browser/commit/30429+1).
 > Sorry, this was not the right commit implementing this. The duplicated
 translations removal is https://github.com/acatarineu/tor-
 browser/commit/6647e87dc1ed59c5b39e8618bf8753d1d8423343, and the rest of
 the torbutton work in tor-browser is in https://github.com/acatarineu/tor-
 browser/commit/8f841e5ccd0af5b1f73f5f9c74bb0fd866ba4c33.
 >
 > The torbutton branch with the changes is
 https://github.com/acatarineu/torbutton/commits/10760.

 Let's start with the Torbutton changes here:

 2a501682217eff74df47f45c60618b71f2a38353 -- please add the dependent
 changes to other files to this commit as well so it is self-contained as
 much as possible (there are still mentions of `torcookiedialog.xul`,
 `popup.xul` etc. in other files)

 18e7226776301a82bb2c5715739b25f9c2b281ad -- There are several things to
 fix up/think through, in no particular order:

 1) What is the reason for commenting out code in the patch? If we don't
 need it then we should remove it. Additionally, the `torbutton-new-
 identity` part is even disabled only sometimes but it's not obvious why
 not every time.

 2) In `torbutton_utils.js` there is `Services` used, but `// let {
 Services }`

 3) In aboutTor.js (and `cookie-jar-selector.js` + `domain-isolator.js` +
 `dragDropFilter.js` + `external-app-blocker.js` + `torCheckService.js` +
 `torbutton-logger.js` + partly `tor-control-port.js` + `utils.js`)
 we have
 {{{
 const {XPCOMUtils}
 const {Services}
 }}}
 while having spaces after and before the curly braces elsewhere in the
 same changes, please stick to one style.

 4) nsIObserverService in cookie-jar-selector.js -> Services.obs

 5) `+  QueryInterface: ChromeUtils.generateQI([Ci.nsISupports,
 Ci.nsIClassInfo]),`

 Why suddenly here `Ci.nsISupports` but a lot of other `generateQI()` calls
 don't have it? There is more of this in other components, like `domain-
 isolator.js`, `dragDropFilter.js`, `external-app-blocker.js`,
 `torCheckService.js`, `torbutton-logger.js`

 6) s/mecanism/mechanism/ in `noscript-control.js`

 7) Why do we need to resort to `broadCastAsyncMessage` and
 `sendAsyncMessage` would not be enough?

 8) There is an `addTab` call in `menu-overlay.xul` that needs to get
 adjusted

 9)
 {{{
 eventSuppressor = browser.contentWindow.
 QueryInterface(Ci.nsIInterfaceRequestor).
getInterface(Ci.nsIDOMWindowUtils);
 }}}
 We should use `windowUtils` here as well, no? Not sure whether we can just
 take `m_tb_domWindowUtils` or actually need the content window version,
 though.

 8) It seems you missed to adapt `startup-observer.js` and doing all the
 clean-up there, too?

 9) In `aboutTor-content.js` replace
 {{{
 let brandBundle = Cc["@mozilla.org/intl/stringbundle;1"]
   .getService(Ci.nsIStringBundleService)
 }}}
 with `Services.strings`?

 10) `new Array()` in `let tabsToRemove = new Array();` in torbutton.js
 should get changed as well.

 11) There are `nsICookieManager2` calls in `cookie-jar-selector.js` which
 could get replaced by `Services.cookies`.

 Marking this as `needs_revision` while I look over the other commits.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's

[Tor Bug Tracker & Wiki]

#28849: Handle dormant mode in process library and for PT's
-+-
 Reporter:  ahf  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  042-proposed, network-team-  |  Actual Points:  2.5
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  3
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  042-proposed => 042-proposed, network-team-roadmap-2019-Q1Q2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29260 [Circumvention/Snowflake]: Should Snowflake proxies have a way to identify themselves to the broker

[Tor Bug Tracker & Wiki]

#29260: Should Snowflake proxies have a way to identify themselves to the broker
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Circumvention/Snowflake  |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:  #29207   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * status:  new => assigned
 * keywords:  ex-sponsor-19 => ex-sponsor-19, anti-censorship-roadmap
 * owner:  cohosh => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-+-
 Reporter:  cohosh   |  Owner:  ahf
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, design, ex-sponsor-19,|  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  snowflake, design, ex-sponsor-19 => snowflake, design, ex-
 sponsor-19, anti-censorship-roadmap
 * status:  new => assigned
 * owner:  (none) => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29736 [Circumvention/Snowflake]: Use WebSocket protocol to communicate between snowflake proxies and broker

[Tor Bug Tracker & Wiki]

#29736: Use WebSocket protocol to communicate between snowflake proxies and 
broker
-+-
 Reporter:  cohosh   |  Owner:  ahf
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, websocket, ex-|  Actual Points:
  sponsor-19, anti-censorship-roadmap|
Parent ID:  #29207   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  snowflake, websocket, ex-sponsor-19 => snowflake, websocket,
 ex-sponsor-19, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30368 [Circumvention/Snowflake]: Run some tests to check reachability of snowflake proxies

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---
Changes (by gaba):

 * keywords:   => anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25483 [Circumvention/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
-+-
 Reporter:  arlolra  |  Owner:  cohosh
 Type:  project  | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201805, ex-|  Actual Points:
  sponsor-19, anti-censorship-roadmap|
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by gaba):

 * keywords:  TorBrowserTeam201805, ex-sponsor-19 => TorBrowserTeam201805,
 ex-sponsor-19, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25429 [Circumvention/Snowflake]: Need something better than client's `checkForStaleness`

[Tor Bug Tracker & Wiki]

#25429: Need something better than client's `checkForStaleness`
-+-
 Reporter:  arlolra  |  Owner:  cohosh
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by gaba):

 * keywords:  ex-sponsor-19 => ex-sponsor-19, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29259 [Circumvention/Snowflake]: Ensure high test coverage for Snowflake

[Tor Bug Tracker & Wiki]

#29259: Ensure high test coverage for Snowflake
-+-
 Reporter:  ahf  |  Owner:  cohosh
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Circumvention/Snowflake  |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  ex-sponsor-19 => ex-sponsor-19, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29864 [Internal Services/Tor Sysadmin Team]: consider replacing nagios with prometheus

[Tor Bug Tracker & Wiki]

#29864: consider replacing nagios with prometheus
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 about such transitions, there was a good talk at srecon2019:

 https://noidea.dog/blog/srecon-americas-2019#block-
 yui_3_17_2_1_1553909927526_122915
 https://www.usenix.org/conference/srecon19americas/presentation/lykke
 https://www.usenix.org/sites/default/files/conference/protected-
 files/sre19amer_slides_lykke.pdf
 https://twitter.com/tammybutow/status/1110194448472989697

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #5304 [Circumvention/Obfs4]: Obfsproxy should respect OutboundBindAddress in torrc

[Tor Bug Tracker & Wiki]

#5304: Obfsproxy should respect OutboundBindAddress in torrc
-+-
 Reporter:  korobkov |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec-change needs-tor-change,  |  Actual Points:  0.25
  anti-censorship-roadmap|
Parent ID:  #30471   | Points:  1
 Reviewer:  phw  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  needs-spec-change needs-tor-change,sponsor19-can => needs-
 spec-change needs-tor-change, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29863 [Circumvention/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
+--
 Reporter:  cohosh  |  Owner:  (none)
 Type:  task| Status:
|  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  snowflake, anti-censorship-roadmap  |  Actual Points:
Parent ID:  #30152  | Points:
 Reviewer:  |Sponsor:
|  Sponsor30-can
+--
Changes (by gaba):

 * keywords:  snowflake => snowflake, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- proxy protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- proxy protocol for Snowflake
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19, anti-censorship-  |  Actual Points:
  roadmap|
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  ex-sponsor-19 => ex-sponsor-19, anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23888 [Circumvention/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
-+-
 Reporter:  oarel|  Owner:  arlolra
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-pt, ex-sponsor-19   |  Actual Points:
  ,anti-censorship-roadmap   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

 * keywords:  ux-team, tor-pt, ex-sponsor-19 => ux-team, tor-pt, ex-
 sponsor-19,anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #11330, #15404, #20813, #26542, ...

[Tor Bug Tracker & Wiki]

Batch modification to #11330, #15404, #20813, #26542, #10831, #21314, #24607, 
#25595, #25681, #26543, #28651, #29274, #29296 by gaba:


--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---
Changes (by gaba):

 * keywords:   => anti-censorship-roadmap


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21315 [Circumvention/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+---
 Reporter:  arma |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor28-can
-+---
Changes (by phw):

 * reviewer:  irl => phw


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22755 [Circumvention/BridgeDB]: Use stem to create test descriptors

[Tor Bug Tracker & Wiki]

#22755: Use stem to create test descriptors
-+-
 Reporter:  atagar   |  Owner:  phw
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Minor| Resolution:
 Keywords:  python, stem, bridgedb-parsers,  |  Actual Points:
  bridgedb-ci|
Parent ID:   | Points:  1
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by phw):

 * reviewer:   => sysrqb


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- proxy protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- proxy protocol for Snowflake
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:   | Points:  6
 Reviewer:  dcf  |Sponsor:  Sponsor28-must
-+
Changes (by gaba):

 * reviewer:   => dcf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30878 [Circumvention/Snowflake]: Set up snowbox to simulate censorship

[Tor Bug Tracker & Wiki]

#30878: Set up snowbox to simulate censorship
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:  #29259   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 Adding a note here to look into whether chutney will help with this

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29285 [Circumvention/Pluggable transport]: Improve the PT spec and how PTs interface with Tor

[Tor Bug Tracker & Wiki]

#29285: Improve the PT spec and how PTs interface with Tor
-+-
 Reporter:  cohosh   |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2,  |  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by dcf):

 Replying to [comment:8 mcs]:
 > The module within Tor Launcher that implements Moat (interactive bridge
 retrieval) is another example of the above. We did that so we could reuse
 your Meek PT implementation. See https://gitweb.torproject.org/tor-
 launcher.git/tree/src/modules/tl-bridgedb.jsm?h=maint-0.2.18#n188

 Oh good call, IIRC on the server side of Moat as well there is some half-
 baked shell script managing the meek-server process, that could be
 replaced with ptadapter (#29096).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30878 [Circumvention/Snowflake]: Set up snowbox to simulate censorship

[Tor Bug Tracker & Wiki]

#30878: Set up snowbox to simulate censorship
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  ex-sponsor-19|  Actual Points:
Parent ID:  #29259   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--
Description changed by cohosh:

Old description:

> We can use the VPS in china to see how current blocking affects Tor
> clients. But it doesn't tell us:
>
> - How this impacts the user experience of Tor Browser
> - How future plausible censorship events will impact the experience of
> Tor Browser
> - How misbehaving snowflake proxies will impact the experience of Tor
> Browser

New description:

 We can use the VPS in china to see how current blocking affects Tor
 clients. But it doesn't tell us:

 - How this impacts the user experience of Tor Browser
 - How future plausible censorship events will impact the experience of Tor
 Browser
 - How misbehaving snowflake proxies will impact the experience of Tor
 Browser

 We should try to set up our current testing environment to do some of
 these things.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30878 [Circumvention/Snowflake]: Set up snowbox to simulate censorship

[Tor Bug Tracker & Wiki]

#30878: Set up snowbox to simulate censorship
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   |   Keywords:  ex-sponsor-19
Actual Points:   |  Parent ID:  #29259
   Points:   |   Reviewer:
  Sponsor:  Sponsor28|
-+--
 We can use the VPS in china to see how current blocking affects Tor
 clients. But it doesn't tell us:

 - How this impacts the user experience of Tor Browser
 - How future plausible censorship events will impact the experience of Tor
 Browser
 - How misbehaving snowflake proxies will impact the experience of Tor
 Browser

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29285 [Circumvention/Pluggable transport]: Improve the PT spec and how PTs interface with Tor

[Tor Bug Tracker & Wiki]

#29285: Improve the PT spec and how PTs interface with Tor
-+-
 Reporter:  cohosh   |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2,  |  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 Replying to [comment:7 dcf]:
 > Replying to [comment:5 phw]:
 > > And here's an incomplete list of existing library implementations:
 >
 > Really there are two types of PT implementations, or three if you count
 PT 2.0 additions. There aren't really standard names for these.
 > 1. IPC manager/dispatcher. As far as I know, tor and
 [https://github.com/twisteroidambassador/ptadapter] are the only two
 implementations of this. This is the thing that sets e.g.
 `TOR_PT_MANAGED_TRANSPORT_VER` and manages subprocesses of type (2).

 The module within Tor Launcher that implements Moat (interactive bridge
 retrieval) is another example of the above. We did that so we could reuse
 your Meek PT implementation. See https://gitweb.torproject.org/tor-
 launcher.git/tree/src/modules/tl-bridgedb.jsm?h=maint-0.2.18#n188

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29285 [Circumvention/Pluggable transport]: Improve the PT spec and how PTs interface with Tor

[Tor Bug Tracker & Wiki]

#29285: Improve the PT spec and how PTs interface with Tor
-+-
 Reporter:  cohosh   |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2,  |  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by dcf):

 Replying to [comment:5 phw]:
 > And here's an incomplete list of existing library implementations:

 Really there are two types of PT implementations, or three if you count PT
 2.0 additions. There aren't really standard names for these.
 1. IPC manager/dispatcher. As far as I know, tor and
 [https://github.com/twisteroidambassador/ptadapter] are the only two
 implementations of this. This is the thing that sets e.g.
 `TOR_PT_MANAGED_TRANSPORT_VER` and manages subprocesses of type (2).
 2. IPC transport/plugin. This is goptlib and pyptlib. It's a subprocess
 managed by an implementation of type (1). This is the thing that writes
 e.g. `CMETHOD` to stdout.
 3. From PT 2.0, there are also plugin/transport implementations that you
 are meant to link with directly in the same executable, without going
 through the IPC interface. There are [https://github.com/Pluggable-
 Transports/Pluggable-Transports-
 
spec/blob/master/releases/PTSpecV2.1Draft1/Pluggable%20Transport%20Specification%20v2.1%20-%20Go%20Transport%20API%20v2.1%2C%20Draft%201.pdf
 Go] and [https://github.com/Pluggable-Transports/Pluggable-Transports-
 
spec/blob/master/releases/PTSpecV2.1Draft1/Pluggable%20Transport%20Specification%20v2.1%20-%20Swift%20Transport%20API%20v1.0%2C%20Draft%201.pdf
 Swift] API spec. From talking to Brandon Wiley, my understanding is that
 everything that uses PT other than tor and ptadapter uses such an API, or
 something like it, not the IPC model.
 [https://github.com/OperatorFoundation/shapeshifter-dispatcher
 shapeshifter-dispatcher] converts implementations of type (3) into type
 (2).

 The [https://github.com/Pluggable-Transports/Pluggable-Transports-
 
spec/blob/master/releases/PTSpecV2.1Draft1/Pluggable%20Transport%20Specification%20v2.1%20-%20Base%20Specification%20v2.1%2C%20Draft%201.pdf
 Pluggable Transports Base Spec v2.1] calls types (1) and (2) "IPC" and
 type (3) "API".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 some more numbers on trac:

 * ~1GB of attachments
 * 4GB pgsql database

 the actual server uses around 25GB of disk space because of random junk
 here and there but that's the very minimum it can be trimmed down to.
 naturally, we can keep *that* data forever, the problem is keeping the app
 running on top of that...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #27801 [Core Tor/Tor]: tor_api: CreateConnection() interface

[Tor Bug Tracker & Wiki]

#27801: tor_api: CreateConnection() interface
-+--
 Reporter:  sysrqb   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  040-deferred-201915  |  Actual Points:
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by DCNick3):

 I would propose these changes in embedding API:
 {{{

 /* The actual type depends on backend */
 typedef void tor_main_token_t;

 typedef void (*tor_ready_callback_t)(tor_main_token_t*, void*);
 typedef void (*tor_stop_callback_t)(tor_main_token_t*, void*);

 /** Requests resource allocation for tor_api_create_connection() to work
 */
 int tor_main_configuration_enable_create_connection(
 tor_main_configuration_t *cfg, int enable);

 int tor_main_configuration_register_callbacks(
 tor_main_configuration_t *cfg, tor_ready_callback_t ready,
 tor_stop_callback_t stop, void* userdata);

 tor_embedded_socket_t tor_api_create_connection(tor_main_token_t *tok,
 const char *hostname,
 uint16_t port);

 tor_embedded_socket_t tor_main_configuration_setup_control_socket(
   tor_main_configuration_t *cfg);
 }}}

 (`tor_control_socket_t` renamed to `tor_embedded_socket_t`. This breaks
 API, but we can allow usage of `tor_control_socket_t` as deprecated
 behavior or introduce another type of socket for the connection).

 It is safe to run functions taking token only between calling of
 `tor_ready_callback_t` and `tor_stop_callback_t` for this token (Not
 inside stop callback, but possibly inside ready callback). Token would
 implements locking inside, so it would be safe to call token-related
 functions from multiple threads. Stop callback won't be called during
 API's method execution, so there should not be races.

 Internally, `tor_runner` would request socks unix socket allocation and
 use it for connections. When embedding tor directly, call to
 `tor_api_create_connection()` would allocate a new socket pair, add one of
 them to the connection list inside tor in the way similar to transparent
 proxy handling and return another one.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29211 [Core Tor/Tor]: Distribute config.c functionality across more modules

[Tor Bug Tracker & Wiki]

#29211: Distribute config.c functionality across more modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  15
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by gaba):

 * status:  new => assigned
 * owner:  (none) => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30368 [Circumvention/Snowflake]: Run some tests to check reachability of snowflake proxies

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---

Comment (by cohosh):

 Updated the results. As before, my script still has some flaws where the
 CA probe site records its own IP address for some of the values (which is
 why you see only CN probes to some snowflakes).

 Overall, since switching the tests to the new STUN server, there have been
 no problems reaching snowflakes. We might get more interesting results
 after changing the STUN server in the release (#30579)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30368 [Circumvention/Snowflake]: Run some tests to check reachability of snowflake proxies

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28-can
-+---
Changes (by cohosh):

 * Attachment "snowflake-reachability-2019-06-13.pdf" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 and before everyone goes off the rails freaking out about me shutting down
 Trac tomorrow forever, please:

 =     DON'T PANIC!     

 the main objective  in opening this ticket is to brainstorm and document
 how to *possibly* migrate from Trac to GitLab. it's going to take some
 time and we'll get to talk about it.

 if you have objections, they are welcome and you can state them here! but
 please stay calm, we're doing this for the win and hopefully make everyone
 happier with our tools, not the opposite. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  The wiki of trac can be easily redirect without a gigantic redirect
 file because it can be set in the section and page directly.
 >
 > Tickets are a different story.
 >
 > Gitlab is also organized in projects and we have been using Trac with
 tags. We might not have a complete mapping between the two that doesn't
 overlap two projects and we might have to make some hard choices.

 I think it's a similar problem, actually: every ticket, every wiki page is
 in this single project in Trac. I doubt that it makes sense to keep the
 same "one gigantic wiki" approach if/when we migrate to GitLab: each
 project or team could have its own wiki...

 So we will *probably* want to split wikis *and* tickets up by "component"
 or some sort of delimiter. This could be done in the migration or after,
 in GitLab.

 > Furthermore when we did the last survey about trac vs github a few years
 ago we talked that trac links had been used as references for papers so
 preserving those was a hard requirement.

 Yes, that was my understanding as well. One thing I am thinking of is to
 make sure that, in the migration, the original URL of the migrated page
 (ticket or wiki) is retained somewhere in GitLab so that it can be
 searched. That way we could have a redirection that finds that stuff more
 easily. I don't know how practical that can be, but that's the kind of
 stuff we'll find out about when we start working on the migration.

 > I am personally for making trac read only and above all not searchable.
 That way we save a lot of resources and we still preserve old tickets.

 Well, maybe I'm not familiar enough with Trac, but what does that
 *actually* mean? We might be able to disable all users and disable user
 registration, but then people can still search for tickets and crawl the
 website and cause trouble. If we disable all queries, then people can't
 find tickets any more, and I'm not even sure we can just disable searching
 like that.

 In any case, this all means maintaining Trac forever: "readonly" still
 means "Trac is installed, running, upgraded and maintained", and I would
 very much like to stop doing that eventually.

 > Finally, I think we should start to migrate active tickets of certain
 projects only at this point, so that we don't go through a radical switch
 from one system to another, also while we just freeze old tickets.

 So my enquiries so far at the migration systems is they (well, "it",
 really) proceed in one big batch, per Trac project. Because we have a
 single Trac project, it will actually be pretty difficult to migrate
 tickets one at a time: I suspect that will not be possible at all, and
 especially tricky if we want to retain ticket number associations.

 To put it quite bluntly, we're need to shit or get off the pot here at
 some point. :) Maybe a few teams can start using it for new projects: the
 website stuff is a good example. Or small projects can be migrated if they
 don't mind losing ticket references.

 But if ticket portability is that critical, I think the only way this can
 be ensured in the long term is to do a proper migration, with Trac ticket
 metadata embedded inside GitLab tickets.

 Because there's no way we can keep maintaining Trac forever and I am not
 sure at all we'll be able to permanently archive it. That's still an open
 question, mind you, but I can't help but feel that if we're going to
 migrate tickets anyways, we might as well do it correctly...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.0
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * actualpoints:  0.5 => 1.0


Comment:

 Replying to [comment:4 catalyst]:
 > Replying to [comment:1 teor]:
 > > This bug was introduced in in 0.2.1.5-alpha, when tor_addr_lookup()
 was called tor_addr_port_parse().
 > >
 > > The first commit fixes the bug, the next two commits refactor the code
 so the logic is clearer. I split tor_addr_lookup() into 3 separate
 functions as part of the refactor, the split gets rid of a practracker
 exception.
 > >
 > > See my pull request https://github.com/torproject/tor/pull/1068
 > >
 > > This change will break some rare, invalid tor configs, so we can't
 backport it.
 > Thanks! This looks good by visual inspection. The commit structure is
 helpful. The first commit could use a few minor changes:
 > * Add a changes file

 The PR already has changes/bug30721:
 https://github.com/torproject/tor/pull/1068/files#diff-
 82ae46251bd81539f5fb75c1d7e7a82b

 > * Maybe add unit tests to ensure that IPv4 addresses with square
 brackets get rejected?

 Hmm yeah the unit tests are not in a great state. I'm working on them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 The wiki of trac can be easily redirect without a gigantic redirect file
 because it can be set in the section and page directly.

 Tickets are a different story.

 Gitlab is also organized in projects and we have been using Trac with
 tags. We might not have a complete mapping between the two that doesn't
 overlap two projects and we might have to make some hard choices.

 Furthermore when we did the last survey about trac vs github a few years
 ago we talked that trac links had been used as references for papers so
 preserving those was a hard requirement.

 I am personally for making trac read only and above all not searchable.
 That way we save a lot of resources and we still preserve old tickets.

 Finally, I think we should start to migrate active tickets of certain
 projects only at this point, so that we don't go through a radical switch
 from one system to another, also while we just freeze old tickets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old description:

> having both Trac and GitLab for TPO might not be desirable in the long
> term, both for maintenance and consistency. if GitLab is okay for people,
> we should consider migrating to it and turning off (or turning into a
> static website) this Trac instance.

New description:

 Having both Trac and GitLab for TPO is not desirable in the long term,
 both for maintenance and consistency across projects.

 If GitLab is okay for people, we should consider migrating to it and
 turning off (or turning into a static website) this Trac instance.

 This ticket explores the practicalities behind this project.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 So while I personnally believe we should migrate to GitLab for a variety
 of reasons, we may want to keep running Trac forever instead. I suspect
 that will not be the case, but I'm open to the idea.

 What I am strongly against, however, is running *both* software
 indefinitely. They are *both* complex pieces of machinery (GitLab maybe
 even more so) and it would me nonsensical to run them both at the same
 time. That would make basically *everyone* unhappy: people unhappy with
 trac or GitLab would still have to deal with it, and I, as a sysadmin,
 would still need to maintain both as well. That's the "status quo" option
 1, above, and I really think it's a bad idea.

 If we're going to use GitLab, we should migrate. I don't think it's
 reasonable to maintain both services forever. I must admit that I was
 assuming that, by setting up the GitLab instance, a decision had been made
 to migrate as well, but you are right that this decision hasn't been
 clearly made yet either.

 Therefore, this is also a space to have that discussion. I have heard
 rumours of concern about GitLab, but nothing clearly substanciated yet.

 Also, just to keep the idea open and recognize a decision hasn't actually
 been made, I'll add the "option zero" of not using GitLab at all and
 shutting down the experiment. I feel that's also the wrong way to go as
 people are generally enthusiastic about the project, but I'll keep an open
 mind. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30799 [Core Tor/Tor]: Fix a small memory leak in nt_service_install() in ntmain.c

[Tor Bug Tracker & Wiki]

#30799: Fix a small memory leak in nt_service_install() in ntmain.c
-+-
 Reporter:  xiaoyinl |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very Low |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Trivial  | Resolution:
 Keywords:  no-backport, 041-can, memory-|  Actual Points:  0.1
  management, unreachable-code   |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 I did the changes file and the practracker fix, so this is now ready for
 merge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29263 [Core Tor/Chutney]: prop289: add bidirectional data transfers to chutney

[Tor Bug Tracker & Wiki]

#29263: prop289: add bidirectional data transfers to chutney
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, network-team-   |  Actual Points:  2
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Seems to work fine now, except for 0.3.4, which is an expected fail.

 Let's re-run CI after the #30876 merge, and then merge this PR?

 We'll need to close and re-open the pull request so GitHub re-does the
 merge to master.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30876 [Core Tor/Chutney]: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30876: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that 
stable
is now 0.4.0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-should, chutney-ci-fail  |  Actual Points:  0.1
Parent ID:  #30826   | Points:  0.1
 Reviewer:  nickm|Sponsor:  Sponsor31-can
-+-
Changes (by teor):

 * reviewer:   => nickm


Comment:

 nickm will probably review this, if someone else doesn't get to it first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30877 [Core Tor/Stem]: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30877: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that 
stable is
now 0.4.0
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Stem |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-should, stem-ci-fail  |  Actual Points:  0.1
Parent ID:  #30827| Points:  0.1
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my PR:
 https://github.com/torproject/stem/pull/17

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30877 [Core Tor/Stem]: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30877: Remove 0.3.4 and experimental-0.4.0 from stem's CI, and note that 
stable is
now 0.4.0
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  041-should, stem-ci-fail
Actual Points:  0.1|  Parent ID:  #30827
   Points:  0.1|   Reviewer:
  Sponsor:  Sponsor31-can  |
---+--
 We removed some builds as part of #30836, so we need to fix CI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30876 [Core Tor/Chutney]: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30876: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that 
stable
is now 0.4.0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-should, chutney-ci-fail  |  Actual Points:  0.1
Parent ID:  #30826   | Points:  0.1
 Reviewer:   |Sponsor:  Sponsor31-can
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my pull request:
 https://github.com/torproject/chutney/pull/33

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30876 [Core Tor/Chutney]: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that stable is now 0.4.0

[Tor Bug Tracker & Wiki]

#30876: Remove 0.3.4 and experimental-0.4.0 from chutney's CI, and note that 
stable
is now 0.4.0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core |Version:
  Tor/Chutney|
 Severity:  Normal   |   Keywords:  041-should, chutney-ci-fail
Actual Points:  0.1  |  Parent ID:  #30826
   Points:  0.1  |   Reviewer:
  Sponsor:  Sponsor31-can|
-+-
 We removed some builds as part of #30836, so we need to fix CI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Hi anarcat. This ticket's description argues against having both trac and
 gitlab, but does not explain why we're migrating to gitlab. Where was this
 decided? Mind pointing this ticket toward that thread?

 Last year there was some [https://lists.torproject.org/pipermail/metrics-
 team/2018-July/000821.html discussion regarding github], but my
 understanding was that we're keeping our tpo git and trac instances as
 they are.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30683 [Applications/Tor Browser]: Properties in dom/locales/$lang/chrome/ allow detecting user locale

[Tor Bug Tracker & Wiki]

#30683: Properties in dom/locales/$lang/chrome/ allow detecting user locale
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-locale  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Replying to [ticket:30683 gk]:
 > z3t reported a bunch of issues on HackerOne regarding detection of user
 locale with the help of `dom/locales/$lang/chrome/` properties. PoCs done
 by z3t:
 >
 > `dom/dom.properties`:
 https://people.torproject.org/~gk/tests/tor_form_locale_leak.html

 `` is relevant here as well (thanks to mik317 on
 HackerOne for pointing this out).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs