Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201911 => TorBrowserTeam201911R


--
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] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:17 JeremyRand]:
 > Thanks for the feedback Georg.  I've just pushed a revised set of
 patches (same branch as before; Git commit hash
 `26c5593a9230e22b52b03917ad274b8ea08a70b5`) that I believe addresses your
 review so far.
 >
 > > Alas, I don't have time to review everything at once. My current plan
 is to go commit by commit and let you fix up things as we go. I hope this
 works for you.
 >
 > Yes, in fact that's better than reviewing everything at once, since it
 lets me start addressing feedback sooner.
 >
 > > I guess that hard-coding is done by taking the Tor Browser default
 values? One thing to keep in mind is that not every user is using 9150 as
 the SOCKS port. I don't know how hard it is to make this more dynamic but
 it would be nice if it were possible (but it's not necessary for a nightly
 inclusion).
 >
 > Doing this the "right way" will probably require patching Electrum-NMC;
 I'll put it on my to-do list.  That said, can you elaborate on what types
 of users will be using a non-default SOCKS IP/port?  The only cases I can
 think of are setups like Tails and Whonix, and those setups will need
 other changes to work with Namecoin because they use a control port filter
 that will interfere with StemNS.  I definitely want to support those use
 cases (if nothing else because Whonix is my daily driver OS), but I'm
 curious if there's another set of use cases where this matters that I'm
 not aware of.

 We have users that want to avoid using Tor Browser's tor but rather like
 to point to a system tor which they have running anyway. Granted, it's not
 the majority of users (by far) but it's an important use-case we support
 at least.

--
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] #32559 [Core Tor/Tor]: Travis: run chutney with clang for better diagnostics

[Tor Bug Tracker & Wiki]

#32559: Travis: run chutney with clang for better diagnostics
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  network-team-roadmap-november,   |  Actual Points:
  consider-backport-immediately, 029-backport,   |
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_revision => closed
 * resolution:   => wontfix


Comment:

 Using clang doesn't make a difference on Travis, we must have an earlier
 version. And there don't seem to be any obvious extra libraries to
 install.

--
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

[Tor Bug Tracker & Wiki]

#32549: NoScript makes requests to sync-messages.invalid
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 {{{
 TypeError: aNode is null CustomizableUI.jsm:1984:5
 }}}
 in NoScript Options on Windows.

--
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] #32427 [Core Tor/Tor]: Refactor options_act_reversible into manageable chunks

[Tor Bug Tracker & Wiki]

#32427: Refactor options_act_reversible into manageable chunks
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  2.5
Parent ID:  #32408 | Points:
 Reviewer:  teor   |Sponsor:  Sponsor31-can
---+---
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Seems fine to me.

 The chutney CI job failed due to a network error, I restarted it.

 The master merge in the PR doesn't have #32555. But the chutney job
 succeeded, probably because it's on gcc.

 So I opened #32559 to switch our Travis CI chutney to clang. I'm testing
 to see if it fails now.

--
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] #32555 [Core Tor/Tor]: Memory leak on or_options_t?

[Tor Bug Tracker & Wiki]

#32555: Memory leak on or_options_t?
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  043-regression  |  Actual Points:  .1
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:  Sponsor31-must
+

Comment (by teor):

 I opened #32559 to switch our Travis CI chutney to clang.

--
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] #32559 [Core Tor/Tor]: Travis: run chutney with clang for better diagnostics

[Tor Bug Tracker & Wiki]

#32559: Travis: run chutney with clang for better diagnostics
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-november,   |  Actual Points:
  consider-backport-immediately, 029-backport,   |
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 Test build is here:
 * https://travis-ci.org/teor2345/tor/builds/614819545

 Still needs a backport, and a changes file.
 0.2.9 could be interesting, we don't have a lot of jobs to play with
 there.

--
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] #32552 [Core Tor/Nyx]: can't connect to for, whether using cookie or password

[Tor Bug Tracker & Wiki]

#32552: can't connect to for, whether using cookie or password
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Latest stem from git working fine

--
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] #32465 [Circumvention/Snowflake]: Use gorilla websocket instead of x/net websocket in proxy-go

[Tor Bug Tracker & Wiki]

#32465: Use gorilla websocket instead of x/net websocket in proxy-go
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arlolra):

 * status:  assigned => needs_review


Comment:

 Here's a stab at this,
 https://github.com/keroserene/snowflake/commits/trac32465

 I was able to bootstrap a client with 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

[tor-bugs] #32559 [Core Tor/Tor]: Travis: run chutney with clang for better diagnostics

[Tor Bug Tracker & Wiki]

#32559: Travis: run chutney with clang for better diagnostics
-+-
 Reporter:  teor |  Owner:  teor
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  network-team-roadmap-november,
 Severity:  Normal   |  consider-backport-immediately, 029-backport,
 |  035-backport, 040-backport, 041-backport,
 |  042-backport
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 In #32555 and #32427, we discovered that clang picks up some memory
 errors, but gcc does not.

--
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] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Finished for today. Few updates...

 * [https://gitweb.torproject.org/stem.git/commit/?id=36a3ca2 Fixed python
 3.x blinding].
 * Replied to the pull request comments.
 * It sounds like Paul might be able to help with our
 [https://github.com/pyca/cryptography/issues/5068 cryptography blinding
 performance issue].

--
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] #32552 [Core Tor/Nyx]: can't connect to for, whether using cookie or password

[Tor Bug Tracker & Wiki]

#32552: can't connect to for, whether using cookie or password
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 BTW it's defaults python on arch Linux

--
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] #27268 [Applications/Tor Browser]: preferences cleanup

[Tor Bug Tracker & Wiki]

#27268: preferences cleanup
+--
 Reporter:  rzb |  Owner:  gk
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201911  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--

Comment (by Thorin):

 https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000
 -tor-browser.js?h=tor-browser-68.2.0esr-9.5-1#n208
 - `devtools.webide.autoinstallADBHelper` (which you set to false) was
 removed in F64 and replaced by `devtools.webide.autoinstallADBExtension`
 (which you don't set and is at default true) -
 https://bugzilla.mozilla.org/show_bug.cgi?id=1491315
 - `devtools.webide.autoinstallFxdtAdapters` was deprecated in FF57 -
 https://bugzilla.mozilla.org/show_bug.cgi?id=1393497

--
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] #32552 [Core Tor/Nyx]: can't connect to for, whether using cookie or password

[Tor Bug Tracker & Wiki]

#32552: can't connect to for, whether using cookie or password
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 As for Debian or Ubuntu, this ticket is about Arch.

 I think your question is exactly the right one: do a hotfix now, or wait
 some more weeks for the intended next release?

 I guess it depends in part on how many more confused users we hear from --
 and how many confused users we think that there are behind the scenes who
 just aren't reporting the breakage.

--
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] #27992 [Core Tor/Tor]: config DataDirectoryGroupReadable 1 is overridden if you set KeyDir == DataDir

[Tor Bug Tracker & Wiki]

#27992: config DataDirectoryGroupReadable 1 is overridden if you set KeyDir ==
DataDir
-+-
 Reporter:  needle8420   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  DataDirectoryGroupReadable intro |  Actual Points:  .1
  BugSmashFund   |
Parent ID:   | Points:  #32427
 Reviewer:  teor |Sponsor:
-+-
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

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


Comment:

 I'm reopening this ticket, so we can make our Makefile support more than
 one bridge.

--
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] #32532 [Internal Services/Tor Sysadmin Team]: Install ZNC on Chives, make pastly admin it

[Tor Bug Tracker & Wiki]

#32532: Install ZNC on Chives, make pastly admin it
-+-
 Reporter:  pastly   |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pastly):

 Replying to [comment:9 anarcat]:
 > Do you want me to merge your github branch it or are you going to push
 it yourself to git-rw?

 I don't think I have access to that repo (haven't tried). Instead of me
 gaining access, I think it would be easiest and best for you to just grab
 my commits and push them yourself.

 Should you do so now? Nah. Let me add how to add ZNC users to it first.

 That would also give you a chance to clean up the document as you see fit.
 It's serving a lot of purposes right now. Maybe after this is set up then
 the only thing the document needs is the stuff I wrote. Not my call to
 make :p

--
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] #32332 [Internal Services/Service - nextcloud]: Set up LDAP authn for nc.tpn

[Tor Bug Tracker & Wiki]

#32332: Set up LDAP authn for nc.tpn
-+-
 Reporter:  ln5  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32519   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i just had the idea that we could leverage the "basic http auth" system
 for authentication here.

 the idea would be that ud-ldap would populate a "htaccess/htpasswd" kind
 of file and Nextcloud would tap into that. It seems there's support for
 configuring nextcloud to authenticate against "environment variables"
 which we could leverage for this purpose:

 
https://docs.nextcloud.com/server/11/admin_manual/configuration_server/sso_configuration.html
 #configuring-environment-based-authentication

 The advantage of this approach is that it could possibly work for *ALL*
 web apps. We would reuse the `webPassword` field in LDAP and reuse it
 everywhere... It could be used for GitLab as well, for example...

 Otherwise I don't think it's worth treating NC as a special snowflake. If
 we don't take the above approach, we should just hook it up directly into
 LDAP and accept that it might have problems if LDAP is down.

--
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] #32383 [Internal Services/Tor Sysadmin Team]: retire build-arm-* raspi boxes

[Tor Bug Tracker & Wiki]

#32383: retire build-arm-* raspi boxes
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 cleared the wiki, ipsec and nagios configuration, now really all done, and
 yes, ipsec is fully managed in puppet now.

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---

Comment (by thymbahutymba):

 Replying to [comment:6 phw]:

 > > Make it easier to get the bridge's fingerprint and/or bridge line. At
 the moment, users have to spawn a shell in the container, which is
 tedious.
 > [[br]]
 > Commit [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/d2335c91ecc04e2236158ed80bd432ee8b07e6bd d2335c91]
 adds a script that determines the bridge line.

 Remember also that since now the directory is mapped as docker volume the
 path
 {{{
 PT_STATE=/var/lib/tor/pt_state/obfs4_bridgeline.txt
 }}}
 is no longer meaningful and should be replaced with something like
 {{{
 PT_STATE=/var/lib/docker/volumes//_data/
 }}}

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---

