Re: [tor-bugs] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-rarely, tor-test, hang,  |  Actual Points:
  tor-ci, 043-should |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I still haven't received any response from Travis support.

 Please continue linking failed jobs in this ticket, so I can use those
 links ina  follow-up email.
 (They like fresh failures in each email.)

--
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] #33032 [Core Tor/Tor]: Decode key files with Unix or Windows newlines

[Tor Bug Tracker & Wiki]

#33032: Decode key files with Unix or Windows newlines
-+-
 Reporter:  larshilse|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:  .2
  044-should, 035-backport, 041-backport,|
  042-backport, 043-backport |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Yep, 0.4.3 and master are the right places for bug fixes. Then I'll
 backport later.

 (I asked because you moved this ticket to 0.4.1 after merging.)

--
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] #33375 [Core Tor/Tor]: Stop advertising an IPv6 exit policy when DNS is broken for IPv6

[Tor Bug Tracker & Wiki]

#33375: Stop advertising an IPv6 exit policy when DNS is broken for IPv6
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, security-review- |  Actual Points:
  dos-risk, extra-review, no-backport, ipv6, |
  tor-exit, tor-dns  |
Parent ID:  #24833   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 (It's not anyone's fault. Sometimes code changes are more complicated than
 we expect.)

--
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] #33375 [Core Tor/Tor]: Stop advertising an IPv6 exit policy when DNS is broken for IPv6

[Tor Bug Tracker & Wiki]

#33375: Stop advertising an IPv6 exit policy when DNS is broken for IPv6
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, security-review- |  Actual Points:
  dos-risk, extra-review, no-backport, ipv6, |
  tor-exit, tor-dns  |
Parent ID:  #24833   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_information
 * keywords:
 security-review-dos-risk, extra-review, no-backport, ipv6, tor-exit,
 tor-dns
 =>
 needs-proposal, security-review-dos-risk, extra-review, no-backport,
 ipv6, tor-exit, tor-dns


Comment:

 So there's a bunch of missing data here, a lot of design questions, and a
 lot of risks.

 I think we need a proposal here, so that other developers can review the
 design.
 The proposal should cover the questions I've asked in this ticket.
 And talk about how we can test these changes.

 And then we can update the code, and merge it.

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

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF73)

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF73)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  12
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+

Comment (by Thorin):

 Replying to [comment:6 pospeselr]:
 > {{{
 > 74:
 > TextMetrics interface updated, canvas fingerprinting?
 > - https://bugzilla.mozilla.org/show_bug.cgi?id=1102584
 > }}}

 https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#fonts -
 see the textmetric entry and click the view details

 RFP doesn't protect against this. The prefs (all added in 74+) are
 - `dom.textMetrics.actualBoundingBox.enabled` FF74+ default true
 - `dom.textMetrics.baselines.enabled` - 76 Nightly still at default false
 - `dom.textMetrics.emHeight.enabled` - 76 Nightly still at default false
 - `dom.textMetrics.fontBoundingBox.enabled` - 76 Nightly still at default
 false

 measureText uses floats (which may be affected by OS), so the precision is
 much higher than say domrect (which uses app-units - e.g. 1/60th of a CSS
 pixel). Additionally, text layout goes from device pixels (which _are_
 affected by DPI) to CSS pixels: so it could also be affected by DPI (but
 no one knows for sure)

 I'm not sure if it really adds any more entropy than other font
 measurements like dcf's unicode glyphs - but it is another avenue

--
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] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [comment:3 dcf]:
 > I was running a Turbo Tunnel Snowflake browser at the time, and after
 rebooting the server the browser was not responding
 > This makes sense, as a server restart isn't something Turbo Tunnel can
 recover from--the end-to-end session is broken and snowflake-client has to
 wait until tor makes another SOCKS request. I used the trick of switching
 to obfs4 for one second and then switching back to snowflake, and it
 started working again right away.

 I was running a Turbo Tunnel Snowflake browser too, and it gave me a bunch
 of page failures, and for a while the broker was giving me snowflakes that
 timed out when I tried to use them, and sometimes it give me a 504 error
 rather than giving me a snowflake. After a while (including periodically
 reloading the failed tabs) it all recovered.

