Re: [tor-bugs] #24477 [Applications/Tor Browser]: Windows 64 mar files are not generated

[Tor Bug Tracker & Wiki]

#24477: Windows 64 mar files are not generated
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201712R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by gk):

 * keywords:  TorBrowserTeam201712R => tbb-rbm, TorBrowserTeam201712R
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Works for me although I guess we could have done something like
 {{{
  # Extract the MAR tools.
 -unzip -d $rootdir $rootdir/[% c('input_files_by_name/firefox') %]/mar-
 tools-*.zip
 +[% IF c("var/windows-x86_64") -%]
 +  # Workaround for bug 24477
 +  unzip -d $rootdir $rootdir/mar-tools-linux32.zip
 +[% ELSE %]
 +  unzip -d $rootdir $rootdir/[% c('input_files_by_name/firefox') %]/mar-
 tools-*.zip
 +[% END -%]
 }}}
 as well. Anyway, pushed to `master` as commit
 0abccfe4258218612f38ac1c2d762c319781386f.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21925 [Applications/Tor Browser]: Tor Browser based on ESR52 can't get built with ASan and FORTIFY_SOURCE

[Tor Bug Tracker & Wiki]

#21925: Tor Browser based on ESR52 can't get built with ASan and FORTIFY_SOURCE
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21998| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I still hit that one with GCC 6.4.0 and have filed
 https://bugzilla.mozilla.org/show_bug.cgi?id=1422254.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21998 [Applications/Tor Browser]: Add the option for debug builds to rbm

[Tor Bug Tracker & Wiki]

#21998: Add the option for debug builds to rbm
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201712  |  Actual Points:
Parent ID:  #17379 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-rbm, TorBrowserTeam201711 => tbb-rbm, TorBrowserTeam201712


Comment:

 Thanks. One final thing. I am a bit wary to start collecting Firefox
 patches in `tor-browser-build`. While I think there could be an argument
 made for the #23231 workaround (who really is using plain tor-browser.git
 to cross-compile stuff for Windows??) I think it does not hold for the
 ASan case. We are shipping a `.mozconfig-asan` file and, in fact, if one
 uses Linux and wants to do dev work there is no need to use an `rbm` build
 for that. Thus, let's keep the workaround for #21925 in tor-browser.git.
 There should not be any breakage for the non-ASan series regardless the
 platform we compile for. And it would make the `tor-browser-build` patch
 simpler.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15251 [Core Tor/Tor]: Make tor support starting with 10.000 Tor Hidden Service

[Tor Bug Tracker & Wiki]

#15251: Make tor support starting with 10.000 Tor Hidden Service
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, scalability, tor-dos  |  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by naif):

 @teor do you think that Tor2webMode 1 (that require compile-time flags)
 will make connections going to HSDir to become 1-hop only?
 Ref: https://trac.torproject.org/projects/tor/ticket/2553

 That way the single-onion will also make outgoing "single-hop" connections
 for the connections to HSDirs ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24428 [Applications/Tor Launcher]: bootstrap error message sometimes lost

[Tor Bug Tracker & Wiki]

#24428: bootstrap error message sometimes lost
---+---
 Reporter:  brade  |  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:2 brade]:
 > Here is a fix:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug24428-01&id=2cc63c03e1c67e2db71e581db1f6ca17cb75bcd1

 Thanks, do you have some easy STR for me to check what happens without the
 patch and make sure your patch actually fixes this bug?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15251 [Core Tor/Tor]: Make tor support starting with 10.000 Tor Hidden Service

[Tor Bug Tracker & Wiki]

#15251: Make tor support starting with 10.000 Tor Hidden Service
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, scalability, tor-dos  |  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:16 naif]:
 > @teor do you think that Tor2webMode 1 (that require compile-time flags)
 will make connections going to HSDir to become 1-hop only?
 > Ref: https://trac.torproject.org/projects/tor/ticket/2553
 >
 > That way the single-onion will also make outgoing "single-hop"
 connections for the connections to HSDirs ?

 Don't do this. Connecting to HSDirs over a 1-hop path allows HSDirs to
 selectively deny service to clients and onion services based on their IP
 address. This is why single onion services connect over a 3-hop path.

 If you have this many onion services on a tor instance, it will need to be
 connected to most relays anyway. If you use a single onion service, it
 won't use fixed guards, so it will spread the HSDir circuit load over the
 entire network.

 Using single-hop paths for HSDirs is a bug in Tor2web that we plan to fix
 in #20104.
 Also, we plan on removing Tor2web in a few years time when we remove v2
 onion services. Tor2web isn't well tested or supported.

 Also, have you considered using subdomains on a few onion services, rather
 than trying to set up 10,000?
 Or do you need the authentication to each individual entity?

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21704, #23745, #18022, #23016, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21704, #23745, #18022, #23016, #23766, #23970, #24398, 
#24428 by gk:


Comment:
Moving review tickets over to December

--
Tickets URL: 

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---

Comment (by gk):

 I think the overlay idea is a good one. I am not sure about a good layout
 for the "Use a different bridge" part. There are basically three different
 UI elements pretty close together and all three interact somehow with each
 other. Might be confusing to users.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24437 [Webpages/Blog]: Change line height of blog post title

[Tor Bug Tracker & Wiki]

#24437: Change line height of blog post title
---+
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by hiro):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24384 [Metrics/Onionoo]: Decode percent-encoded characters in qualified search terms

[Tor Bug Tracker & Wiki]

#24384: Decode percent-encoded characters in qualified search terms
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Onionoo-1.9.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

 * cc: irl (added)


Comment:

 I've made some changes to the way that URLs are encoded and uploaded to a
 webserver. Could you let me know if this fixes the issues?

 https://people.torproject.org/~irl/atlas/#

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23424 [Applications/Tor Browser]: Stop exposing the moz-icon URL scheme to the web

[Tor Bug Tracker & Wiki]

#23424: Stop exposing the moz-icon URL scheme to the web
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-fingerprinting, ff59-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-fingerprinting => tbb-fingerprinting, ff59-esr


Comment:

 It seems we will get this with ESR59. However, we want to check that,
 while it is not allowed any longer to link to moz-icon URLs, the presence
 of a moz-icon handler is not leaking, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1222924#c14.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12420 [Applications/Tor Browser]: Investigate deploying STACK to check for optimization-unstable code

[Tor Bug Tracker & Wiki]

#12420: Investigate deploying STACK to check for optimization-unstable code
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201711,  |  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 I successfully deployed STACK to check for optimization-unstable code in
 tor. It found some bugs which are about the get resolved (see: #24423).
 Unfortunately, the current code works only with clang 3.4 which is pretty
 old and not new enough to check the browser part. I plan to work on that
 to get it going with clang 3.6 at least (which is currently the minimum
 required for compiling Firefox 52ESR).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12420 [Applications/Tor Browser]: Investigate deploying STACK to check for optimization-unstable code

[Tor Bug Tracker & Wiki]

#12420: Investigate deploying STACK to check for optimization-unstable code
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201711,  |  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * priority:  Very High => Medium


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6236 [Core Tor/Tor]: Remove duplicate code between parse_{c, s}method_line

[Tor Bug Tracker & Wiki]

#6236: Remove duplicate code between parse_{c,s}method_line
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client easy refactor duplicate-  |  Actual Points:
  code   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Hey! I am a beginner. Can I work on 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] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-