Comment (by thymbahutymba):

 Replying to [comment:11 phw]:
 > Replying to [comment:10 cohosh]:
 > > It looks really good! I like the changes that were made. I left a few
 comments on the commits but it's good to go as is.
 > [[br]]
 > Thanks, your comments were very helpful. I addressed your feedback in
 commit [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/543e5db214acf858ca6468a6aeda9f8d69ebcff5 543e5db2],
 [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/a13b1d796a598162138023bb5c77e04742c12cf6 a13b1d79],
 and [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/2bb69bd2aebe9c1a7052de71aabae30789f9f2f1 2bb69bd2]. I
 also updated our
 [https://community.torproject.org/relay/setup/bridge/docker/ setup
 instructions] and pushed a new image tag,
 [https://hub.docker.com/repository/docker/phwinter/obfs4-bridge 0.3].

 I would like to let you know about an issue in your Makefile, with that
 solution you can't deploy more that one container in the whole system;
 therefore if you would to run more the one bridge (relay in general) you
 can't due to limitation about the volume's name that is the same every
 time. Maybe, if you don't like my solution with config-X, provide a kind
 of env file or whatever else that keep track about the number of container
 deployed. I hope I was clear enough.

--
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] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by JeremyRand):

 Thanks for the feedback Georg.  I've just pushed a revised set of patches
 (same branch as before; Git commit hash
 `26c5593a9230e22b52b03917ad274b8ea08a70b5`) that I believe addresses your
 review so far.

 > Alas, I don't have time to review everything at once. My current plan is
 to go commit by commit and let you fix up things as we go. I hope this
 works for you.

 Yes, in fact that's better than reviewing everything at once, since it
 lets me start addressing feedback sooner.

 > I guess that hard-coding is done by taking the Tor Browser default
 values? One thing to keep in mind is that not every user is using 9150 as
 the SOCKS port. I don't know how hard it is to make this more dynamic but
 it would be nice if it were possible (but it's not necessary for a nightly
 inclusion).

 Doing this the "right way" will probably require patching Electrum-NMC;
 I'll put it on my to-do list.  That said, can you elaborate on what types
 of users will be using a non-default SOCKS IP/port?  The only cases I can
 think of are setups like Tails and Whonix, and those setups will need
 other changes to work with Namecoin because they use a control port filter
 that will interfere with StemNS.  I definitely want to support those use
 cases (if nothing else because Whonix is my daily driver OS), but I'm
 curious if there's another set of use cases where this matters that I'm
 not aware of.

 > Are you sure this is needed? We are applying a lot of other patches
 without requiring `patch` being explicitly installed (because it seems to
 come at least in newer OSes installed by default).

 Yes; removing that line causes the build to fail because `patch` isn't
 found.  Maybe `patch` is only installed by default in newer versions of
 Debian than what's used here.

 > Please remove those comments here and just include those projects when
 it is time.

 Done.

 > I think we can't require users just having `python3` available yet.
 Please add a check and somewhere so users get a notice when they need to
 install `python3`.

 Done.  At the same time I also now check if their `python3` is too old,
 and give them a notice for that case too.

 > Please add a `namecoin: 0` to all the other platforms given that you are
 not only checking for Namecoin support when dealing with Linux.

 Done.

 > 1) We try to make it possible to bisect issues in tor-browser-build in
 the sense that resulting builds are still running. It's hard sometimes and
 sometimes even not really possible, but that should be the goal anyways.
 With that in mind I think the commit I looked at above should be (to a
 large extend (that is without the changes in rbm.conf)) the *last* in your
 series of patches. Usually one is adding commits for all the projects and
 then in the final commit(s) one is "activating" those by getting them
 actually build once one sets the proper flags/or builds for the respective
 platforms/architectures. It would be nice if you could follow this general
 idea.

 Good point.  I've rearranged the order and grouping of commits to
 hopefully bring it closer to what you describe.  Let me know if this is an
 improvement, and whether there's anything remaining that I should do on
 this front.

 > 2) Please don't use the submodule approach you had in mind first and
 then later on discard it in favor of including all the needed projects
 directly. Just include those projects directly. This makes the patch set
 smaller, is easier to review, and is the right thing to do anyway.

 Done.

 Thanks for the review!

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * actualpoints:   => 1.1


Comment:

 Replying to [comment:10 cohosh]:
 > It looks really good! I like the changes that were made. I left a few
 comments on the commits but it's good to go as is.
 [[br]]
 Thanks, your comments were very helpful. I addressed your feedback in
 commit [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/543e5db214acf858ca6468a6aeda9f8d69ebcff5 543e5db2],
 [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/a13b1d796a598162138023bb5c77e04742c12cf6 a13b1d79],
 and [https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/commit/2bb69bd2aebe9c1a7052de71aabae30789f9f2f1 2bb69bd2]. I
 also updated our
 [https://community.torproject.org/relay/setup/bridge/docker/ setup
 instructions] and pushed a new image tag,
 [https://hub.docker.com/repository/docker/phwinter/obfs4-bridge 0.3].

--
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] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser

[Tor Bug Tracker & Wiki]

#30579: Add more STUN servers to the default snowflake configuration in Tor 
Browser
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  stun, anti-censorship-roadmap-   |  Actual Points:  .3
  october|
Parent ID:  #31281   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by cohosh):

 * actualpoints:   => .3


--
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] #30381 [Core Tor/Tor]: Provide control port commands to ADD/REMOVE/VIEW v3 client-auth

[Tor Bug Tracker & Wiki]

#30381: Provide control port commands to ADD/REMOVE/VIEW v3 client-auth
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:  4.5
  auth, network-team-roadmap-september,  |
  042-deferred-20190918  |
Parent ID:  #14389   | Points:  6
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 Replying to [comment:24 mcs]:
 > `Flags=Permanent` does not seem to have any effect. Is there another
 ticket for that or should someone open one?

 Wow you are right! `CLIENT_AUTH_FLAG_IS_PERMANENT` is not used in the HS
 client code. We need to open a ticket for this. I've pinged asn about it.
 Thanks mcs!

--
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] #32532 [Internal Services/Tor Sysadmin Team]: Install ZNC on Chives, make pastly admin it

[Tor Bug Tracker & Wiki]

#32532: Install ZNC on Chives, make pastly admin it
-+-
 Reporter:  pastly   |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => accepted


Comment:

 > I'm assigning the ticket back to you because I think that's how you're
 keeping track of what's on your plate vs what is on mine. If this was
 inappropriate, please excuse my ignorance.

 Not at all! That's exactly what I was expecting. :) will followup soon.

 Do you want me to merge your github branch it or are you going to push it
 yourself to git-rw?

 thanks for your work!

--
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] #30770 [Internal Services/Tor Sysadmin Team]: consider alternatives to the puppet mono-repo

[Tor Bug Tracker & Wiki]