--
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] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 It's done. The snowflake bridge is now running tor 0.3.5.10 and Debian
 10.3.

 I mainly followed the instructions at
 https://www.debian.org/releases/buster/amd64/release-notes/ch-
 upgrading.en.html. Our old /etc/apt/sources.list was
 {{{
 deb http://ftp.nl.debian.org/debian stretch main
 deb http://security.debian.org/ stretch/updates main
 }}}
 I changed it to
 {{{
 deb http://ftp.nl.debian.org/debian buster main
 deb http://ftp.nl.debian.org/debian-security buster/updates main
 deb http://ftp.nl.debian.org/debian buster-updates main
 }}}
 I wasn't sure about the `buster/updates` and `buster-updates` lines
 because they were not mentioned in the upgrade guide. I found them used in
 the example sources.list at
 https://wiki.debian.org/SourcesList#Example_sources.list.

 I had to preserve local changes in /etc/ferm/ferm.conf and /etc/tor/torrc,
 while merging in the updates.

 After the installation there were these obsolete packages:
 {{{
 # aptitude search '~o'
 Warning: Invalid locale (please review locale settings, this might lead to
 problems later):
   locale::facet::_S_create_c_locale name not valid
 i   deb.torproject.org-keyring -
 GnuPG archive key of the deb.torproject.org repository
 i   gcc-4.8-base   -
 GCC, the GNU Compiler Collection (base package)
 i   gcc-4.9-base   -
 GCC, the GNU Compiler Collection (base package)
 i A gcc-6-base -
 GCC, the GNU Compiler Collection (base package)
 i   libapt-inst1.5 -
 deb package format runtime library
 i   libapt-pkg4.12 -
 package management runtime library
 i   libboost-iostreams1.55.0   -
 Boost.Iostreams Library
 i   libcryptsetup4 -
 disk encryption support - shared library
 i   libdns-export100   -
 Exported DNS Shared Library
 i   libgdbm3   -
 GNU dbm database routines (runtime version)
 i   libgnutls-deb0-28  -
 GNU TLS library - main runtime library
 i   libhogweed2-
 low level cryptographic library (public-key cryptos)
 i   libicu52   -
 International Components for Unicode
 i   libirs-export91-
 Exported IRS Shared Library
 i   libisc-export95-
 Exported ISC Shared Library
 i   libisccfg-export90 -
 Exported ISC CFG Shared Library
 i   libjson-c2 -
 JSON manipulation library - shared library
 i   liblogging-stdlog0 -
 easy to use and lightweight logging library
 i   liblognorm1-
 Log normalizing library
 i   libnettle4 -
 low level cryptographic library (symmetric and one-way cryptos)
 i   libprocps3 -
 library for accessing process information from /proc
 i   libpsl0-
 Library for Public Suffix List (shared libraries)
 i   libreadline6   -
 GNU readline and history libraries, run-time libraries
 i   libssl1.0.0-
 Secure Sockets Layer toolkit - shared libraries
 i   libxtables10   -
 netfilter xtables library
 i   linux-image-3.16.0-4-amd64 -
 Linux 3.16 for 64-bit PCs
 i A perl-modules-5.24  -
 Core Perl modules
 }}}
 I removed them with `aptitude 

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF73)

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF73)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  12
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Changes (by pospeselr):

 * actualpoints:   => 12


Comment:

 {{{
 Release notes:

 69:
 Enhanced Tracking Protection
 - I believe we want to turn this off
 Web Authentication HmacSecret extension via Windows Hello (for Windows
 10 versions > May 2019)
 - suspect this feature violates our disk avoidance requirements
 32-bit Firefox on 64-bit OS users no-longer differentiable from 64-bit
 Firefox on 64-bit OS
 - navgator.userAgent, navigator.platform, navigator.oscpu props
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1559747
 userChrome.css and userContent.css no longer enabled by default
 - sure users will probably complain about this but seems like a
 good thing
 - toolkit.legacyUserProfileCustomizations.stylesheets -> true to
 re-enable

 69.0.1:
 69.0.2:
 69.0.3:
 Seems like Firefox hooks into Windows Parental Controls (though
 they are removed in newer versions of Windows 10?)
 - I would think our build should stup out parental controls
 and logging if we don't do this already
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1584613
 - also has implementation for android and macos
 70:
 Firefox Lockwise (about:logins)
 - violates disk avoidance
 'Gift' icon in toolbar that spams users with feature updates/news
 70.0.1:
 71:
Picture-in-Picture video
 - this feature is pretty awesome, but we should make sure it
 doesn't expose fingerprinting surface
 - can be toggled off with media.videocontrols.picture-in-
 picture.enabled
 72:
 72.0.1:
 72.0.2:
 73:
 Enhancement to Windows' High Contrast Mode, web renderer now adds
 'readability backplate' of solid color between background and text
 - possible finger-printing vector?
 73.0.1:
 74:


 Developer release notes

 69:
 Lithuanian specific case rules (also exists for greek, dutch, others),
 locale fingerprinting
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1322992
 add-on api topsites.get() certainly seems sketchy af:
 https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/topSites/get
 - updated to add includePinned and includeSearchShortcuts options
 70:

 71:

 72:

 73:

 74:
 TextMetrics interface updated, canvas fingerprinting?
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1102584
 75:

 Noteworthy Tickets:

 69:
 1584613 - Parental control detection doesn't work on Windows 10
 - make sure parental access checks are always disabled
 1559747 - User-Agent string needn't reveal a user is running 32-bit
 Firefox on a 64-bit OS
 - make sure this is also true for Tor Browser if it isn't already
 1561307 - Add pref to enable/disable the What's New Panel feature
 - make sure this panel is disabled
 70:
 1570732 - Disable DoH if parental controls detected
 - followup on 1584613 to ensure we don't have parental controls in
 Tor Browser
 1561273 - network ID: ipv4NetworkId/scanArp returns gateway IP instead
 of its MAC
 - certainly seems like we shouldn't have runnable code that can
 read the user's IP or MAC
 1563319 - Enable the What's New UI when pref is enabled
 - make sure this is disabled
 1572389 - Add pref to show normal lock icon for sites with EV
 (Extended Validation) certificates
 - so looks like we can bring back full EV names if we so wish
 1576246 - Set pref browser.urlbar.eventTelemetry.enabled by default
 - make sure this is disabled
 1567826 - Don't mark localhost as insecure
 - this should be fine but the patch does touch the url icon logic
 1572936 - Move EV cert UI out of URL Bar
 - security.identityblock.show_extended_validation pref for showing
 EV in url bar, we may want to enable this for onionsites?
 71:
 1539212 - implement readability backplate for high contrast mode
 - probably fingerprinting vector for folks with high contrast mode
 enabled as it adds a new rendering layer
 1585920 - network ID: fix VPN detection on Linux for non ethernet
 devices
 - seems like we would never want to calculate a fingerprintable
 'Network ID' in tor-browser, though I'm not sure what 

Re: [tor-bugs] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-rarely, tor-test, hang,  |  Actual Points:
  tor-ci, 043-should |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Restarted about 3 errored macOS jobs. They all succeeded.

--
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] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Good plan -- oldstable is going to be obsolete pretty soon. So you could
 use the deb.tpo packages as a stopgap, but the right answer is to move the
 OS to stable. 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] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

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


Old description:

> [https://lists.torproject.org/pipermail/tor-
> announce/2020-March/000196.html New stable Tor releases: 0.3.5.10,
> 0.4.1.9, and 0.4.2.7]
> > These releases fix a couple of denial-of-service vulnerabilities.
> Everybody running an older version should upgrade as packages become
> available.
>
> Upgrading tor may require an
> [https://www.debian.org/releases/buster/amd64/release-notes/ch-
> upgrading.en.html OS upgrade] from Debian stretch (oldstable) to buster
> (stable), and/or a switch to the [https://support.torproject.org/apt/tor-
> deb-repo/ torproject.org package repository]. Currently the bridge is on
> stretch. whose available version is
> [https://packages.debian.org/stretch/tor 0.2.9.16-1].

New description:

 [https://lists.torproject.org/pipermail/tor-
 announce/2020-March/000196.html New stable Tor releases: 0.3.5.10,
 0.4.1.9, and 0.4.2.7]
 > These releases fix a couple of denial-of-service vulnerabilities.
 Everybody running an older version should upgrade as packages become
 available.

 Upgrading tor may require an [https://www.debian.org/releases/buster/amd64
 /release-notes/ch-upgrading.en.html OS upgrade] from Debian stretch
 (oldstable) to buster (stable), and/or a switch to the
 [https://support.torproject.org/apt/tor-deb-repo/ torproject.org package
 repository]. Currently the bridge is on stretch, whose available version
 is [https://packages.debian.org/stretch/tor 0.2.9.16-1].

--

Comment:

 I'm going to look at doing the OS upgrade.

--
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] #12802 [Circumvention/BridgeDB]: BridgeDB needs Nagios checks for the Email Distributor

[Tor Bug Tracker & Wiki]

#12802: BridgeDB needs Nagios checks for the Email Distributor
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-email, nagios, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #30152   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

 * status:  new => needs_information


Comment:

 I refactored hiro's "check for emails" script
 
[https://github.com/NullHypothesis/bridgedb/commit/81ce4d13419d1d651fc0a904cec86e77fa346c94
 in this commit]. The script writes its output to
 `/srv/bridges.torproject.org/check/status`. I can set up a cron job that
 runs this script every, say, six hours. We will probably encounter some
 more hiccups once the script is running in production. Hiro, can you
 remind me what will happen if nagios considers BridgeDB's email responder
 down? Will I be able to see this in the nagios web UI? I'm asking because
 there will probably be a few more hiccups with the "check email" script
 once it's running continuously.

--
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] #7193 [Core Tor/Tor]: Tor's sybil protection doesn't consider IPv6

[Tor Bug Tracker & Wiki]

#7193: Tor's sybil protection doesn't consider IPv6
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, intro, tor-dirauth, security,  |  Actual Points:
  sybil, network-health, outreachy-ipv6  |
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-can
-+-

Comment (by maurice_pibouin):

 Thanks a lot for your comments, I will try to fix everything !

--
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] #33647 [Circumvention/BridgeDB]: Minor updates to BridgeDB's dependencies

[Tor Bug Tracker & Wiki]

#33647: Minor updates to BridgeDB's dependencies
+---
 Reporter:  agix|  Owner:  (none)
 Type:  enhancement | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:  sbws: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by phw):

 * status:  new => needs_information


Comment:

 > The link to the get-pip script is outdated and no longer available.
 > The new address would be: ​https://bootstrap.pypa.io/get-pip.py
 [[br]]
 Nice catch. Can you please create a patch for this?
 [[br]]
 > When setup.py is executed the following error occurs:
 > error: The 'pyasn1' distribution was not found and is required by
 service-identity.
 > Therefore i suggest adding pyasn1 to requirements.txt.
 [[br]]
 How did you run setup.py? I am unable to reproduce this.
 [[br]]
 > Since BridgeDB's port seems as good as done, this might not be necessary
 but the pylint version 2.4.4 in .test.requirements.txt is only supporting
 Python 3.
 > For the installation with Python 2.7, pylint version 1.9.5 would be
 required.
 [[br]]
 Also a good catch! It appears that pylint is only used in the Makefile,
 specifically in the `pylint` target. I suggest we update to the latest
 version, and make sure that `make pylint` still works.

--
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] #33701 [UX]: Bug while saving a page.

[Tor Bug Tracker & Wiki]

#33701: Bug while saving a page.
+--
 Reporter:  pbuggy  |  Owner:  antonela
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  UX
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I was trying to save a webpage with Tor and the result is unreadable. It's
 like unicode symbols or something like that. I've attached a video of me
 reproducing the error.

 Video : https://linx.li/vwaicay6.mp4

--
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] #30477 [Core Tor/Tor]: Tor should self-test reachability of TCP listeners exposed by PT's

[Tor Bug Tracker & Wiki]

#30477: Tor should self-test reachability of TCP listeners exposed by PT's
-+-
 Reporter:  ahf  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, s30-o23a3, network-team- |  Actual Points:
  roadmap-2020Q1 |
Parent ID:  #31280   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by gaba):

 * cc: catalyst (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] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [comment:3 cohosh]:
 > Out of curiosity, are there any cases in which a non-PT address would be
 in `AF_USPEC` here? Could we just fix this by removing that condition?

 To be clear, I think the 0.0.3.0 bridge is triggering that middle
 condition: the tor_addr_is_internal() one. That's because 0.0.3.0 is an
 internal ipv4 address.

--
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] #31103 [Core Tor/Tor]: Support ORPort picking a random port that persists across restarts

[Tor Bug Tracker & Wiki]

#31103: Support ORPort picking a random port that persists across restarts
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #30471   | Points:  1
 Reviewer:   |Sponsor:  Sponsor28-must
-+
Changes (by gaba):

 * cc: catalyst (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] #29128 [Core Tor/Tor]: Place complete obfs4 bridge line in accessible location

[Tor Bug Tracker & Wiki]

#29128: Place complete obfs4 bridge line in accessible location
-+-
 Reporter:  phoul|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-doc, |  Actual Points:
  040-deferred-20190220, network-team-roadmap-   |
  2020Q1 |
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gaba):

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


--
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] #29111 [Circumvention/Pluggable transport]: Optional heartbeat message from PT's

[Tor Bug Tracker & Wiki]

#29111: Optional heartbeat message from PT's
---+---
 Reporter:  ahf|  Owner:  catalyst
 Type:  enhancement| Status:  assigned
 Priority:  Low|  Milestone:  Tor:
   |  unspecified
Component:  Circumvention/Pluggable transport  |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-2020Q1|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
   |  Sponsor28-must
---+---
Changes (by gaba):

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


--
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] #33291 [Core Tor/Tor]: Making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
-+-
 Reporter:  gaba |  Owner:  dgoulet
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-size network-team-roadmap-   |  Actual Points:
  2020Q1 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

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


--
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] #32824 [Internal Services/Tor Sysadmin Team]: Upgrade tpo onions to v3.

[Tor Bug Tracker & Wiki]

#32824: Upgrade tpo onions to v3.
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-

Comment (by anarcat):

 https://code.immerda.ch/immerda/puppet-modules/tor/

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 > allow people to call in

 you mean phone?

 >  Are you all thinking on one server to host any video-conferencing
 software? How much $ would that cost?

 depends on the service we pick. biggest cost center is staff, so it
 depends on how hard it would be to setup. would evaluate once we know what
 we do. :)

--
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] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gaba):

 Must have:
 * allow people to call in
 * video/audio communication for a group of people of approx 2-10 people
 * mobile app
 * chat
 * a way for one person to mute themselves


 My experience with nextcloud talk is that does not even work well for 2
 people. Signal is much better for 2 people talking.

 Are you all thinking on one server to host any video-conferencing
 software? How much $ would that cost?

--
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] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-rarely, tor-test, hang,  |  Actual Points:
  tor-ci, 043-should |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 There has been a series of macOS failures in the Travis infrastructure.
 The latest is https://www.traviscistatus.com/incidents/h898fkzlp6xf which
 is supposedly resolved now. Restarted a few errored macOS builds in an
 attempt to verify this.

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  Is this something our nextcloud could support? Or we would have to host
 it and setup a way for it to talk to our nc?

 i don't know. NC Talk doesn't work so well, IMHO, with lots of 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] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Replying to [comment:1 anarcat]:

 > = Nextcloud
 >
 > systemli is using this ansible role to install coturn:
 https://github.com/systemli/ansible-role-coturn
 >

 Is this something our nextcloud could support? Or we would have to host it
 and setup a way for it to talk to our nc?

--
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] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 **Must have:**
 - video/audio communication for a group of people of approx 2-10 people
 - chat fallback
 - have a mobile app

 **Nice to have:**
 - Reliable video support. Video chat is nice, but most video chat systems
 usually require all participants to have video off otherwise the
 communication is sensibly lagged.
 - allow people to call in

--
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] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 my inventory of possible solutions is detailed in this blog post:

 https://anarc.at/blog/2020-03-15-remote-tools/

 the TL;DR: is basically:

  * BBB (Big Blue Button)
  * Jitsi
  * Mumble
  * Nextcloud talk, for small meetings

 some technical considerations regarding install methods:

 = mumble

 there are two different puppet modules to setup mumble:

  * https://github.com/voxpupuli/puppet-mumble
  * https://0xacab.org/riseup-puppet-recipes/mumble

 still need to be evaluated, but i'd be tempted to use the voxpupuli module
 because they tend to be better tested and it's more recent

 = jitsi

 ansible roles: https://code.immerda.ch/o/ansible-jitsi-meet/
 https://github.com/UdelaRInterior/ansible-role-jitsi-meet

 there's also a docker container and (messy) debian packages

 prometheus exporter: https://github.com/systemli/prometheus-jitsi-meet-
 exporter

 = Nextcloud

 systemli is using this ansible role to install coturn:
 https://github.com/systemli/ansible-role-coturn

 = BBB

 no known install procedure, might be messy.

--
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] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services   |Version:
  Admin Team |
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 With the rise of the coronavirus, even Tor, which generally works
 remotely, is affected because we were still having physical meetings from
 time to time, and we'll have to find other ways to deal with this.

 This ticket aims at establishing the problem space ("what we're trying to
 solve") and evaluate possible solutions ("what could fix it"). we could
 follow the sysadmin documentation template:

 https://help.torproject.org/tsa/howto/template/#Discussion

 which establishes the following criterion:

  * Goals
* Must have
* Nice to have
* Non-goals
  * Approvals required
  * Proposed solution
  * Cost
  * Alternatives considered

--
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] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-rarely, tor-test, hang,  |  Actual Points:
  tor-ci, 043-should |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * keywords:  tor-ci-rarely-fail, tor-test, hang, tor-ci, 043-should => tor-
 ci-fail-rarely, tor-test, hang, tor-ci, 043-should


Comment:

 swap keyword so this ticket will show up in `tor-ci-fail` searches

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

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

[Tor Bug Tracker & Wiki]

#5304: Obfsproxy should respect OutboundBindAddress in torrc
-+-
 Reporter:  korobkov |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec-change needs-tor-change,  |  Actual Points:  1.25
  network-team-roadmap-2020Q1, 043-should|
Parent ID:  #30471   | Points:  1
 Reviewer:  phw  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by catalyst):

 * status:  needs_revision => assigned
 * owner:  ahf => catalyst


--
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] #31009 [Core Tor/Tor]: Tor lets transports advertise private IP addresses in descriptor

[Tor Bug Tracker & Wiki]

#31009: Tor lets transports advertise private IP addresses in descriptor
-+-
 Reporter:  phw  |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-bridge, 035-backport,|  Actual Points:
  040-backport, 041-backport,|
  042-deferred-20190918, network-team-roadmap-   |
  2020Q1, 043-should |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by catalyst):

 * owner:  ahf => catalyst
 * status:  needs_revision => assigned


--
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] #33691 [Core Tor/sbws]: Migrate to gitlab.tpo

[Tor Bug Tracker & Wiki]

#33691: Migrate to gitlab.tpo
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by gaba):

 For reviews of sbws in gitlab.torproject.org:
 https://gitlab.torproject.org/torproject/network-health/sbws

 Juga: I gave you mantainer access.

--
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] #33032 [Core Tor/Tor]: Decode key files with Unix or Windows newlines

[Tor Bug Tracker & Wiki]

#33032: Decode key files with Unix or Windows newlines
-+-
 Reporter:  larshilse|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:  .2
  044-should, 035-backport, 041-backport,|
  042-backport, 043-backport |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:21 teor]:
 > Hey asn, just checking: did you merge to 0.4.2 ?

 Hey Tim. I did not. Should I?

--
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] #33131 [Core Tor/Tor]: Bug: buf->datalen >= 0x7fffffff

[Tor Bug Tracker & Wiki]

#33131: Bug: buf->datalen >= 0x7fff
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by nickm):

 I've made a test merge branch at
 https://github.com/torproject/tor/pull/1834 so that I can let the CI run
 at this.  There were some conflicts I had to resolve.

 I'm thinking that the `BUF_MAX_LEN` changes are pervasive enough that we
 wouldn't want to backport those, if we do a backport here.

 Any chance of getting a unit test for the new code 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] #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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:120 acat]:
 > And builds of 21952+6 branch for UX review:
 https://people.torproject.org/~acat/builds/21952+6/.

 Thank you!

 - Both /meta and /header demos work for me.
 - The general setting works well and without reload (we may need user
 feedback on this flow, but is a current firefox issue, I'll open a
 different ticket for it).
 - Can we remove the left margin at the doorhanger?

 @steph @pili @mcs @brade @pospeselr: We are using this text at the prompt.
 Any thought? Let me know if we are ok to reach l10n.

 {{{
 Try this: Onionsite

 Website publishers can protect users by adding a security layer. This
 prevents eavesdroppers from knowing that you are the one visiting that
 website.
 }}}

--
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] #7193 [Core Tor/Tor]: Tor's sybil protection doesn't consider IPv6

[Tor Bug Tracker & Wiki]

#7193: Tor's sybil protection doesn't consider IPv6
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, intro, tor-dirauth, security,  |  Actual Points:
  sybil, network-health, outreachy-ipv6  |
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Some notes on the content of the patch:
   * This like is incorrect `node_t *node_running =
 tor_malloc(sizeof(node_t *));`.  That "sizeof" is taking the size of a
 pointer, not the size of a node_t.  Because of that, you'll only allocate
 a few bytes, not a whole node_t.
   * It looks like the `mock_node_get*` functions have a memory leak -- you
 malloc node_running, but there is nothing that frees it.  Please remember
 that in C, every allocated object needs to have a corresponding free.  If
 you run configure with `--enable-fragile-hardening` it will turn on extra
 run-time checking that will catch this kind of problem for you.
   * When using strlcpy or strlcat, it's good style to use the size of the
 target buffer.
   * For the address comparison, could we use tor_addr_compare() ?
   * I don't understand why we're looking at the family type for the ipv6
 address -- if it's an IPv6 address, then the family should always be
 AF_INET6.  (And if the family is AF_INET, then it shouldn't be stored in a
 variable called ipv6_addr).
   * Most fundamentally: this function seems to be for sorting relays into
 a list by address and then by bandwidth.  But now it is trying to sort by
 ipv6 address _and_ by ipv4 address at the same time.  I don't think that
 makes sense -- a relay can have both kinds of address, but it wouldn't
 appear at more than one point in the list necessarily.

 It probably makes sense for there to be two different variants of the
 function -- one that sorts by ipv6 and one that sorts by ipv4.  The parts
 of the two functions that would be shared in common should turn into a
 third function that they both would call.

--
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] #33699 [Community/Relays]: Create an exitmap module for DNS exit checks

[Tor Bug Tracker & Wiki]

#33699: Create an exitmap module for DNS exit checks
---+--
 Reporter:  gk |  Owner:  gk
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202003  |  Actual Points:
Parent ID:  #33695 | Points:  1
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Another issue this ticket would easily solve is not excluding badexits in
 the list of potential exits to check. We'd essentially get that for free
 with a dns check module for `exitmap`.

--
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] #33699 [Community/Relays]: Create an exitmap module for DNS exit checks

[Tor Bug Tracker & Wiki]

#33699: Create an exitmap module for DNS exit checks
---+---
 Reporter:  gk |  Owner:  gk
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component: |Version:
  Community/Relays |
 Severity:  Normal |   Keywords:  network-health, GeorgKoppen202003
Actual Points: |  Parent ID:  #33695
   Points:  1  |   Reviewer:
  Sponsor: |
---+---
 I think `exitmap` has a lot of infrastructure which could get used for DNS
 exit checks. And we already run `exitmap` with different modules for a
 bunch of our bad relay checks. So, I propose to create dns check module
 and we could use the already existing `dnssec.py` one for running another,
 related, check to get an overview of all the DNS related problems our
 exits have.

 We should try to keep the output format similar to Arthur's to make it
 easier to parse both results series.

--
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] #33698 [Applications/Tor Browser]: Update "About Tor Browser" links in Tor Browser

[Tor Bug Tracker & Wiki]

#33698: Update "About Tor Browser" links in Tor Browser
--+--
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In Tor Browser, in Help > About Tor Browser, we should update some links:

 1. Donate to https://donate.torproject.org
 2. Get involved to https://community.torproject.org
 3. Questions to https://support.torproject.org
 4. Help the Tor Network Grow! to https://community.torproject.org/relay

--
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] #33697 [Applications/Tor Browser]: Investigate new Search Engine configuration

[Tor Bug Tracker & Wiki]

#33697: Investigate new Search Engine configuration
--+
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202003  |  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Changes (by acat):

 * sponsor:   => Sponsor58-must


--
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] #33697 [Applications/Tor Browser]: Investigate new Search Engine configuration

[Tor Bug Tracker & Wiki]

#33697: Investigate new Search Engine configuration
--+
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam202003
Actual Points:|  Parent ID:  #33533
   Points:|   Reviewer:
  Sponsor:|
--+
 While working on #33533 I noticed that the engines configured in
 `list.json` were being ignored, and had to set the
 `browser.search.modernConfig = false` for them to work.

 I believe this is because of a new Search Engine configuration that has
 been enabled by default in nightly recently, this is the meta ticket is
 https://bugzilla.mozilla.org/show_bug.cgi?id=1542235.

 We should investigate this and see whether it's enough to flip that pref
 to get the behaviour we want.

--
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] #32981 [Internal Services/Tor Sysadmin Team]: New RT queue 'training'

[Tor Bug Tracker & Wiki]

#32981: New RT queue 'training'
-+-
 Reporter:  ggus |  Owner:  pili
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #32893   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-
Changes (by pili):

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


Comment:

 I believe this is now done

--
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] #25102 [Applications/Tor Browser]: Add script to sign nightly build mar files, generate update-responses xml and publish the new version

[Tor Bug Tracker & Wiki]

#25102: Add script to sign nightly build mar files, generate update-responses 
xml
and publish the new version
-+-
 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:  4.5
  TorBrowserTeam202003R  |
Parent ID:  #18867   | Points:  3.5
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam202003 => tbb-rbm, tbb-
 update, TorBrowserTeam202003R
 * status:  assigned => needs_review


Comment:

 The branch `bug_25102_v10` has two commits for review:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25102_v10=709592712db8fc1050c88143b7ca3eea09b8e77f

 The first one adds the script `tools/signing/nightly/sign-nightly` which
 is downloading, signing and uploading mar files and xml responses to
 https://nightlies.tbb.torproject.org/nightly-updates/.

 The second commits contains ansible scripts to deploy it.

 This is what is currently being used, and it seems to be working
 correctly.

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

Re: [tor-bugs] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 Great find, arma. Here is some background on this and related issues.

 * [[#18517|#18517 meek is broken in Tor Browser 6.0a3]]\\
   Commit
 
[https://gitweb.torproject.org/tor.git/commit/?id=23b088907fd23da417f5caf2b7b5f664f317ef4a
 23b08890] in tor temporarily broke meek's 0.0.2.0 address in the course of
 trying to fix unrelated bugs. It added a test for `tor_addr_is_internal`
 to `circuit_handle_first_hop`. There's discussion there of what address to
 use that tor won't consider internal--it's not guaranteed that tor will
 ever permanently reserve a safe set of addresses for us--but the best
 candidate seems to be [https://tools.ietf.org/html/rfc5737 192.0.2.0/24],
 a range reserved for documentation. In the end, tor's code was changed to
 allow bridges on internal addresses, which resolved the problem even
 though meek doesn't ''actually'' connect to a bridge on an internal
 address.
 * [[#18611|#18611 Improve semantics for pluggable transports with dummy
 addresses]]\\
   Was an attempt to formalize the situation around dummy addresses, and
 provide guidance as to what transport authors should do if they don't use
 the address field in the bridge line. phw suggested an `implicit` token in
 the bridge line that would tell tor not to consider that the bridge line
 address is actually being connected to.
 * [[#19487|#19487 Meek and ReachableAddresses]]\\
   A related address-handling bug: if you configure `ReachableAddresses`
 such that a dummy address is considered not reachable, tor will not even
 try connecting to the transport. (Not knowing that the transport has no
 intention of trying to connect to that address.) teor has a patch there to
 ignore `ReachableAddresses` for bridges with transports, but it fell off
 the review pipeline.
 * [[#25528|#25528 When ClientTransportPlugin is missing, tor connects
 directly to bridge addresses, even if they have a transport name]]\\
   Shows the danger of putting a routable address in a bridge line, even if
 ignored by the transport. If there are errors elsewhere in torrc, tor may
 make a direct TCP connection to whatever address is there, instead of
 passing it to a pluggable transport proxy. This is what I was trying to
 prevent by using an obviously invalid address like 0.0.3.0: in the event
 of error, tor still tries to connect directly to the address, but it fails
 at the OS level with an "Invalid argument" error and no traffic leaves the
 machine.

 And some history on how we arrived at the 0.0.''X''.0:1 pattern for dummy
 addresses. With flash proxy back in 2011, there was originally was no such
 thing as `ClientTransportPlugin` or transport-aware bridge lines, so you
 had to fake it with `Socks4Proxy` and a SOCKS-speaking local transport
 program. It happened that the address of the local SOCKS proxy was
 127.0.0.1:9001, and I put that address in both `Socks4Proxy` and `Bridge`
 lines:
 
https://gitweb.torproject.org/flashproxy.git/tree/README?id=d40953b0b2164548d06964f2e98087e2dd528f31#n53
 {{{
 UseBridges 1
 Bridge 127.0.0.1:9001
 Socks4Proxy 127.0.0.1:9001
 }}}
 Later I decided it was confusing to have the same address in both places
 when one of them is ignored and one is not, so I changed the ignored one
 to 0.0.0.0:1. I didn't document why I chose the port number 1, but I'm
 pretty sure it's because tor internally uses port 0 as a sentinel in some
 places.
 
https://gitweb.torproject.org/flashproxy.git/commit/?id=bf51cf0b761214e39f635d14451582d27a8915ab
 But 0.0.0.0 didn't work well because that is `AF_UNSPEC`, which tor treats
 specially in various places (including in `connection_is_rate_limited` in
 comment:2). I think I first tried 0.0.0.1 after that, but that one is no
 good because 0.0.0.''nonzero'' is a
 [https://en.wikipedia.org/wiki/SOCKS#SOCKS4a SOCKS4a] magic value
 indicating a hostname. So I switched it to 0.0.''X''.0:1.
 
https://gitweb.torproject.org/flashproxy.git/commit/?id=fdcb2d1382b430565afbcd5dcfad829479c0bb7b
 Since then I've been incrementing ''X'' with each new transport that uses
 dummy addresses. This is because if we use the same dummy address for two
 transports that actually connect to different bridges, tor will complain
 about seeing two different fingerprints for the "same" bridge, because
 internally it 

Re: [tor-bugs] #29220 [Core Tor/Tor]: Update review guidelines to list best practices

[Tor Bug Tracker & Wiki]

#29220: Update review guidelines to list best practices
-+-
 Reporter:  nickm|  Owner:  asn
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, 042-deferred, s31-docs, |  Actual Points:
  043-should |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * milestone:  Tor: 0.4.3.x-final => Tor: 0.4.4.x-final


--
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] #33651 [Core Tor/Tor]: Suspicious "fetched this many bytes" counts from #32720

[Tor Bug Tracker & Wiki]

#33651: Suspicious "fetched this many bytes" counts from #32720
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 That appveyor failure is #33643

--
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] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  1
 Reviewer:  teor   |Sponsor:  Sponsor55-can
---+---
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * 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] #33375 [Core Tor/Tor]: Stop advertising an IPv6 exit policy when DNS is broken for IPv6

[Tor Bug Tracker & Wiki]

#33375: Stop advertising an IPv6 exit policy when DNS is broken for IPv6
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  security-review-dos-risk, extra- |  Actual Points:
  review, no-backport, ipv6, tor-exit, tor-dns   |
Parent ID:  #24833   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * 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] #33651 [Core Tor/Tor]: Suspicious "fetched this many bytes" counts from #32720

[Tor Bug Tracker & Wiki]

#33651: Suspicious "fetched this many bytes" counts from #32720
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 For some reasons, one of Appveyor builds failed with:

 
https://ci.appveyor.com/project/torproject/tor/builds/31574905/job/7nyl60kltec1gs4h

 {{{
   FAIL ../src/test/test_crypto.c:237: OpenSSL library version 1.1.1d did
 not begin with header version 1.1.1e.
 }}}

 Seems unrelated so apart from that, lgtm. Feel free to merge.

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

Re: [tor-bugs] #33673 [Core Tor/Tor]: Use the right DLLs and pkg-config path on Appveyor

[Tor Bug Tracker & Wiki]

#33673: Use the right DLLs and pkg-config path on Appveyor
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, appveyor, windows,   |  Actual Points:  0.1
  035-backport, 041-backport, 042-backport,  |
  043-backport, consider-backport-after-ci-  |
  passes |
Parent ID:   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => ahf


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

Re: [tor-bugs] #33688 [Core Tor/Tor]: README cleanups

[Tor Bug Tracker & Wiki]

#33688: README cleanups
--+
 Reporter:  bduszel   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by dgoulet):

 * reviewer:   => catalyst


--
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] #33258 [Metrics]: Add CSV file export of graphed data

[Tor Bug Tracker & Wiki]

#33258: Add CSV file export of graphed data
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  1
 Reviewer:  anarcat  |Sponsor:  Sponsor59
-+--
Changes (by anarcat):

 * reviewer:   => anarcat


Comment:

 this looks great! certainly an improvement over the previous version,
 assuming rendering performance is either similar or not a concern (i
 haven't checked).

 i haven't reviewed the code in details, however.

 i wonder if time plots with dots could be improved... in the current
 design, more frequent occurences will overlap and hide each other and
 outliers will be disproportionately represented. maybe something like a
 catplot would help?

 https://seaborn.pydata.org/generated/seaborn.catplot.html#seaborn.catplot

 maybe a swarm plot?

 https://seaborn.pydata.org/generated/seaborn.swarmplot.html#seaborn.swarmplot
 https://seaborn.pydata.org/generated/seaborn.violinplot.html#seaborn.violinplot

 ... maybe you're already doing in which case i apologize.. :)

--
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] #33695 [Community/Relays]: Setup process for repeatedly check for exits that can't handle DNS queries

[Tor Bug Tracker & Wiki]

#33695: Setup process for repeatedly check for exits that can't handle DNS 
queries
--+--
 Reporter:  gk|  Owner:  ggus
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #29343 is a related ticket. For checks in `tor` see #24014.

--
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] #33696 [Metrics/Consensus Health]: Integrate badexiting into the badconf-entry.py script

[Tor Bug Tracker & Wiki]

#33696: Integrate badexiting into the badconf-entry.py script
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus|Version:
  Health |   Keywords:  network-health,
 Severity:  Normal   |  GeorgKoppen202003
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 We'll probably use the Badexit flag more from now on (see: #32864), so it
 might make sense to add a respective option to our `badconf-entry.py`
 script.

--
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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

[Tor Bug Tracker & Wiki]

#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
-+-
 Reporter:  arma |  Owner:  gk
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Community/Relays |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:  3.5
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by gk):

 * actualpoints:   => 3.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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

[Tor Bug Tracker & Wiki]

#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
-+-
 Reporter:  arma |  Owner:  gk
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Community/Relays |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Okay, some final note here: I created [https://gitlab.torproject.org/gk
 /helper-scripts/-/commit/b40a0e100e8d3e6d1503076ddb6ddfbf05346a59 a
 script] that pulls exit relays failing DNS queries with a certain
 threshold (by default only relays failing 10/10 times are shown) out of
 some JSON blob created either by Arthur's exit dns check tool or by my own
 run. I contacted the respective exit relay ops (that's the "[s]" below
 where "[sf]" means "mails sent but bounced") last week and did not really
 hear back (just one replied looking into it). So, now's the time to
 actually start the badexiting process. I pushed a rule to mark all the
 exits below as badexit:
 {{{
 [s]
 "$296B2178FD742AB35AB20C9ADF04D5DFD3D407EB"
 [s]
 "$3BADB3EFFB87534736BFAC9A2024AB78401BDBC3"
 [no email address]
 "$4684E03631097C77F013637EC800D499CD71C250"
 [s]
 "$51AE5656C81CD417479253A6363A123A007A2233"
 [no email address]
 "$53FF368902D124FA9A806D149AF22C3A6357B150"
 [s]
 "$5AD1D535373C05BB1624BD2A76DDE713E974240E"
 [s]
 "$9AD12F0E3CC871D59ACA14BB4076CDD8CB28DE57"
 [s]
 "$9C339F4F3101B744C8C040C9F51D63B520D38712"
 [sf]
 "$9E9C2223EA179F52BA73A24BFDE2E44DCA468EEF"
 [no email address]
 "$A5B682E846615088362A3B2BD11C353C84778659"
 [s]
 "$AD1639F47D6233E812A67F98F9D76FF55D1D2ECC"
 [no email address]
 "$F912C0A30DC9CBD4E7BA566C235DA194C4623EC0"
 [s]
 "$FAD823A2AA7400D4A8107D7CD83050EEBB7A51FE"
 [no email address]
 "$FBBC3BD58B471F6227DC0F05265C6A37C770905F"
 [s]
 "$FE59C12C9697E742CD3F7ADBAF6385EA1C8B379F"
 }}}
 (FWIW: As said previously I slightly modified arthur's to use
 `https://eff.org` to check for exits as the results compared with Arthur's
 allow us to differentiate between DNSSEC only issues and more general
 ones. That's useful when contacting relay ops in particular until #33179
 is solved).

 Marking this ticket as in `needs_review` for the script I want to add to
 the `helper-scripts` 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] #33695 [Community/Relays]: Setup process for repeatedly check for exits that can't handle DNS queries