Comment (by asn):

 Replying to [comment:14 nickm]:
 > I'm okay with backporting this if somebody prepares a branch.

 Hello. Pushed `bug23862_031` and `bug23862_030` 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] #6236 [Core Tor/Tor]: Remove duplicate code between parse_{c, s}method_line

[Tor Bug Tracker & Wiki]

#6236: Remove duplicate code between parse_{c,s}method_line
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client easy refactor duplicate-  |  Actual Points:
  code   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:5 aruna1234]:
 > Hey! I am a beginner. Can I work on this?

 Go for it!

 Let us know on IRC if you have any questions :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6773 [Core Tor/Tor]: DirServer lines should take more than one "orport="

[Tor Bug Tracker & Wiki]

#6773: DirServer lines should take more than one "orport="
---+---
 Reporter:  ln5|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, tor-dirauth, good-idea easy  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by aruna1234):

 Hey! I am a beginner! Can I work on 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] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

[Tor Bug Tracker & Wiki]

#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by aruna1234):

 * severity:   => Blocker


Comment:

 Hey!! I am a beginner ! Can I work on 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] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

[Tor Bug Tracker & Wiki]

#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * severity:  Blocker => Minor


Comment:

 Sure, go ahead!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15518 [Core Tor/Tor]: Tor considers routers in the same IPv6 /16 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15518: Tor considers routers in the same IPv6 /16 to be "in the same subnet"
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, path, path-bias, tor-client|  Actual Points:
  easy   |
Parent ID:  #24393   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Hey!! I am a beginner! Can I take this up!

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

[tor-bugs] #24478 [Applications/Tor Browser]: Enable tests and debug assertions in our ASan builds

[Tor Bug Tracker & Wiki]

#24478: Enable tests and debug assertions in our ASan builds
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201712,
 Severity:  Normal   |  GeorgKoppen201712, tbb-rbm
Actual Points:   |  Parent ID:  #24154
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should make a full debug build with our ASan build(s) in order to allow
 us better to fuzz them.

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

Re: [tor-bugs] #6773 [Core Tor/Tor]: DirServer lines should take more than one "orport="

[Tor Bug Tracker & Wiki]

#6773: DirServer lines should take more than one "orport="
---+---
 Reporter:  ln5|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, tor-dirauth, good-idea easy  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by ln5):

 This wouldn't hurt, but also wouldn't help much until #6772 is implemented
 i think.

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

Re: [tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  docs => tor-client
 * priority:  Low => Medium
 * type:  enhancement => defect
 * severity:  Minor => Normal
 * milestone:   => Tor: 0.3.3.x-final


Comment:

 It looks like this might be a bug in the new 0.3.x guard code.

 Is there some reason that our circuits change every 5 minutes?
 Do we build a new circuit every 5 minutes?
 Do new streams go on new circuits in 0.3.1, but old circuits in earlier
 versions?

 Replying to [comment:8 Zakhar]:
 > '''[(Almost) Solved]'''
 >
 > I make this a '''low priority documentation enhancement'''!
 >
 > The README says that we must do
 >
 > {{{
 > To build Tor from source:
 > ./configure && make && make install
 > }}}
 >
 > Proposition:
 > {{{
 > To build Tor from source:
 > ./configure && make && make install
 >
 >(or use the build procedure specific to your distribution)
 > }}}
 >
 >
 > Indeed, the documentation could also hint other specific ways of
 building/compiling according to the distribution. Otherwise the trouble is
 that with Debian/Ubuntu '''it works''' but in the end you get an
 executable with strange behavior like the one above.
 >
 >
 > For those who might search, here is how to make it work instead of
 ./configure && make:
 >
 > {{{
 > apt-get install build-essentials fakeroot dpkg-dev
 > apt-get build-dep tor
 > fakeroot debian/rules binary
 > }}}
 >
 > In the end you get a .deb repackaged with your newly compiled source.
 > - same size as the Ubuntu stock binary
 > - same default config files
 > - works with MaxCircuitDirtiness
 >
 >
 > Interesting link: https://www.cyberciti.biz/faq/rebuilding-ubuntu-
 debian-linux-binary-package/
 >
 >
 > '''(Almost)''' because I am now wondering how I will get a working
 Debian Package when I'll try the 0.3.1.8 (or more recent) from the tor
 git/tar.gz
 >
 > Also a small signature issue since I don't have the private key of the
 initial Debian/Ubuntu maintainer, I can't obviously re-sign the package...
 but that is non tor related!

 Please open a separate ticket for this issue.
 We lose track of issues when there is more than one issue in a ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth, easy, intro  |  Actual Points:
Parent ID:  #24403| Points:  1
 Reviewer:|Sponsor:  SponsorV-can
--+
Changes (by teor):

 * sponsor:   => SponsorV-can


Comment:

 Here's what we need to do to fix this bug:

 If an authority has an IPv6 ORPort, it should assume its own IPv6 ORPort
 is reachable, and vote for it.
 This is what authorities do for their own Reachable flag, so we should be
 able to use the same code for this fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24478 [Applications/Tor Browser]: Enable tests and debug assertions in our ASan builds

[Tor Bug Tracker & Wiki]

#24478: Enable tests and debug assertions in our ASan builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201712R,   |  Actual Points:
  GeorgKoppen201712, tbb-rbm |
Parent ID:  #24154   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201712, GeorgKoppen201712, tbb-rbm =>
 TorBrowserTeam201712R, GeorgKoppen201712, tbb-rbm
 * status:  new => needs_review
 * sponsor:   => Sponsor4


Comment:

 `bug_24478` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_24478&id=6c889e3bd6a3dec009f11b5b648b20bdfcaafb3f)
 is up for review. I've been doing several local builds with that
 configuration locally over the last couple of days (taking #21925 into
 account) and it works for me.

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

Re: [tor-bugs] #6773 [Core Tor/Tor]: DirServer lines should take more than one "orport="

[Tor Bug Tracker & Wiki]

#6773: DirServer lines should take more than one "orport="
---+---
 Reporter:  ln5|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  ipv6, tor-dirauth, good-idea easy  |  Actual Points:  0
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => closed
 * milestone:  Tor: unspecified => Tor: 0.2.8.x-final
 * resolution:   => duplicate
 * actualpoints:   => 0


Comment:

 Hi aruna1234,

 Thanks for being keen to help out with Tor!
 It turns out that we already implemented this a few years ago when we gave
 authorities and fallback directories an "ipv6=" field in #17327.
 But we never closed this ticket. Oops!

 If you want to work on a similar intro ticket, try #24338.

 (And I don't think we'll ever want more than one IPv4 or IPv6 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] #24479 [Applications/Tor Browser]: NoScript shouldn't block local HTML5 video and audio files when security slider is set to medium or high

[Tor Bug Tracker & Wiki]

#24479: NoScript shouldn't block local HTML5 video and audio files when security
slider is set to medium or high
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 NoScript shouldn't block local HTML5 video and audio files when security
 slider is set to medium or high

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6772 [Core Tor/Tor]: Fall back to alternative OR or Dir port if the current fails

[Tor Bug Tracker & Wiki]

#6772: Fall back to alternative OR or Dir port if the current fails
-+-
 Reporter:  ln5  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-client tor-hs single-onion  |  Actual Points:
  robustness address-handling|
Parent ID:  #17835   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * keywords:  ipv6 tor-client robustness address-handling => ipv6 tor-client
 tor-hs single-onion robustness address-handling
 * priority:  Low => Medium
 * points:   => 1
 * sponsor:   => SponsorV-can
 * parent:  #17811 => #17835