#30770: consider alternatives to the puppet mono-repo
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29387   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> another aspect of "how to publish our puppet repos" and how to
> collaborate is how to manage sub-repositories. expanding on the "mono-
> repo" problem discussed in #29387, i have found the following options:
>
>  1. current "monorepo" approach
>  2. pure [https://librarian-puppet.com/ librarian] /
> [https://github.com/puppetlabs/r10k r10k]
>  3. [https://git-scm.com/book/en/v2/Git-Tools-Submodules git submodules]
>  4. [https://github.com/git/git/blob/master/contrib/subtree/ git subtree]
> (originally from [https://github.com/apenwarr/git-subtree apenwarr] but
> now merged in mainline since git 2.22)
>  5. [https://github.com/ingydotnet/git-subrepo git subrepo]
>  6. [https://myrepos.branchable.com/ myrepos]
>  7. Puppet itself, with the [https://forge.puppet.com/puppetlabs/vcsrepo
> vcsrepo module] or the
> [https://puppet.com/docs/puppet/6.4/modules_installing.html puppet module
> command]
>
> i'll add more as i find them here. i should probably make a more detailed
> review of the advantages/inconvenients of all of those...

New description:

 another aspect of "how to publish our puppet repos" and how to collaborate
 is how to manage sub-repositories. expanding on the "mono-repo" problem
 discussed in #29387, i have found the following options:

  1. current "monorepo" approach
  2. pure [https://librarian-puppet.com/ librarian] /
 [https://github.com/puppetlabs/r10k r10k]
  3. [https://git-scm.com/book/en/v2/Git-Tools-Submodules git submodules]
  4. [https://github.com/git/git/blob/master/contrib/subtree/ git subtree]
 (originally from [https://github.com/apenwarr/git-subtree apenwarr] but
 now merged in mainline since git 2.22)
  5. [https://github.com/ingydotnet/git-subrepo git subrepo]
  6. [https://myrepos.branchable.com/ myrepos] and its numerous
 alternatives
  7. Puppet itself, with the [https://forge.puppet.com/puppetlabs/vcsrepo
 vcsrepo module] or the
 [https://puppet.com/docs/puppet/6.4/modules_installing.html puppet module
 command]

 i'll add more as i find them here. i should probably make a more detailed
 review of the advantages/inconvenients of all of those...

--

Comment (by anarcat):

 apenwarr wasn't happy with subtree so they wrote
 [https://github.com/apenwarr/git-subtrac subtrac] ([https://public-
 inbox.org/git/CAHqTa-15fKjH-3Z-
 vhhgnpfx6c1oqxbdxwkjht9jx6g+7tj...@mail.gmail.com/T/#u announcement])
 which reimplements it with submodules, in golang. might be worth taking a
 look again?

--
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] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser

[Tor Bug Tracker & Wiki]

#30579: Add more STUN servers to the default snowflake configuration in Tor 
Browser
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  stun, anti-censorship-roadmap-   |  Actual Points:
  october|
Parent ID:  #31281   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by cohosh):

 * status:  assigned => needs_information


Comment:

 Here are some lists of public servers:
 - https://gist.github.com/zziuni/3741933
 - https://gist.github.com/mondain/b0ec1cf5f60ae726202e
 - https://www.voip-info.org/stun/
 - EmerCoin is some cryptocurrency/blockchain project that
 [https://emercoin.com/en/news/global-changes-in-emercoin-blockchain-
 segwit-tx-optimizer-stun-and-13-more-updates uses STUN] and they maintain
 their own
 
[https://github.com/emercoin/emercoin/blob/8808770b98248b0174dc3d6f8c70965e13f17396/src/stun.cpp#L59
 list].

 Some possibly useful candidates:
 - `stun.services.mozilla.org`

  Mozilla's stun server is an obvious candidate, but I just checked it and
 it appears to not be working. I found this ticket while investigating:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1143827
 - `stun.gotye.com.cn`

   This appears to work. Looks like a new video/messaging/gaming service.
 See http://www.gotye.com.cn/
 - `stun.stunprotocol.org`

  Idk, it's a .org domain and it works.

 The most useful list seems to be from the
 
[https://github.com/emercoin/emercoin/blob/8808770b98248b0174dc3d6f8c70965e13f17396/src/stun.cpp#L59
 coin project]. I'd suggest referencing it again in the future and looking
 at STUN servers with TLDs in whichever region has blocked the ones we
 currently have in Snowflake (I
 
[https://web.archive.org/web/20191120211855/https://github.com/emercoin/emercoin/blob/8808770b98248b0174dc3d6f8c70965e13f17396/src/stun.cpp
 saved a current snapshot] at archive.org just in case)

 I suppose there's some risk here with choosing a random service. Snowflake
 clients leak their IP address to whichever server we choose. Perhaps a
 better route is to have the broker perform this step over the domain
 fronted connection (#25591)?

--
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] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> while working on the nextcloud project, we realized it wasn't exactly
> trivial to setup the LDAP bridge because of our specific requirements (no
> direct connexion, offline support). so we just didn't implement it yet
> (#32332). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
> procedure, but then i realized there are probably many other such
> services that do *not* connect with LDAP.
>
> On the top of my head, there's at least Trac and mailing lists, for
> example, which are managed completely separarely. Audit
> [[org/operations/services]] and see which services are manager manually
> and which aren't.
>
> Then make sure there's an automated way to add/remove users to services,
> either by hooking up the service with LDAP, or by creating a wrapper
> script that will manage those accesses.
>
> So the following needs to be done here:
>
>  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
> new-person] and https://help.torproject.org/tsa/howto/retire-a-user
> retire-a-user], the various services to add/remove people to
>  * [ ] automate the above with a script or LDAP
>
> Note that the two pages have different scope: `new-person` is about TSA
> while `retire-a-user` is broader. This should also be converged, probably
> in the broader sense.

New description:

 while working on the nextcloud project, we realized it wasn't exactly
 trivial to setup the LDAP bridge because of our specific requirements (no
 direct connexion, offline support). so we just didn't implement it yet
 (#32332). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
 procedure, but then i realized there are probably many other such services
 that do *not* connect with LDAP.

 On the top of my head, there's at least Trac and mailing lists, for
 example, which are managed completely separarely. Audit
 [[org/operations/services]] and see which services are manager manually
 and which aren't.

 Then make sure there's an automated way to add/remove users to services,
 either by hooking up the service with LDAP, or by creating a wrapper
 script that will manage those accesses.

 So the following needs to be done here:

  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
 new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
 retire-a-user], the various services to add/remove people to
  * [ ] automate the above with a script or LDAP

 Note that the two pages have different scope: `new-person` is about TSA
 while `retire-a-user` is broader. This should also be converged, probably
 in the broader sense.

 Also note that a particularly tricky situation is when we want to do a
 *partial* removal. For example, maybe the person needs to be removed from
 tor-internal, but keep access to some servers. Or removed from server, but
 keep an email alias.

 The latter case is especially sensitive: some people feel keeping their
 email alias around forever is an inalienable right and that we should keep
 forwarding their email even after they are fully retired from Tor. This
 policy needs to be clarified, see #32558 for that particularly tricky
 problem.

--

Comment (by anarcat):

 create #32558 to followup on the email problem, and expand on 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

[tor-bugs] #32558 [Internal Services/Tor Sysadmin Team]: clarify what happens to email when we retire a user

[Tor Bug Tracker & Wiki]

#32558: clarify what happens to email when we retire a user
-+
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #32519
   Points:   |   Reviewer:
  Sponsor:   |
-+
 As part of improving the offboarding process (#32519), we should
 especially look at how email works.

 Right now, when we [https://help.torproject.org/tsa/howto/retire-a-user/
 retire a user], their account is first "locked" which means their access
 to various services is disabled. But their email still works for 186 days
 (~6 months). After that date, in theory, their email aliases start
 completely dropping email (needs to be onfirmed).

 It's unclear if that's the right policy to follow. Some people feel that
 an email alias should stay around forever, as it is an inalienable human
 right.

 Others feel that certain administrative roles should be forwarded when a
 person leave. If, say, "Alice" (fictive name) was doing fundraising but
 was using `al...@torproject.org` for that work. When they leave, should we
 forward `alice@` to `fundrais...@torproject.org`?

 But then what if Alice was using their work email for private
 correspondance either? Maybe the fundraising team shouldn't be able to see
 *those* communications.

 One proposal could be that the default policy is this:

  1. email @torproject.org is "function" email and is destined only for
 torproject.org related work
  2. when a person leave their position, that email gets deactivated after
 a 6 months delay
  3. in extreme cases, some forward may be *temporarily* enabled to reset
 accesses or re-establish contacts with a provider or third-party

 It is also possible that there could be *two* policies, one for TPI
 employees and one for other TPO people.

--
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] #30381 [Core Tor/Tor]: Provide control port commands to ADD/REMOVE/VIEW v3 client-auth

[Tor Bug Tracker & Wiki]

#30381: Provide control port commands to ADD/REMOVE/VIEW v3 client-auth
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:  4.5
  auth, network-team-roadmap-september,  |
  042-deferred-20190918  |
Parent ID:  #14389   | Points:  6
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 `Flags=Permanent` does not seem to have any effect. Is there another
 ticket for that or should someone open 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] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 > Hm. I understand that _descriptor_content() arguments are default
 values, but what defines a good default value here?

 Hi George. Yup, I'm delighted to improve our defaults and this is probably
 simply a matter of us misunderstanding each other's code. Here's what you
 had...

 {{{
 def _get_fake_clients_bytes():
   """
   Generate fake client authorization data for the middle layer
   """

   final_bytes = b''
   num_fake_clients = 16  # default for when client auth is disabled

   for _ in range(num_fake_clients):
 client_id = base64.b64encode(os.urandom(8)).rstrip(b'=')
 client_iv = base64.b64encode(os.urandom(16)).rstrip(b'=')
 descriptor_cookie = base64.b64encode(os.urandom(16)).rstrip(b'=')

 final_bytes += b'%s %s %s %s\n' % (b'auth-client', client_id,
 client_iv, descriptor_cookie)

   return final_bytes


 def _get_middle_descriptor_layer_body(encrypted):
   """
   Get the middle descriptor layer as bytes
   (It's just fake client auth data since client auth is disabled)
   """

   from cryptography.hazmat.primitives.asymmetric.x25519 import
 X25519PrivateKey
   from cryptography.hazmat.primitives import serialization

   fake_pub_key = X25519PrivateKey.generate().public_key()
   fake_pub_key_bytes = fake_pub_key.public_bytes(encoding =
 serialization.Encoding.Raw, format = serialization.PublicFormat.Raw)
   fake_pub_key_bytes_b64 = base64.b64encode(fake_pub_key_bytes)
   fake_clients = _get_fake_clients_bytes()

   return b'desc-auth-type x25519\n' \
 b'desc-auth-ephemeral-key %s\n' \
 b'%s' \
 b'%s' % (fake_pub_key_bytes_b64, fake_clients, encrypted)
 }}}

 This didn't explain why values were fabricated this way so I figured it
 was simply overly complicated and inflexible (callers should have a
 mechanism to override all descriptor values).

 Since you're calling out **desc-auth-ephemeral-key** in particular here's
 your version of just that...

 {{{
 fake_pub_key = X25519PrivateKey.generate().public_key()
 fake_pub_key_bytes = fake_pub_key.public_bytes(encoding =
 serialization.Encoding.Raw, format = serialization.PublicFormat.Raw)

 b'desc-auth-ephemeral-key %s' % base64.b64encode(fake_pub_key_bytes)
 }}}

 As such, to do the same as your code I could simply change...

 {{{
 return _descriptor_content(attr, exclude, (
   ('desc-auth-type', 'x25519'),
   ('desc-auth-ephemeral-key', base64.b64encode(os.urandom(32))),
 ), (
   ('encrypted', b'\n' + inner_layer._encrypt(revision_counter,
 subcredential, blinded_key)),
 ))
 }}}

 ... to...

 {{{

 return _descriptor_content(attr, exclude, (
   ('desc-auth-type', 'x25519'),
   ('desc-auth-ephemeral-key',
 base64.b64encode(stem.util._pubkey_bytes(X25519PrivateKey.generate(,
 ), (
   ('encrypted', b'\n' + inner_layer._encrypt(revision_counter,
 subcredential, blinded_key)),
 ))
 }}}

 Is that what you would like? The base64 encoding of a random key? If so
 that's a very simple tweak to make. Or are you requesting something else?

--
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] #28800 [Applications/Tor Browser]: Implement New Identity functionality for Tor Browser on Android

[Tor Bug Tracker & Wiki]

#28800: Implement New Identity functionality for Tor Browser on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-newnym, ux-team, |  Actual Points:
  TBA-a3, tbb-8.5, tbb-parity,   |
  TorBrowserTeamTriaged, fenix-migration |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-
Changes (by sysrqb):

 * keywords:
 tbb-mobile, tbb-newnym, ux-team, TBA-a3, tbb-8.5, tbb-parity,
 TorBrowserTeam201911
 =>
 tbb-mobile, tbb-newnym, ux-team, TBA-a3, tbb-8.5, tbb-parity,
 TorBrowserTeamTriaged, fenix-migration


Comment:

 Replying to [comment:14 sisbell]:
 > Is it just a matter off hooking up this functionality or is there
 something else involved here?

 That should be most of it. We'll need a UI for it (where do we put the
 button for this?), and we need to make sure the UI doesn't hold any
 references to now-invalid objects. torbutton should handle clearing all of
 the actual data with Gecko, so we'll need to make sure we handle clearing
 any higher-level abstractions around that data (like closing all tabs when
 this is triggered, clearing any in-memory history). We'll need to send
 NEWNYM ourselves, because torbutton doesn't have a controller connection
 on Android.

 With all of that said, we're not going to work on this until after the
 fenix migration.

--
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] #32552 [Core Tor/Nyx]: can't connect to for, whether using cookie or password

[Tor Bug Tracker & Wiki]

#32552: can't connect to for, whether using cookie or password
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi Roger. There certainly is a sharp uptick in these reports over the last
 couple days which begs the question: what changed?

 This bug was originally reported by teor on #30882 but I was unable to
 reproduce this issue with python 3.5. I'm not positive what's up, but I
 **suspect** it's something like the following...

 * This bug only occurs with new python versions (3.8?).
 * Python 2.x is [https://pythonclock.org/ discontinuing at the end of
 2019].
 * A popular linux distribution (probably Debian and Ubuntu) finally made
 the python 3.x switch and picked the latest interpreter, causing the sharp
 uptick of this issue from 'obscure' to 'frequent'.

 [https://trac.torproject.org/projects/tor/ticket/32525#comment:3 I plan to
 release Stem 1.8 in December], concluding our Python 2.x support and
 Stem's 1.x series. [https://trac.torproject.org/projects/tor/ticket/31823
 Hidden service v3 support] is not mature enough to cut a stable release
 right now.

 I hate to hotfix when we're so near another release but if folks would
 like I **could** provide a Stem 1.7.2 release with this
 [https://gitweb.torproject.org/stem.git/commit/?id=b5aecb7 one line fix].
 However, if I'm correct that the uptick in these reports are coming from a
 new linux distribution this likely won't resolve confusion (due to
 debian's glacial pace). That said, it **would** change the steps to fix
 this from...

 {{{
 % git clone https://git.torproject.org/stem.git
 % cd stem
 % sudo python setup.py --install
 }}}

 ... to...

 {{{
 % sudo pip install --upgrade stem
 }}}

 Would folks prefer a hotfix or to wait for the Stem 1.8 release?

--
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] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser

[Tor Bug Tracker & Wiki]

#30579: Add more STUN servers to the default snowflake configuration in Tor 
Browser
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  stun, anti-censorship-roadmap-   |  Actual Points:
  october|
Parent ID:  #31281   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-

Comment (by cohosh):

 Okay it looks like Steam itself does not run STUN servers (or at least not
 public-facing ones) (yet). See:
 - https://github.com/ValveSoftware/GameNetworkingSockets#nat-piercing-
 icestunturn
 -
 
https://github.com/ValveSoftware/GameNetworkingSockets/issues/2#issuecomment-377643973
 - https://github.com/ValveSoftware/GameNetworkingSockets/issues/64

 It's also unclear whether Steam will eventually run a server that games
 developers can use or if game devs are expected to run their own servers.
 What we really want for this ticket are existing STUN servers that are
 already associated with popular services and therefore unlikely to be
 blocked.

--
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] #28800 [Applications/Tor Browser]: Implement New Identity functionality for Tor Browser on Android

[Tor Bug Tracker & Wiki]

#28800: Implement New Identity functionality for Tor Browser on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-newnym, ux-team, |  Actual Points:
  TBA-a3, tbb-8.5, tbb-parity,   |
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-

Comment (by sisbell):

 Looking at tor button code, we have the following comment

  The "New Identity" implementation does the following:
  *   1. Disables Javascript and plugins on all tabs
  *   2. Clears state:
  *  a. OCSP
  *  b. Cache + image cache
  *  c. Site-specific zoom
  *  d. Cookies+DOM Storage+safe browsing key
  *  e. google wifi geolocation token
  *  f. http auth
  *  g. SSL Session IDs
  *  h. last open location url
  *  i. clear content prefs
  *  j. permissions
  *  k. site security settings (e.g. HSTS)
  *  l. IndexedDB and other DOM storage
  *  m. plugin data
  *  n. media devices
  *  o. predictor network data
  *   3. Sends tor the NEWNYM signal to get a new circuit
  *   4. Opens a new window with the default homepage
  *   5. Closes this window
  *
  * XXX: intermediate SSL certificates are not cleared.

 Is it just a matter off hooking up this functionality or is there
 something else involved here?

--
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] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser

[Tor Bug Tracker & Wiki]

#30579: Add more STUN servers to the default snowflake configuration in Tor 
Browser
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  stun, anti-censorship-roadmap-   |  Actual Points:
  october|
Parent ID:  #31281   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by cohosh):

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


--
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] #32557 [Core Tor]: TOR crashes when AvoidDiskWrites and/or DisableAllSwap defined in `torrc`

[Tor Bug Tracker & Wiki]

#32557: TOR crashes when AvoidDiskWrites and/or DisableAllSwap defined in 
`torrc`
--+
 Reporter:  Kein  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor  |Version:  Tor: 0.4.2.3-alpha
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Kein):

 Ignore `DisableAllSwap ` since it is mention that it is not supported on
 Windows.
 No such mention for AvoidDiskWrites: https://2019.www.torproject.org/docs
 /tor-manual.html.en

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 It looks really good! I like the changes that were made. I left a few
 comments on the commits but it's good to go as is.

--
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] #32557 [Core Tor]: TOR crashes when AvoidDiskWrites and/or DisableAllSwap defined in `torrc`

[Tor Bug Tracker & Wiki]

#32557: TOR crashes when AvoidDiskWrites and/or DisableAllSwap defined in 
`torrc`
+--
 Reporter:  Kein|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Low |  Component:  Core Tor
  Version:  Tor: 0.4.2.3-alpha  |   Severity:  Minor
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Windows 7x64, Tor Bundle 9.5a2, tor 0.4.2.3-alpha.

 Specifying

 {{{
 AvoidDiskWrites 1
 DisableAllSwap 1
 }}}

 Crashes tor on start, nothing in log.

--
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 -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


--
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] #32480 [Applications/GetTor]: Use Github/Gitlab releases to distribute gettor binaries

[Tor Bug Tracker & Wiki]

#32480: Use Github/Gitlab releases to distribute gettor binaries
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  github, releases |  Actual Points:  .5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 This is the test repo I used: https://github.com/cohosh/releases/releases

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---

Comment (by phw):

 Reminder to myself: once the changes are reviewed, we need to update our
 [https://community.torproject.org/relay/setup/bridge/docker/ instructions]
 and push a new image version.

--
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] #31157 [Circumvention/Snowflake]: Collect metrics about what type of proxies are running

[Tor Bug Tracker & Wiki]

#31157: Collect metrics about what type of proxies are running
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-october  |  Actual Points:  1
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+-
Changes (by cohosh):

 * actualpoints:   => 1


--
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] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 https://github.com/pion/dtls/blob/master/conn.go#L518
 root

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

 * status:  assigned => needs_review
 * reviewer:   => cohosh


Comment:

 This is finally ready for a review. Cecylia, could you please review the
 commits starting at and including [https://dip.torproject.org/torproject
 /anti-censorship/docker-
 obfs4-bridge/commit/d2335c91ecc04e2236158ed80bd432ee8b07e6bd d2335c91]?

--
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] #31157 [Circumvention/Snowflake]: Collect metrics about what type of proxies are running

[Tor Bug Tracker & Wiki]

#31157: Collect metrics about what type of proxies are running
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-october  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+-
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 https://github.com/cohosh/snowflake/pull/13

--
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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  1
 Reviewer: |Sponsor:  Sponsor30-can
---+---

Old description:

> Here is some feedback we got from an operator (see
> [https://www.securimancy.com/dockerizing-tor-bridge/ this blog post] for
> the full story):
>
> * ~~Make it easier to get the bridge's fingerprint and/or bridge line. At
> the moment, users have to spawn a shell in the container, which is
> tedious.~~
> * Maybe provide a docker-compose file.
> * ~~Improve our
> [https://community.torproject.org/relay/setup/bridge/docker/ official
> setup instructions]. [https://dip.torproject.org/torproject/anti-
> censorship/docker-obfs4-bridge These instructions] were more helpful to
> an operator.~~
> * ~~Add a note that operators can run `docker logs ` to check
> if it's up and running.~~
> * Mention concerns regarding permanence: Ideally, a container should run
> as long as possible.
> * ~~Allow running a bridge on a port <1024 (as per mrphs's request in
> comment:2).~~

New description:

 Here is some feedback we got from an operator (see
 [https://www.securimancy.com/dockerizing-tor-bridge/ this blog post] for
 the full story):

 * ~~Make it easier to get the bridge's fingerprint and/or bridge line. At
 the moment, users have to spawn a shell in the container, which is
 tedious.~~
 * ~~Maybe provide a docker-compose file.~~
 * ~~Improve our
 [https://community.torproject.org/relay/setup/bridge/docker/ official
 setup instructions]. [https://dip.torproject.org/torproject/anti-
 censorship/docker-obfs4-bridge These instructions] were more helpful to an
 operator.~~
 * ~~Add a note that operators can run `docker logs ` to check
 if it's up and running.~~
 * ~~Mention concerns regarding permanence: Ideally, a container should run
 as long as possible.~~
 * ~~Allow running a bridge on a port <1024 (as per mrphs's request in
 comment:2).~~

--

Comment (by phw):

 > Maybe provide a docker-compose file.
 [[br]]
 [https://trac.torproject.org/projects/tor/ticket/31834#comment:5
 thymbahutymba's comment] convinced me that a Makefile is a better solution
 than a docker-compose file. I replaced the script deploy-container.sh with
 a Makefile in commit [https://dip.torproject.org/torproject/anti-
 censorship/docker-
 obfs4-bridge/commit/2dce6dc7a420e08f555faa46a07e4381af194f04 2dce6dc7].
 [[br]]
 > Mention concerns regarding permanence: Ideally, a container should run
 as long as possible.
 [[br]]
 I adopted thymbahutymba's idea of using a volume by adding docker's
 `--volume` argument to the Makefile.

--
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] #32427 [Core Tor/Tor]: Refactor options_act_reversible into manageable chunks

[Tor Bug Tracker & Wiki]

#32427: Refactor options_act_reversible into manageable chunks
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  2.5
Parent ID:  #32408 | Points:
 Reviewer:  teor   |Sponsor:  Sponsor31-can
---+---
Changes (by nickm):

 * status:  needs_revision => needs_review
 * actualpoints:  .3 => 2.5


Comment:

 Putting this in needs_review; what do you think about my suggestion above
 to do the renaming with the refactoring?

--
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] #32427 [Core Tor/Tor]: Refactor options_act_reversible into manageable chunks

[Tor Bug Tracker & Wiki]

#32427: Refactor options_act_reversible into manageable chunks
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  .3
Parent ID:  #32408 | Points:
 Reviewer:  teor   |Sponsor:  Sponsor31-can
---+---

Comment (by nickm):

 After a couple of false starts, I think that the right point at which to
 do the renaming is along with the refactoring.  It's going to be a bit
 tricky, and I think we'll have to do it in stages, beyond the end of
 november, to get it right.

--
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] #32427 [Core Tor/Tor]: Refactor options_act_reversible into manageable chunks

[Tor Bug Tracker & Wiki]

#32427: Refactor options_act_reversible into manageable chunks
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  .3
Parent ID:  #32408 | Points:
 Reviewer:  teor   |Sponsor:  Sponsor31-can
---+---

Comment (by nickm):

 Okay, this is looking better. Tests are passing, chutney is passing, test-
 stem is passing.

 I've added a bunch of comments to explain the ordering in
 options_act_reversible.  I think that the actual correct division of
 responsibility is something like:

   * Pre-configuration
   * Post-configuration, pre-fork.
   * Post-fork, pre-setuid.
   * post-setuid.

 Having the torrc, having daemonized and having setuid are the important
 barriers here.

--
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] #32555 [Core Tor/Tor]: Memory leak on or_options_t?

[Tor Bug Tracker & Wiki]

#32555: Memory leak on or_options_t?
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  043-regression  |  Actual Points:  .1
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:  Sponsor31-must
+
Changes (by nickm):

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


Comment:

 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] #32546 [Core Tor/Tor]: hs-v3: Report invalid onion address SOCKS5 extended error code

[Tor Bug Tracker & Wiki]

#32546: hs-v3: Report invalid onion address SOCKS5 extended error code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #30022| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:7 asn]:
 > Hm. I think this description is not right, since we don't return `F6` if
 the onion address has the wrong length (since that's how we realize it's a
 v3 address). Please describe the exact cases under which we return `F6`
 since it might be used as part of the error page in #30022. Also, let's
 mention that it's v3 exclusive.

 Pushed as fixup. Actually, all ExtendedErrors are v3 only so I added a
 note to each code about it.

 >
 > (Also the PR did not update for some reason)

 Here is the fresh PR: https://github.com/torproject/tor/pull/1555

--
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] #32497 [Applications/Tor Browser]: Think about changing update-channel name for nightly

[Tor Bug Tracker & Wiki]

#32497: Think about changing update-channel name for nightly
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  0.5
  TorBrowserTeam201911R  |
Parent ID:  #18867   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, boklm201911, tbb-update, TorBrowserTeam201911 => tbb-
 rbm, tbb-update, TorBrowserTeam201911R
 * status:  assigned => needs_review
 * actualpoints:   => 0.5


Comment:

 After looking at the uses of `MOZ_UPDATE_CHANNEL`, I didn't notice
 anything that would cause problems if we changed to use `nightly` as the
 channel name.

 In my branch `bug_32497` I added a patch for review which changes the
 nightly channel to `nightly`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32497=111ff13d612e5bfc830f19b3a001136db6baf477

--
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] #32418 [Applications/Tor Browser]: Torbrowser tells on every start, that it can't update although it is newest