[Tor Bug Tracker & Wiki]

#33695: Setup process for repeatedly check for exits that can't handle DNS 
queries
--+--
 Reporter:  gk|  Owner:  ggus
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * type:  defect => task


--
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] #33695 [Community/Relays]: Setup process for repeatedly check for exits that can't handle DNS queries

[Tor Bug Tracker & Wiki]

#33695: Setup process for repeatedly check for exits that can't handle DNS 
queries
--+
 Reporter:  gk|  Owner:  ggus
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal|   Keywords:  network-health
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Over at #32864 we started the process of badexiting relays which don't
 handle DNS queries properly (but rather fail on them). We should set up a
 process to do that repeatedly and ideally automatically. It could be one
 of our bad relay checks

--
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] #32915 [Community/Relays]: Cloudflare alt-svc failures cause spurious "DNS resolution error" in Tor Browser

[Tor Bug Tracker & Wiki]

#32915: Cloudflare alt-svc failures cause spurious "DNS resolution error" in Tor
Browser
--+--
 Reporter:  cypherpunks   |  Owner:  ggus
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:  #32864 =>


Comment:

 Unparenting. Some steps to reproduce would be helpful, so we can move this
 ticket forward.

--
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] #33691 [Core Tor/sbws]: Migrate to gitlab.tpo