Comment:

 Existing client guard code already implements this feature by trying
 another guard if one fails.
 #24403 will make relays retry IPv4 and IPv6 when an EXTEND has both
 addresses.
 #17835 should do the same for client connections to entry nodes.
 (If a specific entry node is required (single onion services only?), we
 should choose an available address at random. If not, we should do what
 the existing guard code does, and choose another entry node at random -
 because we are more likely to succeed than a retry.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15518 [Core Tor/Tor]: Tor considers routers in the same IPv6 /16 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15518: Tor considers routers in the same IPv6 /16 to be "in the same subnet"
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, path, path-bias, tor-client|  Actual Points:
  easy   |
Parent ID:  #24393   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 You can!
 Try to stick with the same coding style we use,
 And submit a patch as a diff attachment or a git branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15518 [Core Tor/Tor]: Tor considers routers in the same IPv6 /16 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15518: Tor considers routers in the same IPv6 /16 to be "in the same subnet"
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, path, path-bias, tor-client|  Actual Points:
  easy   |
Parent ID:  #24393   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by Samdney):

 *argh* I forgot to assign it to me. *argh*. I have already spent some time
 with this.

 But it was my mistake, hence you can take it aruna1234. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24154 [Applications/Tor Browser]: Look into fuzzing our tor-browser patches

[Tor Bug Tracker & Wiki]

#24154: Look into fuzzing our tor-browser patches
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201711,|  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 To sum up on where we are with this:

 To get started with fuzzing the Firefox codebase it seems worth trying to
 get our own patches under scrutiny first. Firefox itself is regularly
 fuzzed by an own, specialized team targeting different components (like
 the JS engines).

 As we don't have any JS engine patches ourselves there is no need for
 looking for a specialized tool in that area. Instead I started to look
 into `domfuzz` (https://github.com/MozillaSecurity/domfuzz) while glancing
 over `domato` (https://github.com/google/domato) which we might deploy
 later on.

 I got `domfuzz` running locally and started fuzzing our code using ASan
 builds (see: #21998 and #24478). There are some challenges we might want
 to consider, though, to make this a smoother and more successful
 experience:

 1) We are using ESR 52 and git and the fuzzing code is expecting `mozilla-
 central` and a mercurial repo. We can work around that but might benefit
 from the idea to at least rebase our patches to `mozilla-central`
 regularly (see: https://lists.torproject.org/pipermail/tbb-
 dev/2017-November/000669.html) and use that. That might as help with the
 plan to discover issues in the Firefox codebase itself.

 2) Doing fuzzing on local computer does not scale and does not give good
 results. Thus, we need to get dedicated machines for that thinking about
 budget etc. I asked Mozilla if we could share resources somehow but they
 declined for good reasons. But they are willing to help us to duplicate
 their infrastructure or at least to get their tools running for us.

 3) There is currently no process established to get the feedback from the
 fuzzing efforts back into the development cycle (like ticket creation,
 ticket assignments and working on them).

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

Re: [tor-bugs] #24154 [Applications/Tor Browser]: Look into fuzzing our tor-browser patches

[Tor Bug Tracker & Wiki]

#24154: Look into fuzzing our tor-browser patches
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201711,|  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * priority:  Very High => Medium


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12514 [Applications/Tor Browser]: Tor Button does not work unless Navigation toolbar is enabled

[Tor Bug Tracker & Wiki]

#12514: Tor Button does not work unless Navigation toolbar is enabled
-+-
 Reporter:  pursuit81|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  easy   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Hey!! Can I work on this bug? I am a newbie.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor|  Actual Points:
  technical-debt tor-relay   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Could you give more information as to what is the problem?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12514 [Applications/Tor Browser]: Tor Button does not work unless Navigation toolbar is enabled

[Tor Bug Tracker & Wiki]

#12514: Tor Button does not work unless Navigation toolbar is enabled
-+-
 Reporter:  pursuit81|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  easy   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:8 aruna1234]:
 > Hey!! Can I work on this bug? I am a newbie.

 Go for 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] #24244 [Core Tor/Tor]: Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services. (was: Fix TROVE-2017-009)

[Tor Bug Tracker & Wiki]

#24244: Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services.
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  trove-2017-009  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Old description:



New description:

 {{{
 TROVE-2017-009: Replay-cache ineffective for v2 hidden services.

 SEVERITY: Medium

 ALSO TRACKED AS: CVE-2017-8819

 SUMMARY:

   There's a possibility for a limited replay attack of INTRODUCE2 cells
   towards a legacy (v2) onion service.

 BACKGROUND:

   The hybrid-encryption algorithm we used for v2 onion services is
   somewhat malleable.  To encrypt the message X to a public key PK,
   clients generate a random AES key K, and then send

  RSA-OAEP(K || Start-of-X) || AES_CTR(K, End-of-X)

   But as you'll notice, the AES-encrypted portion is unauthenticated
   and therefore malleable.  It contains a portion of the g^x DH key.

   What this means is that an attacker who sees a v2 onion service's
   INTRODUCE1 cell can send a large number of corresponding INTRODUCE2
   cells each containing a g^x that differs in the final bits.  When
   the v2 onion service gets one of these altered cells, it will launch a
   connection to the same rendezvous point as before, with a different
   g^y, and a different KH.

   Because of this attack, in 0.2.3.4-alpha, we changed the replay
   cache so that it checks for replays in the RSA-encrypted
   (non-malleable) portion.

   For more info, see tor-spec.txt, section 0.4; rend-spec-v2.txt,
   sections 1.8 and 1.9.

 THE PROBLEM:

   In 471ab34032581e6631c23ee05a2b212e757bafab, when we refactored the
   v2 onion service code in Tor 0.2.4.1-alpha, we accidentally
   included this change.

   The critical part is the change in the length of data added
   checked: previously, it was only "keylen" -- the length of the RSA
   key.  But now it's the whole ciphertext, when means that a
   modified version won't get detected as a replay.

 IMPACT:

   If an attacker can observe the rendezvous point, they can make the
   onion service make lots of connections to it -- but any attacker
   can already do that if they know the onion service's public key by
   sending their own INTRODUCE1 cells and picking a rendezvous point
   they control.  (And in the v2 hs design, we should assume the
   attacker already knows the onion service's public key, because of
   directory crawling attacks.)

 FIX:

   Anyone who is running a v2 (old) hidden service should upgrade to
   one of the releases with the fix for this issue: 0.2.5.16, 0.2.8.17,
   0.2.9.14, 0.3.0.13, 0.3.1.9, or 0.3.2.6-alpha.

 }}}

--

Comment:

 Fixed in today's releases.

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

Re: [tor-bugs] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor|  Actual Points:
  technical-debt tor-relay   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The names of the functions are confusing.
 We want them to have a good structure and a consistent naming scheme.
 We should improve the comments, rename, combine, or split some of them.

 So maybe this is not an easy ticket after all.
 Do you like reading code, understanding it, and giving it a better
 structure?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24245 [Core Tor/Tor]: Fix TROVE-2017-010: Remote DoS attack against directory authorities (was: Fix TROVE-2017-010)

[Tor Bug Tracker & Wiki]

#24245: Fix TROVE-2017-010: Remote DoS attack against directory authorities
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  trove-2017-010  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  accepted => closed
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.2.9.x-final
 * resolution:   => fixed


Old description:



New description:

 {{{
 TROVE-2017-010: Remote DoS attack against directory authorities

 SEVERITY: Medium

 ALSO TRACKED AS: CVE-2017-8820

 SUMMARY:

   If an attacker uploads a malformed descriptor to a directory
   authority, lacking a protocol line and not claiming any particular
   Tor compatibility, the authority will crash when it tries to vote.

 THE PROBLEM:

   An attacker who sends a malformatted descriptor to a directory
   authority can make that directory authority crash by reading a null
   pointer.

   The problematic code was introduced in 0.2.9.4-alpha, with the rest
   of the subprotocols system.

 FIX:

   All directory authorities should upgrade to one of the releases with
   a fix for this issue: 0.2.9.14, 0.3.0.13, 0.3.1.9, or 0.3.2.6-alpha.

 }}}

--

Comment:

 This issue is fixed in today's security releases.

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

Re: [tor-bugs] #24246 [Core Tor/Tor]: Fix TROVE-2017-011: An attacker can make tor ask for a password (was: Fix TROVE-2017-011)

[Tor Bug Tracker & Wiki]

#24246: Fix TROVE-2017-011: An attacker can make tor ask for a password
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  trove-2017-011  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Old description:



New description:

 {{{
 TROVE-2017-011: An attacker can make Tor ask for a password

 SEVERITY: High

 ALSO TRACKED AS: OSS-Fuzz testcase 6360145429790720, CVE-2017-8821

 CREDIT: This was found by OSS-Fuzz.

 SUMMARY:

   All over our code, we accept parse RSA public keys in the "PEM"
   format, such as:

   -BEGIN RSA PUBLIC KEY-
   SXQncyBjb29sIHRoYXQgeW91IHdlcmUgY29uY2VybmVkIGVub3VnaCB0byBjaGVj
   aywgYnV0IHRoZXJlIGlzIGluIGZhY3Qgbm8gc2VjcmV0IGluZm9ybWF0aW9uIGhl
   cmUuICBUaGlzIHNwYWNlIGludGVudGlvbmFsbHkgbGVmdCBibGFuay4=\n
   -END RSA PUBLIC KEY-

   But if you pass OpenSSL a public key that's suitably constructed, it
   will ask for a password.  This applies to public keys as well as
   private keys!

   If this "key" is used in a microdescriptor, an onion service
   descriptor, a relay or bridge descriptor, or anywhere, then OpenSSL
   will pause, and ask for a passphrase.  This blocks Tor, causing a
   denial of service attack. If it causes an onion service or busy client
   to block, this could aid in traffic analysis.

   Tors that are running as a daemon (without a terminal) or inside
   another process may not be vulnerable -- it depends on OpenSSL's
   behavior when it tries to ask for a password.

 FIX:

   Everyone affected should upgrade to one of the releases with the fix
   for this issue: 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or
   0.3.2.6-alpha.

 }}}

--

Comment:

 Fixed in today's security releases.

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

Re: [tor-bugs] #24333 [Core Tor/Tor]: Fix TROVE-2017-012: Relays can pick themselves in a circuit path (was: Fix TROVE-2017-012)

[Tor Bug Tracker & Wiki]

#24333: Fix TROVE-2017-012:  Relays can pick themselves in a circuit path
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  trove-2017-011  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Old description:

> Ticket for medium severity issue TROVE-2017-012
>
> See https://trac.torproject.org/projects/tor/wiki/TROVE

New description:

 Ticket for medium severity issue TROVE-2017-012

 See https://trac.torproject.org/projects/tor/wiki/TROVE

 {{{
 TROVE-2017-012: Relays can pick themselves in a circuit path

 SEVERITY: Medium

 ALSO TRACKED AS: CVE-2017-8822

 DESCRIPTION

 A relay can open circuits for reachability purposes, preemptive
 Exit circuits or possible onion service client usage. If a relay
 doesn't have the descriptors of all the relays in the network, it
 is possible for the relay to pick itself in a circuit path like so
 (R1: Relay, G: Guard, E: Exit):

 R1 -> G -> R1 -> E

 This leads to a log warning on the Guard node and the circuit
 being closed immediately because tor doesn't allow to extend to
 the previous node.

 Furthermore, a relay can also pick itself as a primary guard,
 leading to it being unable to open any circuits for a while, until
 enough failures have been recorded and the guard is switched.

 This can only happens if the relay doesn't have all descriptors
 downloaded yet, and if it considers itself in the consensus.

 This affects version >= 0.2.0.x series which is basically every
 relay on the network.

 MITIGATION NOTES:

 1. If you are using tor but it is not configured as a relay, this
doesn't affect you.

 2. This can have anonymity consequences if you are running a
onion service and a relay at the same time on the same tor
instance. It is something we do NOT recommend in the first
place, so: avoid doing this.

 ACKNOWLEDGMENTS:

Thanks to the Tor network team members who tracked this down!

 FIX:

Everyone affected should upgrade to one of the releases with the fix
for this issue: 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or
0.3.2.6-alpha.
 }}}

--

Comment:

 Fixed in today's security releases.

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

Re: [tor-bugs] #24430 [Core Tor/Tor]: Fix TROVE-2017-013: Use-after-free in onion service v2 when rotating intro points (was: Fix TROVE-2017-013)

[Tor Bug Tracker & Wiki]

#24430: Fix TROVE-2017-013: Use-after-free in onion service v2 when rotating 
intro
points
+
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  trove-2017-013  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Old description:

> Ticket for high severity issue TROVE-2017-013
>
> See https://trac.torproject.org/projects/tor/wiki/TROVE

New description:

 Ticket for high severity issue TROVE-2017-013

 See https://trac.torproject.org/projects/tor/wiki/TROVE

 {{{
 TROVE-2017-13: Use-after-free in onion service v2 when rotating intro
 points

 SEVERITY: High

 ALSO TRACKED AS: CVE-2017-8823

 DESCRIPTION

 An onion service v2 expires its intro points regularly at least
 once very 24 hours. While removing an intro point, if no circuit
 is found, it is put in a retry list. Then just after, if it is
 removed because it is expiring, it is put in the expiring list.

 Tor then tries to open a circuit to that node and, on failure, it
 will free the intro point without removing it from the expiring
 list ultimately leading to a use-after-free.

 This can only happens in specific conditions which are that the
 service's is unable to launch circuits, this can happen if it is
 missing descriptors for instance and if the intro points was just
 being expired. It only affects version 2 services.

 MITIGATION NOTES:

 1. If you are not running an onion service, this doesn't affect
you.

 2. If you are running tor version <= 0.2.6, this doesn't affect
you.

 3. We believe this to be quite difficult to trigger remotely
because of the specific conditions that tor needs to be
in. However, it could be possible but hard to be induced by a
malicious Guard node suspecting a connection to be an onion
service.

 ACKNOWLEDGMENTS:

 Thanks to an anonymous reporter on our bugtracker that opened a
 ticket which lead to the discovery of this issue.

 FIX:

 Anybody running an onion service on an affected version should
 upgrade to one of the releases with the fix for this issue:
 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or 0.3.2.6-alpha.
 }}}

--