[Tor Bug Tracker & Wiki]

#32418: Torbrowser tells on every start, that it can't update although it is 
newest
--+---
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 Replying to [comment:4 mcs]:
 > Tor Browser team: Do we want to provide a way to disable the update
 check, e.g., by re-implementing support for the old `app.update.enabled`
 pref? We would need to ensure that that pref is checked very early; for
 example, the UpdateService JS constructor calls a getter that causes the
 file system permission fix to be attempted on Windows, which would trigger
 the "manual update required" prompt. Mozilla removed the capability for
 users to disable the update check because they do not want users to run
 outdated browsers.

 In the blog comments there were a few people unhappy about not having an
 easy way to disable updates. In some cases it can be useful to have a way
 to disable the updater, so I think having support for the
 `app.update.enabled` pref would be nice.

--
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] #32324 [Applications/Tor Browser]: Introduce Letterboxing to users

[Tor Bug Tracker & Wiki]

#32324: Introduce Letterboxing to users
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sajolida):

 Maybe it would be possible to have some just-in-time help here and make
 this information available right from the letter boxing gray area? Maybe
 making the whole gray area clickable and pointing to some doc or having a
 (?) icon somewhere in it, etc.

--
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] #32546 [Core Tor/Tor]: hs-v3: Report invalid onion address SOCKS5 extended error code