[Tor Bug Tracker & Wiki]

#33691: Migrate to gitlab.tpo
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---
Changes (by gaba):

 * cc: gaba (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] #33691 [Core Tor/sbws]: Migrate to gitlab.tpo

[Tor Bug Tracker & Wiki]

#33691: Migrate to gitlab.tpo
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by gaba):

 Hey juga! Wait a little for moving things up to gitlab. We are going to do
 it with ahf using the script he wrote and then disable sbws in trac once
 is done.

 I think it should go under network health group in gitlab.

 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] #33629 [Core Tor/Tor]: Use stale bot to close old pull requests

[Tor Bug Tracker & Wiki]

#33629: Use stale bot to close old pull requests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:3 catalyst]:
 > This seems like a good idea to me.
 >
 > Is Probot relatively well maintained?

 Seems active, the last change was 14 hours ago:
 https://github.com/probot

 > What hosting or infrastructure requirements are there for running it?

 It runs as a GitHub app on github.io:
 https://developer.github.com/apps/

 I think it will be useful, while we are still using GitHub for PRs. GitLab
 probably does it's own thing, and that's 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] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  0.5
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => 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] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  0.5
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by teor):

 I think there's a missing keys lock when relay mode is disabled.
 And there might be merge conflict with #32588.

 Let's also open a ticket for the TODO dirauth change?