Comment:

 Fixed in today's security releases.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Thanks for the really helpful review! All of these suggestions make sense-
 I wasn't sure about the best way to import dependencies for a macro in
 other modules.

 It is interesting to hear your recommendation to use a function for the
 macro body. Would you recommend using the #[inline] tag for that function
 then?

 I'll make these fixes over the weekend, thanks again for the help.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Also lets consider #24228. A fresh relay without a Guard state will
 open/close many circuits to ramp up as quickly as possible the CBT
 (circuit build timeout) and it don't honor `MaxCircuitDirtiness` but
 rather a random interval usually around 60 seconds.

 It should stabilize after 100 circuits are created and the CBT is then
 used normally. It takes ~30 minutes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 rendservice.[ch] are mixing signed and unsigned types for struct
 rend_intro_cell_s member ciphertext_len.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24201 [Core Tor/Tor]: spec: ADD_ONION syntax is not reflecting the code

[Tor Bug Tracker & Wiki]

#24201: spec: ADD_ONION syntax is not reflecting the code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Good point. I just pushed the trivial fix in commit: `4f809e03629cd372`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ln5):

 Using clang 3.4.1:

 {{{
   CC   src/or/rendservice.o
 /usr/local/src/tor/src/or/rendservice.c:2027:29: error: comparison of
 integers of different signs: 'ssize_t'
   (aka 'long') and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-
 compare]
 parsed_req->ciphertext, MIN(parsed_req->ciphertext_len, keylen),
 ^   ~~  ~~
 /usr/include/sys/param.h:298:23: note: expanded from macro 'MIN'
 #define MIN(a,b) (((a)<(b))?(a):(b))
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24346 [Core Tor/Tor]: prop224: Service stops uploading one of its two descriptors

[Tor Bug Tracker & Wiki]

#24346: prop224: Service stops uploading one of its two descriptors
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Arf indeed... So I think we either want to have a `rlimit_t` object per
 condition so each of them control their limit.

 Second thing, we probably want to decouple `current` and `next` then so
 they don't get caught in the same rlimit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24313 [Core Tor/Tor]: Crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]

[Tor Bug Tracker & Wiki]

#24313: Crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

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


Comment:

 Fixed as part of #24430.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Merged with TROVE-2017-012 in #24333.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ln5):

 See branch bug24480 in my public repo for a fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+--
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ln5):

 * status:  new => needs_review


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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+

Comment (by dgoulet):

 I'm going to add my opinion to this.

 There are cases (and maybe not standardize) where lowercase makes sense.
 For me, it does when the macro acts as a "function" that kind of could be
 a `static inline` but can't because we need to handle local variables
 (`tor_free()` for instance). And the lower case macro don't need to have
 pre-processor tricks applied to it (like doing arithmetic in it).

 I think there is a separation of semantic between a lower and upper case
 macro and Tor kind of follows it as "acting as a function" vs constant or
 inline testing a value (ex: `ERRNO_IS_EAGAIN()`).

 The case of `tor_free()` for me is a clear Tor wrapper around libc
 functions to make them safer and we have a many of those but they are
 functions. And I would prefer that it stays lower case for the semantic
 here linking that to our other wrappers and as `tor_free_()` is a
 function. Furthermore, there is a "if(predict_likely)" in there so one
 more argument in my opinion to treat it as a "function" that does have
 conditions and is a wrapper over the libc free().

 Finally, this change will hurt the `git blame` for no gain imho. We'll
 actually bring confusion and more syntax split with the current code base
 as asn pointed out our other lower case macros (`approx_time()` is a big
 one.)

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+

Comment (by nickm):

 So, I had originally left all these macros in lowercase, until someone
 (Taylor, I think?) asked me "so, what problems have we run into with
 `tor_free()` so far?"  And the biggest problems I could think of is that
 people are confused because `tor_free()` does not actually behave like a
 function.

 In C, if you call `foo(ptr)`, and foo is a function, then the value of
 `ptr` cannot change.  But `tor_free(ptr)` does change the value of `ptr`
 to NULL, which is something that tor_free() could not do if it were a
 function.  New developers on Tor often don't expect this to happen.

 That said, it is usually a pretty short learning curve, so it might be
 okay to leave everything as it is.

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

Re: [tor-bugs] #24428 [Applications/Tor Launcher]: bootstrap error message sometimes lost

[Tor Bug Tracker & Wiki]

#24428: bootstrap error message sometimes lost
---+--
 Reporter:  brade  |  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:3 gk]:
 > Thanks, do you have some easy STR for me to check what happens without
 the patch and make sure your patch actually fixes this bug?

 It is a little tricky to reproduce because the bug is timing-dependent, so
 you may need to try several times. And note that Kathy and I only
 reproduced it on OSX (but I think catalyst saw it on Linux). That said,
 here are some STR:
 1. Start with a clean Tor Browser that uses the new Tor Launcher UI, e.g.,
 7.5a8.
 2. Set you system clock forward; Kathy and I used 24 or 25 hours but
 catalyst saw the bug with a +3.5 hour offset.
 3. Start Tor Browser and click Connect.

 If the bug occurs, you will see a stalled progress bar after a while with
 a bold progress message such as "Loading relay information." The bold font
 is an indication that an error message was displayed and then replaced
 with a regular bootstrap progress message.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+