[Tor Bug Tracker & Wiki]

#32546: hs-v3: Report invalid onion address SOCKS5 extended error code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #30022| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 {{{
 +  X'F6' Onion Service Invalid Address
 +
 +The given .onion address is invalid. Either the checksum
 doesn't
 +match or the length or encoding.
 +
 }}}

 Hm. I think this description is not right, since we don't return `F6` if
 the onion address has the wrong length (since that's how we realize it's a
 v3 address). Please describe the exact cases under which we return `F6`
 since it might be used as part of the error page in #30022. Also, let's
 mention that it's v3 exclusive.

 (Also the PR did not update for some reason)

--
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] #32543 [Core Tor/Tor]: spec: Merge prop304 into torspec.git in socks-extensions.txt

[Tor Bug Tracker & Wiki]

#32543: spec: Merge prop304 into torspec.git in socks-extensions.txt
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec  |  Actual Points:  0.1
Parent ID:  #14389| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by asn):

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


Comment:

 Merged! 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] #32532 [Internal Services/Tor Sysadmin Team]: Install ZNC on Chives, make pastly admin it

[Tor Bug Tracker & Wiki]

#32532: Install ZNC on Chives, make pastly admin it
-+-
 Reporter:  pastly   |  Owner:  anarcat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * owner:  pastly => anarcat


Comment:

 As stated on IRC 24+ hours ago, I fixed the bug generating a ton of email
 spam. Sorry about that, again.

 I've documented everything on the `irc` branch of my fork of that wiki.
 https://github.com/pastly/tsa-
 wiki/commit/dac66a37bef2232ddc234d56918895de23b952c6. Everything expect
 how to add users. View it rendered [https://github.com/pastly/tsa-
 wiki/blob/dac66a37bef2232ddc234d56918895de23b952c6/tsa/howto/irc.mdwn
 #setting-up-znc here]. I'm waiting on adding users and documenting how to
 do so until the necessary/desired network changes are made.

 To distill [comment:6 comment 6] into concrete requests:

 - [ ] allow 2001 inbound to ZNC, TLS-protected web and IRC
 - [ ] configure Tor as follows, or as close to it as willing

 {{{
 Log notice syslog
 # to use 3 hops instead of 6. not anonymous
 # can't do this if you want a SocksPort
 SocksPort 0
 HiddenServiceSingleHopMode 1
 HiddenServiceNonAnonymousMode 1
 # actual interesting config
 HiddenServiceDir /var/lib/tor/onion/ircbouncer.torproject.org
 HiddenServiceVersion 3
 HiddenServicePort 80 2000
 HiddenServicePort 2000
 }}}

 - [ ] share with pastly the onion address if different than
 eibwzyiqgk6vgugg.onion

 I'm assigning the ticket back to you because I think that's how you're
 keeping track of what's on your plate vs what is on mine. If this was
 inappropriate, please excuse my ignorance.

--
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] #32527 [Applications/rbm]: rbm downloads 0B sig file if network drops; rejects sig on next run

[Tor Bug Tracker & Wiki]

#32527: rbm downloads 0B sig file if network drops; rejects sig on next run
---+--
 Reporter:  JeremyRand |  Owner:  boklm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201911R  |  Actual Points:  0.2
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

 * status:  new => needs_review
 * keywords:   => TorBrowserTeam201911R
 * actualpoints:   => 0.2


Comment:

 I think this is an issue for signatures files, but also for any files
 downloaded in `input_files`. The issue is that if `wget` fails for some
 reason, the partially downloaded files is left in the destination.

 We can fix that by first downloading the file to a temporary file, and
 only rename it to the destination if the download was successful. This is
 was I did in my branch `bug_32527_v2`:
 
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_32527_v2=dad4ab355d754d650d5d6ad2cccd9931b931c0ff

--
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] #32020 [Core Tor/Tor]: hsv3: Client do not report failing circuit back into HS subsystem

[Tor Bug Tracker & Wiki]

#32020: hsv3: Client do not report failing circuit back into HS subsystem
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-client  |  Actual Points:  1
Parent ID:  #30200  | Points:  1
 Reviewer:  asn |Sponsor:  Sponsor27-must
+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 As discussed with asn on IRC, new PR/branch since much have changed from
 asn's review.

 Branch: `ticket32020_043_02`
 PR: https://github.com/torproject/tor/pull/1554

--
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] #10603 [Applications/Tor Launcher]: Make tor log available if tor exited unexpectedly

[Tor Bug Tracker & Wiki]

#10603: Make tor log available if tor exited unexpectedly
-+---
 Reporter:  gk   |  Owner:  brade
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, extdev-interview  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by brade):

 * cc: mcs (removed)
 * cc: tbb-team, traumschule (added)


Comment:

 #27426 is a duplicate.

--
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] #27426 [Applications/Tor Launcher]: "Tor unexpectedly exited." is not clear enough

[Tor Bug Tracker & Wiki]

#27426: "Tor unexpectedly exited." is not clear enough
---+---
 Reporter:  traumschule|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by brade):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #10603.

--
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] #31506 [Applications/Tor Browser]: Write up comprehensive advice to "Tor unexpectedly exited", and link to it from inside Tor Browser

[Tor Bug Tracker & Wiki]