--
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] #33032 [Core Tor/Tor]: Decode key files with Unix or Windows newlines

[Tor Bug Tracker & Wiki]

#33032: Decode key files with Unix or Windows newlines
-+-
 Reporter:  larshilse|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:  .2
  044-should, 035-backport, 041-backport,|
  042-backport, 043-backport |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final


Comment:

 Hey asn, just checking: did you merge to 0.4.2 ?

--
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] #33629 [Core Tor/Tor]: Use stale bot to close old pull requests

[Tor Bug Tracker & Wiki]

#33629: Use stale bot to close old pull requests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 This seems like a good idea to me.

 Is Probot relatively well maintained? What hosting or infrastructure
 requirements are there for running it?

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

Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 Replying to [comment:16 MrSquanchee]:
 > I think, I can use this
 [https://github.com/torproject/tor/blob/master/src/test/test_bwmgt.c file]
 to test the added changes.
 > What do you say ??

 Sounds like a great idea!

 > Also I added the changes requested.
 > And I think when BandwidthStatistics is explicitly set to 1, it should
 not check the consensus as cited
 [https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-
 ipv6-stats.txt#n305. here] (indirectly).

 Thanks! We need to answer those questions in the comments and manual page.

 Writing comments and manuals can be hard.
 Can you try one more time?
 Try to use similar options as a template.

 If you're still having trouble, I can help rewrite them. But I might not
 have time this week.

--
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] #33629 [Core Tor/Tor]: Use stale bot to close old pull requests

[Tor Bug Tracker & Wiki]

#33629: Use stale bot to close old pull requests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Yes, we can change the message. For details, see:
 https://probot.github.io/apps/stale/

 Let's say "on trac, in the Core Tor/Tor component"?

 We might also want to use bugs.torproject.org, so the links point to the
 new GitLab, when the migration happens.

--
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] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  0.5
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good! There's a typo that I commented on in the pull request.

 I manually tested building with `--disable-module-relay`, but I didn't
 verify that the removed code was absent from the executable.