Comment (by dgoulet):

 Right. The "change the local value" is the part that is making it stand
 out as a "function". But having it upper case won't help much of making
 new developers realize it "could do" something like that imo... It might
 maybe motivate them to go look at the macro?...

 TBH, I personally don't see that as a "problem" for new developers, as
 long as we document it properly. But also, every `tor_*` function, any
 developer should look at them when they use them because we do wrappers
 for safety and/or compatibility reasons which imo MUST be known to any
 developers.

 We could help new developers by adding a note to our HACKING/
 documentation on "if you use tor_*, please go read them" kind of
 statement.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+--
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Bug confirmed.

 For the fix, how about we just change keylen to ssize_t instead?  It is a
 smaller and much less risky change, since it's only a local variable, and
 only used in one place.

 Example patch:
 {{{
 diff --git a/src/or/rendservice.c b/src/or/rendservice.c
 index ba8891eade39ea..80e1e10a054b4a 100644
 --- a/src/or/rendservice.c
 +++ b/src/or/rendservice.c
 @@ -1162,7 +1162,7 @@ rend_service_introduce(origin_circuit_t *circuit,
 const uint8_t *request,
time_t now = time(NULL);
time_t elapsed;
int replay;
 -  size_t keylen;
 +  ssize_t keylen;

/* Do some initial validation and logging before we parse the cell */
if (circuit->base_.purpose != CIRCUIT_PURPOSE_S_INTRO) {
 }}}

 What do you think?

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-26  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+

Comment (by Hello71):

 I support uppercase for all macros. Even for long-time contributors that
 know tor_free is a macro, it increases cognitive overhead unnecessarily.
 In the absence of strong overriding factors, like "C does not support
 this", the code should be as easy to read as possible, with syntactic
 sugar that is as transparent as possible, without having to keep some
 extra thing in mind. A small thing, I agree, but death by a thousand cuts.

 tl;dr even oldies can use a reminder

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21925 [Applications/Tor Browser]: Tor Browser based on ESR52 can't get built with ASan and FORTIFY_SOURCE

[Tor Bug Tracker & Wiki]

#21925: Tor Browser based on ESR52 can't get built with ASan and FORTIFY_SOURCE
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21998| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 You're not supposed to build ASAN with FORTIFY, or so I am told by people
 who I think know what they're talking about.

 See:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1377553
 https://bugzilla.mozilla.org/show_bug.cgi?id=1419607
 https://bugzilla.mozilla.org/show_bug.cgi?id=1418052

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+-
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Changing `size_t keylen` to `ssize_t keylen` looks good to me.

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

Re: [tor-bugs] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Added a changes file and pushed as
 461e34bb3dec0f4f7234584806a224040f44c7ed. 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] #24450 [Metrics/Atlas]: Relay Search never loads in Internet Explorer 11 on Windows 7

[Tor Bug Tracker & Wiki]

#24450: Relay Search never loads in Internet Explorer 11 on Windows 7
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 Fixed in d081c09. Internet Explorer is the earliest we can reasonably
 support. I tried to aim for IE 10 but it would be a lot of work.

 This fix will also work for Opera >15.0 which previously was also broken.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24201 [Core Tor/Tor]: spec: ADD_ONION syntax is not reflecting the code

[Tor Bug Tracker & Wiki]

#24201: spec: ADD_ONION syntax is not reflecting the code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Thanks David, pushed Stem support for MaxStreamsCloseCircuit...

 https://gitweb.torproject.org/stem.git/commit/?id=1ffcb59

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+-
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+-
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Hi Antonela. Seems this is missing a few things. As mentioned in email
 this should look like:
 https://trac.torproject.org/projects/tor/ticket/17353

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24464 [Metrics/Atlas]: Add aggregate by what selection to Aggregated Search (like on compass)

[Tor Bug Tracker & Wiki]

#24464: Add aggregate by what selection to Aggregated Search (like on compass)
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID:  #24445 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 This functionality exists on the Advanced Search form, and is only a
 single click when you get to the full aggregated results page to drill
 down the aggregation. You can also link directly to the drilled down
 aggregation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24463 [Metrics/Atlas]: Advanced search: Add a client auto-completion filter to AS field

[Tor Bug Tracker & Wiki]

#24463: Advanced search: Add a client auto-completion filter to AS field
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Very Low   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * priority:  Medium => Very Low


Comment:

 This would mean that the full details document needs to be fetched in
 order to produce the search form, which I'd rather not do. When
 aggregations are supported by Onionoo it will be easier to add this
 functionality. Unlike for countries where there are rarely changes, the
 number of ASs is huge and always changing, so this really does need to be
 fetched dynamically.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24461 [Metrics/Atlas]: Require less scrolling on advanced search page

[Tor Bug Tracker & Wiki]

#24461: Require less scrolling on advanced search page
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * owner:  metrics-team => irl
 * status:  new => accepted


Comment:

 Moving this into my queue.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * cc: hola@… (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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+-
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Right-- also, did you mean just an email alias, or did you mean an ldap
 account?

 (If you're going to be doing git pushes to git.torproject.org repos, or
 you're going to want to be logging in to Tor computers, then you want an
 ldap account, otherwise just an email forward is simpler.)

 For the documentation on the process, look here:
 https://help.torproject.org/tsa/doc/accounts/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+-
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 @arma I just need an alias. Not LDAP account needed :)
 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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by irl):

 * Attachment "existing_flag_icons.tar.gz" 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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by irl):

 Sorry this took a while to get back to. I've attached the existing icons
 that are used by Relay Search.

 teor: That's exactly the same semantics as the Relay Search flag, so
 perhaps Relay Search should rename it?

 antonela: Please let me know if you would like me to review/give feedback
 for any designs. I'm happy to make time to do so.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+-
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ewyatt):

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please create email forwarding/uid for Antonela (no LDAP):

 First name: Antonela
 Last name: Debiasi
 Desired alias/uid: antonela
 Forwarding email: t...@antonela.me
 PGP key: 3661 678E 1CCE C8D4 9AF5  CFCD E233 0A6D 1EB5 A0C8

 Thank you!
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlohn7AACgkQugyUAPgP
 kc41Xg/5Afi4HsYFzbf1u67idWgr+G5MbQ03kK+wx7kXcl8QPpv+gekvh8cUUDr9
 idLjB8GmyJZgZCe7mW0Ru/U3dIQrbh7RwnZb7tsA9nVTee1mzBvdii0RmJ2mIva2
 JKUaoJQ+fsjncZIMn25U0l9wam0KV4RYG/pOA5MWVj8jrCeLfHOCdP1AH5UlK4wK
 bhlCUhoYKyNoxGl1h7J+b/tzIVR0pte72ZxCAVFL0JF73X85IVPIczCYmkNsRx7z
 U1A9KGU1DoXOwRLtX6BnEqrAMufYb7jJcgUNgjgOoCk6sSkfzC7lG1cvd8vPQRNw
 AEgOXYix6kXtltAUdZjJpVsDJJLzPGV1O8/H9IO8ZMcp/1dNJYFE5pE2iFrqHfAk
 eTAO4Hmwa6gNh3FI4ucRWFgDIrc8Fsk4dWYa6p4nOSUjjMxaT2ce6V4qehih9AqY
 s3GHiHVVVehaCx2t/I1863kvKvo6kBA8MmJZXON6znzuxy3QOeugQlQ7ZQMFfcDm
 S+ms99Bf9gye3SJCaVf4ZzLr+tl7f6F/rc38pAfT6p42perWjK0qW+H8HAAgeNiI
 hbJGA8Z72LCTExJU40la8ZG1qhkYaGKlTQJMXOFNmNW+IK5FEMxPKmPao7OO870V
 2ES1aJQN3vGnaYodUlQt9WpQW+KTNPb6A5DNXgVay6I9q3FFL3Y=
 =cXS3
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24480 [Core Tor/Tor]: Signed/unsigned mismatch

[Tor Bug Tracker & Wiki]

#24480: Signed/unsigned mismatch
--+
 Reporter:  ln5   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ln5):

 Replying to [comment:4 nickm]:
 > What do you think?

 I agree that's much better. 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

[tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

[Tor Bug Tracker & Wiki]

#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type: | Status:  new
  enhancement  |
 Priority:  Medium |  Milestone:
Component:  Core   |Version:  Tor: unspecified
  Tor/Tor  |
 Severity:  Normal |   Keywords:  tor repository deb.torproject.org
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Currently only the latest stable version is included in torproject repo.

 Example: https://deb.torproject.org/torproject.org/dists/jessie/main
 /binary-amd64/Packages has the latest 0.3.1.x series.

 It would be helpful to be able to apt-pin system tor to a particular major
 version (ie 0.2.9.x) and receive security updates while testing
 compatibility with the next major version. At the moment, updates to
 0.2.9.x must be built and distributed by a third-party even though 0.2.9.x
 is an LTS release.

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

Re: [tor-bugs] #24482 [Core Tor/Tor]: Upload all stable binaries to torproject debian repository

[Tor Bug Tracker & Wiki]

#24482: Upload all stable binaries to torproject debian repository
---+---
 Reporter:  entr0py|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor repository deb.torproject.org  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 What are you trying to do?

 If you want the LTS Tor, use the one in Debian stable, and if you want
 security updates, be sure to have a security.debian.org line in your
 sources.list?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:3 irl]:
 > teor: That's exactly the same semantics as the Relay Search flag, so
 perhaps Relay Search should rename it?

 They have subtly different semantics, so I'm not sure I want to rename
 them:
 * if an authority votes for one address in an "a" line, and another
 authority votes for a different address in an "a" line, they will both
 have the ReachableIPv6 flag in their votes, but the relay won't have an
 IPv6 ORPort in the consensus, because there is no majority.
 * for an authority to vote for any ReachableIPv6 "a" lines, it needs to
 have outbound IPv6 connectivity, and set AuthDirHasIPv6Connectivity. This
 is completely separate from whether the authority itself has an IPv6
 ORPort. (Example: dannenberg has ReachableIPv6 in its votes, but does not
 declare an IPv6 ORPort for itself.)
 * there's a subtle difference in semantics, too: in votes, ReachableIPv6
 means "I found this relay's IPv6 ORPort reachable" and UnreachableIPv6
 means "I normally vote for IPv6 ORPorts, and this relay claims one, but I
 didn't find it reachable". But IPv6 ORPort means "we have a consensus
 between the authorities voting ReachableIPv6 on the exact address and port
 of the IPv6 ORPort of this relay".

 Operators mainly care about IPv6 ORPort, until something goes wrong, and
 then they use ReachableIPv6 and UnreachableIPv6 for diagnostics.

 So let's update the list:
 * Running: This relay was found reachable on all of its OR addresses and
 ports.
 * IPv6 ORPort (consensus) / ReachableIPv6 (votes): This relay listens for
 OR connections using IPv6, and was found reachable via IPv6.
 * Unreachable IPv6 ORPort (consensus) / UnreachableIPv6 (vote): This relay
 has an unreachable IPv6 OR address or port according to at least one
 authority. (We can leave the version off this if you want, but we'd have
 to assign it for UnreachableIPv6 *and* not Running.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24483 [Core Tor/Tor]: Make bridges work when the authorities are blocked

[Tor Bug Tracker & Wiki]

#24483: Make bridges work when the authorities are blocked
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  bridge-guard, tor-bridge,
 Severity:  Normal   |  reachability
Actual Points:   |  Parent ID:
   Points:  2|   Reviewer:
  Sponsor:   |
-+-
 Bridges should be able to:
 * bootstrap using fallbacks
 * find and connect to enough relays to avoid failing too many client paths

 If bridges used bridge guards (ticket?), they would work even if most
 relays were blocked.

 This is similar to IPv6-only bridges (ticket?).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  reopened => needs_information


Comment:

 Replying to [comment:13 cypherpunks]:
 > After hibernation on Windows 7:

 But before that, it was running properly right? So it basically was
 running then hibernation and then came back and boom?

 Do you recall the length of time that it was in hibernation? Was it in the
 range of minutes or days?

 > {{{
 > Tor WARN: tor_bug_occurred_(): Bug: scheduler_kist.c:530:
 kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed. (Future
 instances of this warning will be silenced.) (on Tor 0.3.2.4-alpha )
 > Tor WARN: Bug: Non-fatal assertion !((diff < 0)) failed in
 kist_scheduler_schedule at scheduler_kist.c:530. (Stack trace not
 available) (on Tor 0.3.2.4-alpha )
 > }}}

 This is very surprising, it basically means that we got the last scheduler
 run in the future from "now" but both should be monotonic. Even if the
 last run is 0, the diff should be positive...

 Looking at our Windows compat call for `monotonic_get()`, I see this
 comment:

 {{{
   /* Alas, QueryPerformanceCounter is not always monotonic: see bug list
 at

 https://www.python.org/dev/peps/pep-0418/#windows-
 queryperformancecounter
*/
 }}}

 Which means that I would assume here we aren't getting a monotonic time at
 all and this warning is printed. Fortunately, this is harmless because we
 adjust the diff value back to 0 in this case and the scheduler will become
 active which is what we want.

 Considering that we can't guarantee monotonic time it seems, we should
 probably remove the `IF_BUG_ONCE()`... Or make it `log_info()` maybe...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24481 [Internal Services/Tor Sysadmin Team]: Please create email alias for Antonela

[Tor Bug Tracker & Wiki]

#24481: Please create email alias for Antonela
-+
 Reporter:  antonela |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by qbi):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24043 [Core Tor/Tor]: monotonic time test failure on 0.3.0.x

[Tor Bug Tracker & Wiki]

#24043: monotonic time test failure on 0.3.0.x
---+---
 Reporter:  weasel |  Owner:  (none)
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.12
 Severity:  Normal | Resolution:
 Keywords:  031-backport 030-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 Speaking of monotonic time failing, #23696 is getting that on Windows 7
 that is a monotonic get failure. Not sure if related but noting 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] #24164 [Core Tor/Tor]: errors I get after I installed 0.3.2.3 on my relay

[Tor Bug Tracker & Wiki]

#24164: errors I get after I installed 0.3.2.3 on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 You will _always_ see that warning with a kernel on 2.6.32, it doesn't
 have `get_random()` syscall but yet you are using a package or a tor
 compiled with its support.

 As long as you run tor not built for the system you are running it, you'll
 get these issues.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23710 [Core Tor/Tor]: sched: channel_more_to_flush() is probably looking at the wrong queue

[Tor Bug Tracker & Wiki]

#23710: sched: channel_more_to_flush() is probably looking at the wrong queue
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:  SponsorV
--+

Comment (by dgoulet):

 This one will get fixed if we ever merge #23709.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24484 [Core Tor/Tor]: free(NULL) always works (nowadays) so delete comment saying that it might not

[Tor Bug Tracker & Wiki]

#24484: free(NULL) always works (nowadays) so delete comment saying that it 
might
not
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 src/common/util.h has the following text in a comment:
 {{{
  * Unlike the free() function, tor_free() will still work on NULL
 pointers,
  * and it sets the pointer value to NULL after freeing it.
 }}}

 `free(NULL)` has been required to be a no-op since C89 at least.  Some
 pre-ANSI platforms might have had a libc `free()` that didn't allow a null
 pointer, but we mostly don't care about those.

 We should stop propagating this common misconception that `free(NULL)`
 might undefined on modern platforms.  We should remove that text from the
 comment and remove the conditional from the implementation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24484 [Core Tor/Tor]: free(NULL) always works (nowadays) so stop acting like it might not (was: free(NULL) always works (nowadays) so delete comment saying that it might not)

[Tor Bug Tracker & Wiki]

#24484: free(NULL) always works (nowadays) so stop acting like it might not
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| 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

[tor-bugs] #24485 [- Select a component]: Maybe found a Bad exit?

[Tor Bug Tracker & Wiki]

#24485: Maybe found a Bad exit?
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Liberia 197.231.221.211 with https://bugzilla.mozilla.org/ always returns
 a "Secure Connection Failed"

 (Sorry for putting it in the bugtracker, I don't know of any email service
 that allows Tor users and I don't think disposable mail service would be
 accepted in the bad-tor relays mail list)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24485 [- Select a component]: Maybe found a Bad exit?

[Tor Bug Tracker & Wiki]

#24485: Maybe found a Bad exit?
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dgoulet):

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


Comment:

 This is the IPredator relay, I doubt it is malicious as they've been
 running it for a while and some of us know them.

 However, I do get the error as well. I'll be contacting them soon. Thanks
 for the report.

 I've forwarded it to the `bad-rel...@lists.torproject.org` which is the
 right place to report next time. Cheers!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Okay, I have a fix, but I haven't found time to investigate _why_ it
 works: see branch `bug24367_032` in my public 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] #23524 [Core Tor/Tor]: Avoid crashing when we ask for running bridges, but UseBridges is 0

[Tor Bug Tracker & Wiki]

#23524: Avoid crashing when we ask for running bridges, but UseBridges is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  dos-resistance, review-group-26  |  Actual Points:  0.1
Parent ID:  #24392   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => merge_ready