#31506: Write up comprehensive advice to "Tor unexpectedly exited", and link to 
it
from inside Tor Browser
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by brade):

 Having a complete tor log available to the user would be very helpful
 (#10603).

 Here is a sketch to determine "what the user or app may have recently
 done":
 * Did the user manually edit torrc and introduce a syntax error? (#12501)
 * Is anti-virus software installed on the computer? (#19957, #22456, and
 probably others)
 * Is a leftover tor process running in the background?
 * Is the computer's date/time reasonably correct? (clock skew)
 * Did the user switch to/from "Offline" mode? (#9541)  [I'm not sure that
 #9541 accurately describes the behavior of 9.0/9.5 builds.]
 * Did the computer just wake up from hibernation? (#24619)

--
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] #32555 [Core Tor/Tor]: Memory leak on or_options_t?

[Tor Bug Tracker & Wiki]

#32555: Memory leak on or_options_t?
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  043-regression  |  Actual Points:  .1
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:  Sponsor31-must
+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me and seems to solve the issue.

--
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] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 cypherpunks,
 {{{
 Windows Registry Editor Version 5.00

 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters]
 "DefaultReceiveWindow"=dword:0020
 "DefaultSendWindow"=dword:0020
 }}}
 Can you check this registry tweak? (for test purpose only, not sure about
 DefaultSendWindow and values)

 https://docs.microsoft.com/en-us/previous-versions//bb726981(v=technet.10)
 >Default: 4096/8192/8192

 Linux
 >net.core.rmem_max > 128K

--
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] #32418 [Applications/Tor Browser]: Torbrowser tells on every start, that it can't update although it is newest

[Tor Bug Tracker & Wiki]

#32418: Torbrowser tells on every start, that it can't update although it is 
newest
--+---
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Kathy and I did some investigation and learned that (on Windows only)
 Mozilla tries to fix file system permissions whenever it detects that it
 cannot write to the update info directory or to the directory that
 contains the application. Unfortunately, there are quite a few places
 where this kind of fix up is attempted (if you are curious, look for calls
 to `fixUpdateDirectoryPermissions()` within
 `toolkit/mozapps/update/UpdateService.jsm` and trace the call chains).

 If the permission fix up fails, a "manual update required" prompt is shown
 (which is what the reporter of this bug is seeing).

 The entire update service relies upon being able to write to the update
 info directory, so it will be difficult to support a "read only" update
 info directory. In other words, Firefox's updater was not designed with
 this scenario in mind.

 A better approach, assuming we think it is a good idea to support it,
 would be to disable the update checks. Unfortunately, the only way to
 disable update check in recent versions of Firefox is via the enterprise
 policies mechanism, and that mechanism is disabled in Tor Browser (see
 #30575).

 Tor Browser team: Do we want to provide a way to disable the update check,
 e.g., by re-implementing support for the old `app.update.enabled` pref? We
 would need to ensure that that pref is checked very early; for example,
 the UpdateService JS constructor calls a getter that causes the file
 system permission fix to be attempted on Windows, which would trigger the
 "manual update required" prompt. Mozilla removed the capability for users
 to disable the update check because they do not want users to run outdated
 browsers.

 An alternative would be to disable the code that tries to fix file system
 permissions on Windows, but we would then need to verify that doing so
 does not lead to another code path that causes the browser to display an
 update error prompt.

 Another alternative would be to decide that installing in a read-only area
 of the file system and updating the browser manually is not something we
 can support.

--
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] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  2.5 => 5.5


--
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] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_information => needs_revision


Comment:

 Thanks for the fixes atagar! They seem to work just fine, so I resolved
 all previous comments on the GH PR and added three new ones. Good news!
 I'm testing a stem created descriptor with little-t-tor and parsing seems
 to work just fine! :)

 >> One of the goals of my old _get_middle_descriptor_layer_body() function
 here was to make the output of stem indistinguishable from the output of
 Tor.
 > Sorry, I'm not quite understanding this. The _descriptor_content()
 arguments are simply default values for mandatory fields - if a caller
 would care to provide their own desc-auth-ephemeral-key (rather than use a
 default value) they simply need to provide it...

 Hm. I understand that _descriptor_content() arguments are default values,
 but what defines a good default value here? In particular, the `desc-auth-
 ephemeral-key` and `auth-client` fields of the outerlayer are usually fake
 data in little-t-tor which are easy to generate (see my old
 `_get_middle_descriptor_layer_body()`). It's true that a caller can
 provide their own fake data, but why not make the default value more
 sensible (so that it matches with the one from little-t-tor)? The benefit
 here will be that stem descriptors will be closer to identical with
 little-t-tor's, so that a client cannot tell if a descriptor was made by
 stem or little-t-tor (without the individual applications having to
 explicitly do this themselves).

 In any case and regardless of the above, we do need to provide a single
 fake `auth-client` line otherwise the descriptor won't get parsed by Tor
 (it's a `T1N()` element in `hs_descriptor.c`). I left a comment in the PR
 about this.

 

 Back to you now! Over the next few days I will be testing this deeper
 through onionbalance (and as key blinding becomes usable again)!

--
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] #32480 [Applications/GetTor]: Use Github/Gitlab releases to distribute gettor binaries

[Tor Bug Tracker & Wiki]

#32480: Use Github/Gitlab releases to distribute gettor binaries
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  github, releases |  Actual Points:  .5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Here's a commit that updates the github links:
 
https://dip.torproject.org/cohosh/gettor/commit/8fc567b5680fbf497a1a4e63e0e579a3c1105d6e

--
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] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  2.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "21952+1.webm" 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] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  2.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Some update, see `21952+1.webm` attachment. This is based on branch
 https://github.com/acatarineu/tor-browser/commits/21952+1. Will do some
 alpha builds and add them later.

 Now automatic `Onion-Location` redirects are working, and should behave
 similarly as 30X + Location ones (history not modified, etc.). These are
 controlled via a pref in `about:preferences`, which by default is set as
 `Ask everytime`. I reused the same `.onion available` badge to show some
 visual feedback when redirect has happened (`.onion redirected`), and a
 popup that shows the original URL where the redirect started. I did not
 style this popup, as I assume it's just a temporal thing and the final
 redirect visual feedback (if there is) will probably be different.

 Some technical points that will have to address in a subsequent iteration.
 First, I'm using `originalURI` of the `nsIHttpChannel` to detect whether
 there was a redirect. This has two problems: first, if there is a redirect
 chain like `http -> https -> .onion` the originalURI will be the first
 one, and we probably want to display just the previous one to the
 `.onion`. The second problem is that we cannot distinguish redirects with
 `30X` code + `Location` header from redirects done because of `Onion-
 Location`. So if a website did a regular redirect to `.onion`, we would be
 showing the same visual feedback as with `Onion-Location`. I'm not sure if
 the latter is that big of a problem (depends on what we want to do in this
 case), but the first problem will probably need to be solved.

 I also need to check if there is a simpler (or safer) implementation than
 the one I did for the redirects. I modified `nsHttpChannel.cpp` to do a
 redirect to `Onion-Location` if the pref is `true` (for automatic
 redirects) or the channel has a flag set (for manual/temp redirects). I
 wonder if it would be better/possible to move the redirect logic to `JS`
 service, listening for `http-on-examine-response` and using the
 `channel.redirectTo` JS API if needed. I think if possible it would be
 better to avoid doing too many changes in internal http C++ 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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 I have disbled ("locked") the following users:

  * aagbsn
  * andz
  * darkk

 i've moved the ooni home directory on staticiforme and mirrors, and
 scheduled it for deletion in 7 days, just as a safety measure.

--
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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 alright, i'll retire the other three accounts, 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] #32480 [Applications/GetTor]: Use Github/Gitlab releases to distribute gettor binaries

[Tor Bug Tracker & Wiki]

#32480: Use Github/Gitlab releases to distribute gettor binaries
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  github, releases |  Actual Points:  .5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 I just found this [https://dip.torproject.org/torproject/anti-censorship
 /gettor-project/gettor/blob/master/upload/bundles2github.py
 bundles2github.py] script while looking at what we need to do to update
 the links...

 so it looks like we already had a script to upload tor browser as
 releases. However, it also looks old (last edited in 2016) and like it
 does not match the current functionality of gettor. For example, the link
 creation seems outdated:
 {{{core.create_links_file('GitHub', readable_fp)}}}

--
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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hellais):

 @anarcat the only ones you should keep of the above list are:
 * art
 * agrabeli

--
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] #29650 [Metrics/Exit Scanner]: Rewrite exit scanner to produce exit lists according to new format

[Tor Bug Tracker & Wiki]

#29650: Rewrite exit scanner to produce exit lists according to new format
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2 exitscanner  |  Actual Points:
Parent ID:  #29399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 The existing LDAP groups are 'check' and 'tordnsel'. cf #32553

 The new deployment can reuse these groups.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--

Comment (by karsten):

 Replying to [comment:11 irl]:
 > Replying to [comment:10 karsten]:
 > > Replying to [comment:9 irl]:
 > > > Replying to [comment:8 karsten]:
 > > > > Actually, I think it's harmful to download exit lists from
 CollecTor and merging them with the scanner's own measurements. We should
 instead merge new scan results with previous local results. It's also yet
 another dependency to download something from CollecTor that is not really
 needed. I'd say kill this code.
 > > >
 > > > Ok, it's gone.
 > >
 > > But it's still merging with the last-written local exit list?
 >
 > Yes, it keeps a few on disk like OnionPerf does, but only reads the last
 one.

 Great!

 > > I don't think we're using it (I'd have to check), nor do I know about
 others using it. But I'd be careful removing it or filling it with
 approximately correct data.
 > >
 > > Can we somehow access the consensus used for scanning and fill in
 these fields as part of the merge script? Maybe we can extend exitmap to
 dump that consensus to disk at the time of making a list of relays to
 scan?
 >
 > We can make that change, but I'd say it is not a priority until we're
 further along. We still have to fix up check and the DNS server and if all
 the time is spent on the scanner we still end up with a broken service.

 Agreed. Please put this on the list somewhere, so that we don't forget.

 > > One question though: If scanning takes 45 minutes right now, can we
 schedule scans in a way that they will still work when scanning takes 75
 minutes (larger network) or 15 minutes (fewer/faster exits)? For example,
 we should avoid concurrent runs, and if we do scans continuously, we
 should avoid too frequent scans.
 >
 > {{{
 > while True:
 > start = now()
 > run_scanner()
 > while now() < start + minutes(40):
 > pass
 > }}}

 Cool!

--
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] #32543 [Core Tor/Tor]: spec: Merge prop304 into torspec.git in socks-extensions.txt