--
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] #33032 [Core Tor/Tor]: Decode key files with Unix or Windows newlines

[Tor Bug Tracker & Wiki]

#33032: Decode key files with Unix or Windows newlines
-+-
 Reporter:  larshilse|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:  .2
  044-should, 035-backport, 041-backport,|
  042-backport, 043-backport |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


--
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] #33032 [Core Tor/Tor]: Decode key files with Unix or Windows newlines

[Tor Bug Tracker & Wiki]

#33032: Decode key files with Unix or Windows newlines
-+-
 Reporter:  larshilse|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:  .2
  044-should, 035-backport, 041-backport,|
  042-backport, 043-backport |
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * milestone:  Tor: 0.4.4.x-final => Tor: 0.4.1.x-final


Comment:

 Merged to 043 and forward to master!

 Rolling milestone back for backports!

--
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] #31699 [Core Tor/Tor]: Remove unused configure.ac checks

[Tor Bug Tracker & Wiki]

#31699: Remove unused configure.ac checks
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:  #31698| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bduszel):

 I will focus only on the ones with `HAVE_` prefix for now. Thanks
 cypherpunks.

--
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] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

[Tor Bug Tracker & Wiki]

#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
+--
 Reporter:  cypherpunks |  Owner:  brade
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam202003R  |  Actual Points:  7.1
Parent ID:  #30025  | Points:  6
 Reviewer:  acat,pospeselr  |Sponsor:
|  Sponsor27-must
+--
Changes (by mcs):

 * actualpoints:  6.7 => 7.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] #33672 [Applications/Tor Browser]: Force include https-everywhere in incremental mar update

[Tor Bug Tracker & Wiki]

#33672: Force include https-everywhere in incremental mar update
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202003R |  Actual Points:  0.3
Parent ID:| Points:
 Reviewer:  brade, mcs|Sponsor:
--+--
Changes (by mcs):

 * actualpoints:  .2 => 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] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Thanks again for the review. Revised branches:
 https://github.com/acatarineu/tor-browser/commit/28005+4,
 https://github.com/acatarineu/torbutton/commit/28005+2.

 Replying to [comment:35 mcs]:
 > Is there a version of HTTPS-E available that supports the new
 `get_simple_rules_ending_with` API? When we tested with HTTPS-E 2020.3.16
 we saw some strange behavior, but if that is supposed to work we can try
 again.

 I originally tested by building a non-signed xpi with https-everywhere
 master and installing it manually, but now installing the official
 https://eff.org/files/https-everywhere-2020.3.16-eff.xpi is working fine
 for me (after a browser restart).

 > Related to
 `browser/components/onionservices/HttpsEverywhereControl.jsm`:
 > * Should we open a new ticket for the "lock the channel to prevent user
 changes" issue? Is it a foot gun? I guess the idea is that we do not want
 users to substitute their own URL, etc. with the SecureDrop ruleset. On
 the other hand, I think users can add their own .tor.onion rules.
 What I was thinking is to be able to setup the ruleset in a way that
 behaves like the default EFF (Full) ruleset, so that it cannot be edited
 via UI (perhaps just allow to disable? but that might require more work on
 https-everywhere side). But yes, this does not protect against .tor.onion
 mappings being overriden by other rulesets that a user may add. I think
 it's a good to have change, but not strictly needed for now. I created
 #33694 for this.

 Replying to [comment:36 mcs]:
 > One thing I forgot to mention: the SecureDrop ruleset maps
 `www.nytimes.com.securedrop.tor.onion` to the NYT SecureDrop service. It
 is inconvenient to require the `www.` prefix as well as `.com`.  But I am
 not sure what process was used to create the ruleset and how it will be
 maintained by SecureDrop people going forward.

 I think they wanted to keep exactly the same original domain: there are
 cases without `www.` like `home.coworker.org.securedrop.tor.onion` or
 `theintercept.com.securedrop.tor.onion`. By the way, I did not do a review
 of all rulesets, but just noticed a weird case:
 `img.huffingtonpost.com.securedrop.tor.onion`. Here the argument of
 keeping the original domain would not hold, since `img.huffingtonpost.com`
 webpage does not work, so perhaps it's a bug.

 In any case, regarding `www.` prefix, I think we agree that it's
 preferable not to have it, so perhaps we should contact asking whether it
 would be possible to remove it - even if it does not match the original
 domain.

--
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] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.2
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  18 => 18.2


--
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] #33679 [Core Tor/Tor]: Make sure every address function that takes for_listening supports IPv6

[Tor Bug Tracker & Wiki]

#33679: Make sure every address function that takes for_listening supports IPv6
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop312, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33049 | Points:  0.5
 Reviewer: |Sponsor:
   |  Sponsor55-must
---+---
Changes (by MrSquanchee):

 * status:  needs_review => needs_revision


Comment:

 Thanks for suggestions, updating the PR soon !!!

--
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] #33694 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Allow setting up a locked update channel programatically (was: Allow)

[Tor Bug Tracker & Wiki]

#33694: Allow setting up a locked update channel programatically
-+-
 Reporter:  acat |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28005   | Points:
 Reviewer:   |Sponsor:
-+-

--
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] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---
Changes (by MrSquanchee):

 * status:  needs_revision => needs_review


Comment:

 Finding ways to test :)

--
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] #33694 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Allow

[Tor Bug Tracker & Wiki]

#33694: Allow
-+-
 Reporter:  acat |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28005
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 For #28005, it would be good to be able to (programatically) setup an
 update channel in https-everywhere in a way that is locked like the
 default EFF (Full) update channel.

--
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] #33629 [Core Tor/Tor]: Use stale bot to close old pull requests

[Tor Bug Tracker & Wiki]

#33629: Use stale bot to close old pull requests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I wouldn't mind something like this.  I wonder if we can customize the
 messages that the bot uses, so it says something like "Closing this ticket
 because it is older than XX days. If it should not be closed, then please
 reopen it, and make sure that there is a corresponding ticket on
 bugs.torproject.org".