Comment:

 Okay, I found the problem: the entrynode tests were depending on some
 global-state that some of the earlier tests were munging.  I haven't
 tracked down what global state exactly, though -- only enough to fix this.

 See my branch `bug24367_032`, based on yours.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 It likely always messed with the global state, it's just that we never
 checked that global state before.

 This looks fine, let's get it merged. It won't fix all of #24367, but at
 least it will make the remaining issues easier to find.

 I don't think we should backport: #23347 and #17750 make this bug have no
 effect in earlier versions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23524 [Core Tor/Tor]: Avoid crashing when we ask for running bridges, but UseBridges is 0

[Tor Bug Tracker & Wiki]

#23524: Avoid crashing when we ask for running bridges, but UseBridges is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  dos-resistance, review-group-26  |  Actual Points:  0.1
Parent ID:  #24392   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Ok, I think we can do the reviews of this in #24367.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I'm stuck in a maze of twisty little tickets, all being parents of each
 other, but: in proposed commit 690f646bf:

 {{{
 diff --git a/src/or/circuituse.c b/src/or/circuituse.c
 index aa0df95..8c9859b 100644
 --- a/src/or/circuituse.c
 +++ b/src/or/circuituse.c
 @@ -2084,7 +2084,7 @@ circuit_get_open_circ_or_launch(entry_connection_t
 *conn,
 "used client functionality lately" :
 "received a consensus with exits",
 options->UseBridges ? "bridges" : "entrynodes");
 -  } else if (!options->UseBridges || any_bridge_descriptors_known())
 {
 +  } else if (!options->UseBridges || num_bridges_usable() > 0) {
  log_fn(severity, LD_APP|LD_DIR,
 "Application request when we haven't %s. "
 "Optimistically trying directory fetches again.",
 }}}

 teor, did you check that you didn't break this functionality? We have
 broken it several times in the past and taken years to notice.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 (#14216 is the ticket where I fixed it last)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 arma]:
 > I'm stuck in a maze of twisty little tickets, all being parents of each
 other

 Maybe trac needs a tree view? :-)

 > , but: in proposed commit 690f646bf:
 >
 > {{{
 > diff --git a/src/or/circuituse.c b/src/or/circuituse.c
 > index aa0df95..8c9859b 100644
 > --- a/src/or/circuituse.c
 > +++ b/src/or/circuituse.c
 > @@ -2084,7 +2084,7 @@ circuit_get_open_circ_or_launch(entry_connection_t
 *conn,
 > "used client functionality lately" :
 > "received a consensus with exits",
 > options->UseBridges ? "bridges" : "entrynodes");
 > -  } else if (!options->UseBridges ||
 any_bridge_descriptors_known()) {
 > +  } else if (!options->UseBridges || num_bridges_usable() > 0) {
 >  log_fn(severity, LD_APP|LD_DIR,
 > "Application request when we haven't %s. "
 > "Optimistically trying directory fetches again.",
 > }}}
 >
 > teor, did you check that you didn't break this functionality? We have
 broken it several times in the past and taken years to notice.


 > (#14216 is the ticket where I fixed it last)

 #14216 was a partial fix. This ticket may be part of a more complete fix.

 This functionality has been easy to break *because* of this bug #24392,
 which goes back to commit eca2a30 in 0.2.0.3-alpha. Checking for cached
 bridge descriptors is definitely the wrong thing to do, because it can
 find the wrong type of bridges, and it can find non-running bridges. We
 need to check for live bridges instead. This fix needs to be applied
 regardless of any other bugs.

 Once it's fixed, we will deal with any remaining issues in #24367, which
 happened (or was exposed as a bug) due to  #23347 and #17750. I'll add a
 child ticket to #24367 so we test optimistic retries (that ticket is long
 enough and mentions too many issues as it is).

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

[tor-bugs] #24486 [Core Tor/Tor]: Retry bridge descriptor downloads on application activity

[Tor Bug Tracker & Wiki]

#24486: Retry bridge descriptor downloads on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core |Version:  Tor: 0.3.2.1-alpha
  Tor/Tor|   Keywords:  regression, tor-bridge-client,
 Severity:  Normal   |  s8-errors
Actual Points:   |  Parent ID:  #24367
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 If circuit_get_open_circ_or_launch() or its callers don't already retry
 bridge descriptor downloads, we should make them do so.

 A good way to do this is to:
 * modify the bridge state so we're using the bootstrapping schedule, then
 * reset the download statuses on all bridges.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24486 [Core Tor/Tor]: Retry bridge descriptor downloads on application activity

[Tor Bug Tracker & Wiki]

#24486: Retry bridge descriptor downloads on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:
  s8-errors  |
Parent ID:  #24367   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Reference: https://trac.torproject.org/projects/tor/ticket/24392#comment:7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24392 [Core Tor/Tor]: Ignore cached bridge descriptors until we check if they are running

[Tor Bug Tracker & Wiki]

#24392: Ignore cached bridge descriptors until we check if they are running
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:  0.3
  s8-errors  |
Parent ID:  #24367   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I opened #24486 to fix this issue. It's in a different part of the code to
 this change, so let's deal with it separately?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24486 [Core Tor/Tor]: Retry bridge descriptor downloads on application activity

[Tor Bug Tracker & Wiki]

#24486: Retry bridge descriptor downloads on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:
  s8-errors  |
Parent ID:  #24367   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 We want to handle this case better:
 {{{
 diff --git a/src/or/circuituse.c b/src/or/circuituse.c
 index aa0df95..8c9859b 100644
 --- a/src/or/circuituse.c
 +++ b/src/or/circuituse.c
 @@ -2084,7 +2084,7 @@ circuit_get_open_circ_or_launch(entry_connection_t
 *conn,
 "used client functionality lately" :
 "received a consensus with exits",
 options->UseBridges ? "bridges" : "entrynodes");
 -  } else if (!options->UseBridges || any_bridge_descriptors_known())
 {
 +  } else if (!options->UseBridges || num_bridges_usable() > 0) {
  log_fn(severity, LD_APP|LD_DIR,
 "Application request when we haven't %s. "
 "Optimistically trying directory fetches again.",
 }}}

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

Re: [tor-bugs] #24486 [Core Tor/Tor]: Retry bridge descriptor downloads on application activity

[Tor Bug Tracker & Wiki]

#24486: Retry bridge descriptor downloads on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:
  s8-errors  |
Parent ID:  #24367   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 It's not just about retrying bridge descriptor downloads. It's about being
 willing to use your bridges even when you previously marked them all as
 no-longer-running, if it's been a while and you want to try making
 circuits again, so long as you have a descriptor for them.

 In theory there is no reason you would need to first try fetching another
 descriptor, when the original problem was "my network didn't work for a
 while and that's why I marked all my bridges down".

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

Re: [tor-bugs] #24486 [Core Tor/Tor]: Mark all bridges as up on application activity (was: Retry bridge descriptor downloads on application activity)

[Tor Bug Tracker & Wiki]

#24486: Mark all bridges as up on application activity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-bridge-client,   |  Actual Points:
  s8-errors  |
Parent ID:  #24367   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Old description:

> If circuit_get_open_circ_or_launch() or its callers don't already retry
> bridge descriptor downloads, we should make them do so.
>
> A good way to do this is to:
> * modify the bridge state so we're using the bootstrapping schedule, then
> * reset the download statuses on all bridges.

New description:

 If circuit_get_open_circ_or_launch() or its callers don't already mark all
 bridges as up, we should make them do so.

 A good way to do this is to:
 * modify the bridge state so we're using the bootstrapping schedule, then
 * reset the download statuses on all bridges, and
 * reset the guard state on all the bridges (?).

--

Comment (by teor):

 Fixed the description and title.

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