[Tor Bug Tracker & Wiki]

#32543: spec: Merge prop304 into torspec.git in socks-extensions.txt
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:  0.1
Parent ID:  #14389| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by dgoulet):

 * status:  assigned => needs_review
 * actualpoints:   => 0.1


Comment:

 Weirdly simple.

 `socks-extensions.txt` is not the most "verbose" of our spec file ;).

 Branch: `ticket32543_01`

--
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] #32546 [Core Tor/Tor]: hs-v3: Report invalid onion address SOCKS5 extended error code

[Tor Bug Tracker & Wiki]

#32546: hs-v3: Report invalid onion address SOCKS5 extended error code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #30022| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+

Comment (by dgoulet):

 New fixup commit pushed for the manpage. Then an extra commit for the
 #30382 changes file (which includes this change).

 Finally, spec branch to not forget:

 Spec: `ticket32546_01`

--
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] #32546 [Core Tor/Tor]: hs-v3: Report invalid onion address SOCKS5 extended error code

[Tor Bug Tracker & Wiki]

#32546: hs-v3: Report invalid onion address SOCKS5 extended error code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #30022| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


--
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] #28800 [Applications/Tor Browser]: Implement New Identity functionality for Tor Browser on Android

[Tor Bug Tracker & Wiki]

#28800: Implement New Identity functionality for Tor Browser on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-newnym, ux-team, |  Actual Points:
  TBA-a3, tbb-8.5, tbb-parity,   |
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-
Changes (by boklm):

 * keywords:
 tbb-mobile, tbb-newnym, ux-team, TBA-a3, tbb-8.5, tbb-parity,
 TorBrowserTeam201904
 =>
 tbb-mobile, tbb-newnym, ux-team, TBA-a3, tbb-8.5, tbb-parity,
 TorBrowserTeam201911
 * cc: sisbell (added)


Comment:

 #32535 is a duplicate.

--
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] #32535 [Applications/Tor Browser]: Android: Cleanup Cache

[Tor Bug Tracker & Wiki]

#32535: Android: Cleanup Cache
--+---
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-mobile, TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 I think this is a duplicate of #28800.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--

Comment (by irl):

 Replying to [comment:10 karsten]:
 > Replying to [comment:9 irl]:
 > > Replying to [comment:8 karsten]:
 > > > Actually, I think it's harmful to download exit lists from CollecTor
 and merging them with the scanner's own measurements. We should instead
 merge new scan results with previous local results. It's also yet another
 dependency to download something from CollecTor that is not really needed.
 I'd say kill this code.
 > >
 > > Ok, it's gone.
 >
 > But it's still merging with the last-written local exit list?

 Yes, it keeps a few on disk like OnionPerf does, but only reads the last
 one.

 > I don't think we're using it (I'd have to check), nor do I know about
 others using it. But I'd be careful removing it or filling it with
 approximately correct data.
 >
 > Can we somehow access the consensus used for scanning and fill in these
 fields as part of the merge script? Maybe we can extend exitmap to dump
 that consensus to disk at the time of making a list of relays to scan?

 We can make that change, but I'd say it is not a priority until we're
 further along. We still have to fix up check and the DNS server and if all
 the time is spent on the scanner we still end up with a broken service.

 > One question though: If scanning takes 45 minutes right now, can we
 schedule scans in a way that they will still work when scanning takes 75
 minutes (larger network) or 15 minutes (fewer/faster exits)? For example,
 we should avoid concurrent runs, and if we do scans continuously, we
 should avoid too frequent scans.

 {{{
 while True:
 start = now()
 run_scanner()
 while now() < start + minutes(40):
 pass
 }}}

--
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] #32556 [Applications/Tor Browser]: Keep track of Mozilla's entitlements files

[Tor Bug Tracker & Wiki]

#32556: Keep track of Mozilla's entitlements files
+--
 Reporter:  gk  |  Owner:  gk
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201911, tbb-sign  |  Actual Points:
Parent ID:  #32173  | Points:  0.2
 Reviewer:  |Sponsor:
+--
Description changed by gk:

Old description:

> Right now we use the entitlements file Mozilla shipped with ESR 68 when
> we transitioned to it. However, we are about to harden that one/those
> (see: #32505 and #32506) and Mozilla is pushing changes to it [on the ESR
> 68 branch, https://hg.mozilla.org/releases/mozilla-
> esr68/rev/f43123e865f1deba61c80036b483dc6dccf64ee0 too]. It's even
> conceivable that security fixes get deployed that way.

New description:

 Right now we use the entitlements file Mozilla shipped with ESR 68 when we
 transitioned to it. However, we are about to harden that one/those (see:
 #32505 and #32506) and Mozilla is pushing changes to it
 [https://hg.mozilla.org/releases/mozilla-
 esr68/rev/f43123e865f1deba61c80036b483dc6dccf64ee0 on the ESR 68 branch,
 too]. It's even conceivable that security fixes get deployed that way.

--

--
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] #32556 [Applications/Tor Browser]: Keep track of Mozilla's entitlements files

[Tor Bug Tracker & Wiki]

#32556: Keep track of Mozilla's entitlements files
+--
 Reporter:  gk  |  Owner:  gk
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201911, tbb-sign  |  Actual Points:
Parent ID:  #32173  | Points:  0.2
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  new => assigned
 * cc: boklm, sysrqb (added)
 * owner:  tbb-team => gk


Comment:

 What I think we should do is having our entitlements files somewhere under
 version control and making sure we are using an up-to-date one when
 signing/notarizing bundles. This can be done as part of the rebase: the
 one who is rebasing is updating our entitelment files if needed. Later on,
 the one who is signing is making sure they are using the latest version in
 our repo.

--
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] #32427 [Core Tor/Tor]: Refactor options_act_reversible into manageable chunks

[Tor Bug Tracker & Wiki]

#32427: Refactor options_act_reversible into manageable chunks
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  .3
Parent ID:  #32408 | Points:
 Reviewer:  teor   |Sponsor:  Sponsor31-can
---+---

Comment (by nickm):

 I fixed the bug; make test-stem worked okay, but I hit a preexisting
 problem when I tried chutney. (#32555).

 Assuming CI passes, I'm going to squash this branch down and continue.

--
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] #32555 [Core Tor/Tor]: Memory leak on or_options_t?

[Tor Bug Tracker & Wiki]

#32555: Memory leak on or_options_t?
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  043-regression  |  Actual Points:  .1
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:  Sponsor31-must
+
Changes (by nickm):

 * status:  assigned => needs_review
 * actualpoints:   => .1


Comment:

 Branch is `bug32555`, PR is https://github.com/torproject/tor/pull/1553 .

--
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] #32556 [Applications/Tor Browser]: Keep track of Mozilla's entitlements files

[Tor Bug Tracker & Wiki]

#32556: Keep track of Mozilla's entitlements files
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201911,
 Severity:  Normal   |  tbb-sign
Actual Points:   |  Parent ID:  #32173
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 Right now we use the entitlements file Mozilla shipped with ESR 68 when we
 transitioned to it. However, we are about to harden that one/those (see:
 #32505 and #32506) and Mozilla is pushing changes to it [on the ESR 68
 branch, https://hg.mozilla.org/releases/mozilla-
 esr68/rev/f43123e865f1deba61c80036b483dc6dccf64ee0 too]. It's even
 conceivable that security fixes get deployed that way.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--

Comment (by karsten):

 Replying to [comment:9 irl]:
 > Replying to [comment:8 karsten]:
 > > Actually, I think it's harmful to download exit lists from CollecTor
 and merging them with the scanner's own measurements. We should instead
 merge new scan results with previous local results. It's also yet another
 dependency to download something from CollecTor that is not really needed.
 I'd say kill this code.
 >
 > Ok, it's gone.

 But it's still merging with the last-written local exit list?

 > > Well, the spec says what these fields are being used for: `Published`
 is used to skip relays that haven't published a new descriptor since the
 one in the current consensus, and `LastStatus` is used to know when to
 throw out relays from the list. This is all under the assumption that the
 scanner reads its previous exit list from disk before making measurements.
 > >
 > > My suggestion would be to use the consensus valid-after time as
 `LastStatus` time. It's pretty much the same as the `published` time in a
 version 2 status, and it would work for this purpose.
 >
 > I saw what TorDNSEL is using it for, but I wonder if people use exit
 lists in ways we haven't anticipated. I guess we can synthesize the valid
 after time from the measurement time, but our plugin is not directly
 handling consensuses or server descriptors. It would take changes to
 exitmap internals to get this data out.

 I don't think we're using it (I'd have to check), nor do I know about
 others using it. But I'd be careful removing it or filling it with
 approximately correct data.

 Can we somehow access the consensus used for scanning and fill in these
 fields as part of the merge script? Maybe we can extend exitmap to dump
 that consensus to disk at the time of making a list of relays to scan?

 > > > No. It scans the entire network every time. It does this
 asynchronously, and doesn't try to prioritize anything. Just whichever
 circuits are built first will be tested first. I was even thinking it
 could run continuously. If exit relays cannot cope with two HTTP requests
 an hour, perhaps they shouldn't be exit relays.
 > >
 > > Ideally, we would change as few variables at the same time as
 possible, in order to compare the new results with the old ones. Changing
 the scheduling from "only scan relays with changed descriptors" to "scan
 all relays once per hour" seems like a major design change that we could
 make at a later time.
 >
 > This could add a lot of time to the project. The exitmap architecture
 doesn't really have a way to do this, so it would take changes to the
 internals there. I guess we can perform the measurements and then throw
 them away as a shortcut option, but once we've done the measurement anyway
 that seems wasteful.

 I see. Then let's keep this in mind when comparing results. (This is
 mostly a note to myself. ;))

 One question though: If scanning takes 45 minutes right now, can we
 schedule scans in a way that they will still work when scanning takes 75
 minutes (larger network) or 15 minutes (fewer/faster exits)? For example,
 we should avoid concurrent runs, and if we do scans continuously, we
 should avoid too frequent scans.