--
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] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
---+---
 Reporter:  teor   |  Owner:  MrSquanchee
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6  |  Actual Points:
Parent ID:  #33052 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by MrSquanchee):

 I think, I can use this
 [https://github.com/torproject/tor/blob/master/src/test/test_bwmgt.c file]
 to test the added changes.
 What do you say ??

 Also I added the changes requested.
 And I think when BandwidthStatistics is explicitly set to 1, it should not
 check the consensus as cited
 [https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-
 ipv6-stats.txt#n305. here] (indirectly).

--
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] #33667 [Applications/Tor Browser]: TorBrowser installer bungles permissions when umask is set

[Tor Bug Tracker & Wiki]

#33667: TorBrowser installer bungles permissions when umask is set
--+--
 Reporter:  sdavids   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I did not follow the steps to reproduce this problem, but it does look
 like permissions changed between Tor Browser 9.0.4 and 9.0.5.

 After mounting TorBrowser-9.0.4-osx64_en-US:
 {{{
 % ls -l Tor\ Browser/Tor\ Browser.app/Contents/MacOS/
 total 210364
 drwxr-xr-x  3 USER  staff   2048 Jan  9 06:44 Tor/
 -rwxr-xr-x  1 USER  staff  100724160 Jan  9 05:08 XUL*
 -rwxr-xr-x  1 USER  staff  36128 Jan  9 05:08 firefox*
 ...
 }}}

 After mounting TorBrowser-9.0.5-osx64_en-US:
 {{{
 ls -l Tor\ Browser/Tor\ Browser.app/Contents/MacOS/
 total 210380
 drwxr-x---  3 USER  staff   2048 Feb 11 11:18 Tor/
 -rwxr-x---  1 USER  staff  100732448 Feb 10 16:43 XUL*
 -rwxr-x---  1 USER  staff  36128 Feb 10 16:43 firefox*
 ...
 }}}

 I am not sure what caused this change though. The fix for #33200 only
 changed the permissions for `bookmarks.html`.

 boklm or sysrqb, any ideas?

--
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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 Replying to [comment:119 acat]:
 > I updated the Onion-Location proposal from asn to match the current
 implementation:
 >
 > https://github.com/acatarineu/torspec/blob/21952/proposals/ideas/onion-
 location.txt
 >
 >
 
https://github.com/acatarineu/torspec/commit/b39f480eba95dc4a3ed08d7a63067c3f44353b89

 LGTM!

 Perhaps the  thing can go into its own section? Because it is a bit
 hidden like that.

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

Re: [tor-bugs] #33493 [Metrics/Relay Search]: Encourage operators to ignore bridge flags on relay search

[Tor Bug Tracker & Wiki]

#33493: Encourage operators to ignore bridge flags on relay search
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * cc: metrics-team, phw, cohosh (added)
 * type:  defect => enhancement


Comment:

 All those suggestions sound reasonable to me to make it clear to users
 that bridge flags are not being used by '''clients'''.

 But doesn't '''BridgeDB''' use at least the `Stable` flag when assigning a
 bridge to a distributor? Copying phw and cohosh to get a more robust
 answer on that than I could give from looking at possibly outdated specs.

 When we know what exactly bridge flags are being used for we can discuss
 how to make that clear visually.

--
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] #30917 [Core Tor/Tor]: Add instructions for making a new maint branch to EndOfLifeTor.md, and rename the file

[Tor Bug Tracker & Wiki]

#30917: Add instructions for making a new maint branch to EndOfLifeTor.md, and
rename the file
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sponsor31-maybe, 043-should, |  Actual Points:  .1
  postfreeze-ok  |
Parent ID:   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've made the requested edits; sorry for the delay.

--
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] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Out of curiosity, are there any cases in which a non-PT address would be
 in `AF_USPEC` here? Could we just fix this by removing that condition?

--
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] #33650 [Core Tor/Tor]: Verify that intro2 cell extensions actually work

[Tor Bug Tracker & Wiki]

#33650: Verify that intro2 cell extensions actually work
-+-
 Reporter:  arma |  Owner:
 |  mikeperry
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos tor-dos-2020 anonymous-  |  Actual Points:
  credentials research   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:9 arma]:
 > Another piece of this ticket: let's discover how much extra space we
 actually have, in the cells, for these blobs.
 >

 I looked into this.

 tl;dr INTRO1 cells have about 188 bytes of free space...

 For more info, please see section [SPACE_CONSTRAINTS] in
 https://lists.torproject.org/pipermail/tor-dev/2020-March/014198.html .

--
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] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Look at this helpful comment for the `connection_is_rate_limited()`
 function:

 {{{
 /** Return 1 if we should apply rate limiting to conn, and 0
  * otherwise.
  * Right now this just checks if it's an internal IP address or an
  * internal connection. We also should, but don't, check if the connection
  * uses pluggable transports, since we should then limit it even if it
  * comes from an internal IP address. */
 static int
 connection_is_rate_limited(connection_t *conn)
 {
   const or_options_t *options = get_options();
   if (conn->linked)
 return 0; /* Internal connection */
   else if (! options->CountPrivateBandwidth &&
(tor_addr_family(>addr) == AF_UNSPEC || /* no address */
 tor_addr_family(>addr) == AF_UNIX ||   /* no address */
 tor_addr_is_internal(>addr, 0)))
 return 0; /* Internal address */
   else
 return 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] #32994 [Core Tor/Tor]: Get all flag defaults from port_cfg_new()

[Tor Bug Tracker & Wiki]

#32994: Get all flag defaults from port_cfg_new()
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  extra-review, technical-debt, tor-   |  implemented
  client, easy, intro, outreachy-ipv6|  Actual Points:  0.3
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to master.

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

Re: [tor-bugs] #33642 [Core Tor/Tor]: Add *.a to .gitignore

[Tor Bug Tracker & Wiki]

#33642: Add *.a to .gitignore
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  build configure  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I think this would be okay.

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

Re: [tor-bugs] #32588 [Core Tor/Tor]: Setting ORPort [ipv6]:auto mistakenly advertises port 94

[Tor Bug Tracker & Wiki]

#32588: Setting ORPort [ipv6]:auto mistakenly advertises port 94
-+-
 Reporter:  arma |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0435,|  Actual Points:  1.1
  043-should, ipv6, 035-backport, 041-backport,  |
  042-backport, 043-backport |
Parent ID:  #33048   | Points:  1
 Reviewer:  nickm, teor  |Sponsor:
 |  Sponsor55-must
-+-
Changes (by nickm):

 * milestone:  Tor: 0.4.4.x-final => Tor: 0.4.3.x-final


Comment:

 Okay, I'm merging this to master and marking for a 0.4.3 backport.

--
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] #33675 [Core Tor/Chutney]: Search microdescriptor files for relay ed25519 keys

[Tor Bug Tracker & Wiki]

#33675: Search microdescriptor files for relay ed25519 keys
---+---
 Reporter:  teor   |  Owner:  anuradha1904
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Chutney   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, outreachy-ipv6  |  Actual Points:  0.1
Parent ID:  #33428 | Points:  0.5
 Reviewer:  teor   |Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 That looks great!

 But base64 contains "+" characters:
 https://docs.python.org/3.5/library/base64.html#base64.b64encode

 And "+" is a special character in regular expressions:
 https://docs.python.org/3/library/re.html#regular-expression-syntax

 So you'll need to use re.escape() on ed25519-id:
 https://docs.python.org/3/library/re.html#re.escape

 Please write some code, and test it using "make test-network-all".
 Send us a pull request when you're done.

 If you get stuck, send us:
 * a pull request with your draft code
 * the detailed logs from the ".log" files
 And tell us what you've tried already.

--
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] #33663 [Metrics/Consensus Health]: Check checktest.py related errors shown by our network-health scanners

[Tor Bug Tracker & Wiki]

#33663: Check checktest.py related errors shown by our network-health scanners
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:  #33180   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:2 irl]:
 > The issue is not whether the exit is able to resolve it, but whether the
 exit is able to exit to it. Exits need to be able to make exit connections
 to 116.202.120.181:443. This is a fundamental limitation of the current
 exit scanner and would need redesign to do differently.

 Thanks, yes, being able to resolve `check.torproject.org` is just a
 necessary requirement but not sufficient. I should have been clearer,
 sorry for that. So, the node can make an exit connection to
 `check.torproject.org` as it gets JSON back and complaining afterwards
 that it got `"IsTor":false`. Now, there are cases where this can happen,
 e.g. as the exitscanner might have a different consensus containing relays
 the check test script does not have once it is run and vice versa but
 that's usually not causing a permanent failure as in this case.

--
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] #33482 [Applications/Tor Browser]: Update about:tor donate string

[Tor Bug Tracker & Wiki]

#33482: Update about:tor donate string
-+-
 Reporter:  antonela |  Owner:  mcs
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam202003R,  |  Actual Points:  0.1
  l10n   |
Parent ID:   | Points:  0.5
 Reviewer:  acat |Sponsor:
-+-
Changes (by acat):

 * status:  needs_review => merge_ready


--
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] #33663 [Metrics/Consensus Health]: Check checktest.py related errors shown by our network-health scanners

[Tor Bug Tracker & Wiki]

#33663: Check checktest.py related errors shown by our network-health scanners
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:  #33180   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 The issue is not whether the exit is able to resolve it, but whether the
 exit is able to exit to it. Exits need to be able to make exit connections
 to 116.202.120.181:443. This is a fundamental limitation of the current
 exit scanner and would need redesign to do differently.

--
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] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Once we resolve this one to our satisfaction, meek has a similar issue
 with its 0.0.2.0 dummy address.

--
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] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[Tor Bug Tracker & Wiki]

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Snowflake's default bridge pretends to be on 0.0.3.0. It's a dummy address
 since snowflake-client knows how to connect to the right bridge and
 ignores the address that Tor tells it.

 But my Tor client still uses that bridge address to make decisions. For
 example, connection_is_rate_limited() decides "no, it isn't rate limited",
 because tor_addr_is_internal() says 0.0.3.0 is essentially part of
 localhost. And that choice has a cascading effect where when I attach my
 nyx to Tor Browser to graph bandwidth use ({{{nyx -i 9151}}}), the BW
 events all say "0 0" because my Tor hasn't sent or received any non-
 internal bytes.

 The quick fix is to keep using a dummy address, but to pick one that isn't
 an internal address. I confirmed that if I change snowflake's dummy
 address to 11.0.3.0, then connection_is_rate_limited() decides it's
 external, my BW events work again, and nyx gives me graphs. That is, Tor
 is smart enough to know that even though the connection is from the Tor
 client to the localhost snowflake client, the connection is "really" to
 the (non-localhost) destination bridge address.

 I confess that I don't know which "apparently routable but don't worry we
 won't actually connect to it, probably" address is the best choice here.
 :/

 The longer term answer is to have some other way to signal that it's a
 dummy address, or to change the PT interface so we don't need the fake
 address. But I don't think we need to wait for the longer term answer
 here.

 The reason I noticed this issue is because I am pondering lobbying for the
 Tor Browser folks to give me a tiny bandwidth graph (or activity spinner)
 somewhere in the browser, because I got a super slow snowflake, but I was
 still getting 5-10KBytes/s, and my page did load after like 90 seconds,
 but if I hadn't been staring at the
 {{{
 2020/03/23 09:33:05 Traffic Bytes (in|out): 9018 | 10981 -- (27
 OnMessages, 24 Sends)
 }}}
 lines I would have assumed that it was wedged.

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