--
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] #32553 [Internal Services/Tor Sysadmin Team]: Group details for exit scanner

[Tor Bug Tracker & Wiki]

#32553: Group details for exit scanner
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #29399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i've also documented this procedure here
 https://help.torproject.org/tsa/howto/ldap/#index1h2

--
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] #29650 [Metrics/Exit Scanner]: Rewrite exit scanner to produce exit lists according to new format

[Tor Bug Tracker & Wiki]

#29650: Rewrite exit scanner to produce exit lists according to new format
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2 exitscanner  |  Actual Points:
Parent ID:  #29399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * parent:   => #29399


Comment:

 mark as part of the chiwui retirement 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] #32553 [Internal Services/Tor Sysadmin Team]: Group details for exit scanner

[Tor Bug Tracker & Wiki]

#32553: Group details for exit scanner
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #29399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  accepted => closed
 * resolution:   => fixed
 * parent:   => #29399


Comment:

 there are two groups with access to chiwui: `check` and `tordnsel`. active
 accounts part of the latter are `arma` and `arno`.

 you can see those memberships by running the `getent group tordnsel` on
 the relevant machine. the membership will vary according to the machie on
 which the command is run, as not all users are present everywhere.

--
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] #32553 [Internal Services/Tor Sysadmin Team]: Group details for exit scanner

[Tor Bug Tracker & Wiki]

#32553: Group details for exit scanner
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => anarcat
 * status:  new => accepted


Comment:

 checking.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--

Comment (by irl):

 Replying to [comment:8 karsten]:
 > Actually, I think it's harmful to download exit lists from CollecTor and
 merging them with the scanner's own measurements. We should instead merge
 new scan results with previous local results. It's also yet another
 dependency to download something from CollecTor that is not really needed.
 I'd say kill this code.

 Ok, it's gone.

 > Well, the spec says what these fields are being used for: `Published` is
 used to skip relays that haven't published a new descriptor since the one
 in the current consensus, and `LastStatus` is used to know when to throw
 out relays from the list. This is all under the assumption that the
 scanner reads its previous exit list from disk before making measurements.
 >
 > My suggestion would be to use the consensus valid-after time as
 `LastStatus` time. It's pretty much the same as the `published` time in a
 version 2 status, and it would work for this purpose.

 I saw what TorDNSEL is using it for, but I wonder if people use exit lists
 in ways we haven't anticipated. I guess we can synthesize the valid after
 time from the measurement time, but our plugin is not directly handling
 consensuses or server descriptors. It would take changes to exitmap
 internals to get this data out.

 > > No. It scans the entire network every time. It does this
 asynchronously, and doesn't try to prioritize anything. Just whichever
 circuits are built first will be tested first. I was even thinking it
 could run continuously. If exit relays cannot cope with two HTTP requests
 an hour, perhaps they shouldn't be exit relays.
 >
 > Ideally, we would change as few variables at the same time as possible,
 in order to compare the new results with the old ones. Changing the
 scheduling from "only scan relays with changed descriptors" to "scan all
 relays once per hour" seems like a major design change that we could make
 at a later time.

 This could add a lot of time to the project. The exitmap architecture
 doesn't really have a way to do this, so it would take changes to the
 internals there. I guess we can perform the measurements and then throw
 them away as a shortcut option, but once we've done the measurement anyway
 that seems wasteful.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--

Comment (by karsten):

 Replying to [comment:6 irl]:
 > Replying to [comment:5 karsten]:
 > > Glad to see that the rewrite is progressing so quickly!
 > >
 > > Couple remarks/questions:
 > >  - Why 48 hours and not 24 hours? Doesn't the current exit scanner
 keep scan results for 24 hours? I might be wrong, though. Let's use
 whatever the current scanner does.
 >
 > https://2019.www.torproject.org/tordnsel/exitlist-spec.txt
 >
 > It discards relays that were not seen in the last 48 hours in a
 consensus.

 Okay, let's use 48 hours then.

 > >  - Rather than downloading exit lists from CollecTor, wouldn't it be
 sufficient to just read the latest exit list previously written by this
 scanner? And if there's none, just assume that no previous scans have
 happened. In theory, this should be all we need to learn.
 >
 > Probably, but this was a handy way to get test data and I wanted to try
 out the new Stem functionality. It would be nice to have a method to
 bootstrap a new scanner but this could just mean manually downloading the
 latest exit list and putting it in the right place.

 Actually, I think it's harmful to download exit lists from CollecTor and
 merging them with the scanner's own measurements. We should instead merge
 new scan results with previous local results. It's also yet another
 dependency to download something from CollecTor that is not really needed.
 I'd say kill this code.

 > >  - It seems that `LastStatus` is only taken from exit lists downloaded
 from CollecTor but never set by new measurements. We should make a plan
 what to do with this field. Take it out? Populate it with consensus valid-
 after times?
 >
 > Right, this is the tricky bit. Do you know if anything consumes the
 LastStatus or Published timestamps? Ideally we could just drop these but
 for now I'm synthesizing them from the timestamp of the last measurement
 which could be close enough for the consumers.

 Well, the spec says what these fields are being used for: `Published` is
 used to skip relays that haven't published a new descriptor since the one
 in the current consensus, and `LastStatus` is used to know when to throw
 out relays from the list. This is all under the assumption that the
 scanner reads its previous exit list from disk before making measurements.

 My suggestion would be to use the consensus valid-after time as
 `LastStatus` time. It's pretty much the same as the `published` time in a
 version 2 status, and it would work for this purpose.

 > >  - Does exitmap with the plugin use previous scans as input to decide
 which relays to scan? I believe that it uses some logic to avoid scanning
 relays too frequently. This has two effects: it doesn't generate more load
 on the network and on single relays than necessary, and it ensures that
 new relays are scanned sooner. As a result, the new scanner could be run
 once or twice per hour, rather than every 2 or 3 hours (at 45 minutes
 runtime).
 >
 > No. It scans the entire network every time. It does this asynchronously,
 and doesn't try to prioritize anything. Just whichever circuits are built
 first will be tested first. I was even thinking it could run continuously.
 If exit relays cannot cope with two HTTP requests an hour, perhaps they
 shouldn't be exit relays.

 Ideally, we would change as few variables at the same time as possible, in
 order to compare the new results with the old ones. Changing the
 scheduling from "only scan relays with changed descriptors" to "scan all
 relays once per hour" seems like a major design change that we could make
 at a later time.

--
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] #32555 [Core Tor/Tor]: Memory leak on or_options_t?

[Tor Bug Tracker & Wiki]

#32555: Memory leak on or_options_t?
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  043-regression
Actual Points:  |  Parent ID:
   Points:  .2  |   Reviewer:
  Sponsor:  Sponsor31-must  |
+
 When I build with --enable-fragile-hardening and CC=clang, and run test-
 network, I get a pile of memory leaks, related to the options object.
 Time to investigate.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+

Comment (by irl):

 Replying to [comment:5 karsten]:
 > Glad to see that the rewrite is progressing so quickly!
 >
 > Couple remarks/questions:
 >  - Why 48 hours and not 24 hours? Doesn't the current exit scanner keep
 scan results for 24 hours? I might be wrong, though. Let's use whatever
 the current scanner does.

 https://2019.www.torproject.org/tordnsel/exitlist-spec.txt

 It discards relays that were not seen in the last 48 hours in a consensus.

 >  - Rather than downloading exit lists from CollecTor, wouldn't it be
 sufficient to just read the latest exit list previously written by this
 scanner? And if there's none, just assume that no previous scans have
 happened. In theory, this should be all we need to learn.

 Probably, but this was a handy way to get test data and I wanted to try
 out the new Stem functionality. It would be nice to have a method to
 bootstrap a new scanner but this could just mean manually downloading the
 latest exit list and putting it in the right place.

 >  - It seems that `LastStatus` is only taken from exit lists downloaded
 from CollecTor but never set by new measurements. We should make a plan
 what to do with this field. Take it out? Populate it with consensus valid-
 after times?

 Right, this is the tricky bit. Do you know if anything consumes the
 LastStatus or Published timestamps? Ideally we could just drop these but
 for now I'm synthesizing them from the timestamp of the last measurement
 which could be close enough for the consumers.

 >  - Does exitmap with the plugin use previous scans as input to decide
 which relays to scan? I believe that it uses some logic to avoid scanning
 relays too frequently. This has two effects: it doesn't generate more load
 on the network and on single relays than necessary, and it ensures that
 new relays are scanned sooner. As a result, the new scanner could be run
 once or twice per hour, rather than every 2 or 3 hours (at 45 minutes
 runtime).

 No. It scans the entire network every time. It does this asynchronously,
 and doesn't try to prioritize anything. Just whichever circuits are built
 first will be tested first. I was even thinking it could run continuously.
 If exit relays cannot cope with two HTTP requests an hour, perhaps they
 shouldn't be exit relays.

--
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] #32265 [Metrics/Exit Scanner]: MS: Format an exit list from a previous exit list and exitmap output

[Tor Bug Tracker & Wiki]

#32265: MS: Format an exit list from a previous exit list and exitmap output
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:  karsten   |Sponsor:
--+--
Changes (by irl):

 * status:  needs_revision => needs_review


--
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] #31206 [Applications/Tor Browser]: http://ip-check.info detects browser window size with JS disabled

[Tor Bug Tracker & Wiki]

#31206: http://ip-check.info detects browser window size with JS disabled
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Thorin):

 * status:  reopened => closed
 * resolution:   => not a bug


Comment:

 Replying to [comment:21 cypherpunks]:
 > But it detects a change of size (css inner window) also when you press
 CTRL+F or F12

 That's how it works. If the inner window changes size (e.g. due to
 findbar, docked dev tools, full-screen, sidebar, etc), then of course the
 change can be detected. The change **from** one size **to** another is
 **not** entropy. These changes happen with and without letterboxing.
 Letterboxing controls the size you **END** up at.

--
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