Re: [tor-bugs] #25020 [Applications/Tor Browser]: There should be an easy way to detect the version of an installed bundle.

[Tor Bug Tracker & Wiki]

#25020: There should be an easy way to detect the version of an installed 
bundle.
+--
 Reporter:  yawning |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 I made a commit in branch `bug_25020` to add a `tbb_version.json` file:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25020&id=b2201eb2571c885f45bd6632e483310b169759dc

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

Re: [tor-bugs] #20395 [Metrics/Library]: Add capability to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: Add capability to handle large descriptor files
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  assigned => accepted


Comment:

 I'll grab this, as it's bugging users right now:
 https://lists.torproject.org/pipermail/metrics-
 team/2018-February/000667.html

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

Re: [tor-bugs] #25190 [Internal Services/Service - trac]: Why "Add to CC" is already set to "tor-dev" email address?

[Tor Bug Tracker & Wiki]

#25190: Why "Add to CC" is already set to "tor-dev" email address?
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * owner:  (none) => qbi
 * cc: tor-dev@… (removed)
 * component:  - Select a component => Internal Services/Service - trac


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

Re: [tor-bugs] #25189 [Webpages/Website]: Add some clear warning to download page that modifying 3 to 7|8 is a bad idea.

[Tor Bug Tracker & Wiki]

#25189: Add some clear warning to download page that modifying 3 to 7|8 is a bad
idea.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 This question is partly answered on the website here:
 https://www.torproject.org/docs/faq#Proxychains

 And a full answer is here:
 https://tor.stackexchange.com/a/105

 There is no Tor config option for extra hops.
 We already tell people not to modify the Tor source code.
 A specific warning about extra hops isn't needed, and might be counter-
 productive.

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 On the Skype ban and VPNs:
 https://via.hypothes.is/http://gulfnews.com/guides/tech/individuals-can-
 access-vpns-in-the-uae-with-caution-1.1872304

 So seems like your hypothesis is valid.

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

Re: [tor-bugs] #22612 [Applications/Tor Browser]: Provide a list sha256's for verified binary downloads from mirrors

[Tor Bug Tracker & Wiki]

#22612: Provide a list sha256's for verified binary downloads from mirrors
+--
 Reporter:  BenjaminCarr|  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R  |  Actual Points:
Parent ID:  #20892  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201802 => tbb-rbm,
   TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 To make some progress on #20892 in `bug_22612`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_22612&id=90891f83a0692dd7041c162538b417fcf85daf0f)
 in  my `tor-browser-build` repo is a patch that is adding a script to fix
 this bug up for 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] #25087 [Applications/Tor Browser]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


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

Re: [tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

[tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Open a Tor Browser with the "Standard" Security Setting and then go to
 http://ngp5wfw5z6ms3ynx.onion/fp and pass the tests.

 The "Accept-Encodinggzip, deflate" value is considered "unacceptable".

 I wonder whether that's an error from FPCentral.

 (BTW there should be a new component for FPCentral)

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

Re: [tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  assigned => new


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

Re: [tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Note: with https://fpcentral.tbb.torproject.org/fp one gets `gzip,
 deflate, br` as a value for `Accept-Encoding`.

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

Re: [tor-bugs] #20395 [Metrics/Library]: Add capability to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: Add capability to handle large descriptor files
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 I started making some improvements here. Here's my train of thought:
  1. Rather than reading the whole file to memory at the beginning, we
 could read it in chunks and start parsing as soon as we have seen a full
 descriptor. This sounds like a useful improvement, but it's actually very
 limited, at least on its own. Reading the 70M descriptor file I used for
 testing is actually done really fast. It's the parsing that takes long. As
 long as we need the full descriptor file contents in memory, we don't have
 to think about reading files in chunks. (See also 3. below.)
  2. Rather than parsing all descriptors contained in a given file into a
 list and then taking all parsed descriptors and throwing them into the
 `BlockingIterator`, we could just skip the list in the middle.
 The effect is that the time to first descriptor is reduced by a huge
 amount of time, whereas the time to last descriptor stays the same. I
 prepared a patch for this. The commit message contains more details.
  3. Rather than storing descriptor file contents in a `byte[]`, we could
 go through the file, read descriptor by descriptor, and store a `File`
 reference together with offset and length into the file. The effect would
 be that we're avoiding to keep the raw descriptor file contents in memory
 at all. We'd still keep parsed contents in memory. A possible downside is
 that the file must not be deleted or moved away while the application
 processes descriptors, which should be safe to require. Still, this is a
 larger change than 2. And it requires 1. That's why I postponed this.

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20395&id=ef9406c148a477720cdca67c6a2891ecd850f912
 commit ef9406c in my task-20395 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] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * reviewer:   => iwakeh


Comment:

 Okay, that leaves the Onionoo branch for review, which is probably
 iwakeh's part. Setting them as reviewer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25192 [Core Tor/Tor]: change of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumption

[Tor Bug Tracker & Wiki]

#25192: change of bandwidth accounting intveral from 4 to 24 hours results in
unreasonable memory consumption
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The recent change of relay bandwidth reporting has increased the related
 memory consumption on a mid-size relay from  about 200MB to about 1.2GB
 (i.e. a sixfold increase).  The memory dedicated to this function has
 become unreasonably large.

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

Re: [tor-bugs] #14006 [Core Tor/Tor]: Hidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."

[Tor Bug Tracker & Wiki]

#14006: Hidden service error: "We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits..."
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs circuit-management scaling  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by asn):

 Replying to [comment:18 dgoulet]:
 > Replying to [comment:15 arma]:
 > > Or oh hey, what about general-purpose circuits to upload new onion
 descriptors? We launch 6 or 8 of those at a time, and if there are several
 onion services being managed by this Tor... we can get to 32 right quick?
 >
 > Yes that is a problem. v2 uses 6 HSDirs so at 6 configured HS, you reach
 32 circuits quickly. v3 uses `hsdir_spread_store` which is currently 4
 meaning 8 HSDirs for every service. You configure 4 services and boom 32
 circuits are launched.
 >
 > But bumping `MaxClientCircuitsPending` is not really a good idea just
 for services.
 >
 > The thing is that once the services have bootstrapped that is descriptor
 uploaded, after that they will re-upload at random timings between each
 other. But that one time at startup, we need the service to upload in
 mass. And this is for tor to try as fast as possible to make the service
 reachable.
 >
 > So could we either:
 >
 > 1) Allow a burst at service startup if you have `num_services *
 num_hsdirs > MaxClientCircuitsPending`. I say service startup because one
 could do 10 `ADD_ONION` at once ;).
 >
 > 2) Have a special limit just for HS like `MaxHSCircuitsPending` and bump
 it to something bigger than 32.
 >
 > 3) Leave everything like this and after a while, once tor will be able
 to launch circuits, the descriptor will get uploaded. The operator just
 needs to deal with the delay.
 >
 > 4) 

 I think what I would prefer here is for Tor to rate-limit itself when
 building onion service circuits. Especially so when it has multiple onion
 services, but maybe even when it has only a single one. So instead of
 building all its onion circuits (IPs + hsdir circs) at once, it waits a
 randomized time (around a second?) before building each one.

 That will slightly delay the bootup of HSes, but not by too much, and it's
 better for the health of the network. Not sure if this will be a PITA to
 engineer tho.

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+---
 Reporter:  asn|  Owner:  asn
 Type:  defect | Status:
   |  needs_information
 Priority:  Immediate  |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Blocker| Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorV
---+---

Comment (by asn):

 Replying to [comment:71 cypherpunks]:
 > Replying to [comment:69 asn]:
 > > Hello, do you guys have any info logs for these issues by any chance?
 That would be really useful!
 >
 > {{{
 > [notice] Your system clock just jumped 3902 seconds forward; assuming
 established circuits no longer work.
 > [notice] Tried for 3915 seconds to get a connection to [scrubbed]:9878.
 Giving up. (waiting for rendezvous desc)
 > [notice] Tried for 3915 seconds to get a connection to [scrubbed]:9878.
 Giving up. (waiting for rendezvous desc)
 > [notice] Delaying directory fetches: No running bridges
 > }}}
 >

 Thanks for the logs. Unfortunately, they are not info level which kinda
 makes it harder.

 Some questions so that I understand the situation a bit better (too many
 cypherpunks in this ticket). Did you suspend your box for like an hour
 (3902 seconds?). Also, are you using bridges? I guess they were up at that
 time, and Tor was confused? Is this a ricochet setup?

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by mwolfe):

 Thanks for the link to gulfnews. I read that article. The new policy is
 that one must rent Botim from the TRA for $30 a month. My cousin is 93,
 knows how to use Skype, and does not want to learn Botim. I tried a free
 VPN, but it didn't work. And, if one uses a credit card for a VPN, the
 bank will report the credit card charge to the government.

 Since, many years ago, they blocked Tor for a few days then unblocked it,
 I tried again with 'My ISP blocks Tor' unchecked. Tor loaded. I tried to
 view a site. It had a hard time downloading. Speed was limited to 16K.
 Normally, the site downloads at 400K - 1M. After 5 minutes, it was still
 loading. I tried trac.torproject.org. Again, it started to load, but after
 5 minutes, was still loading with the Tor start page still visible.

 So I think the block is part of the block of Skype. Tor is (mis)identified
 as a way to do VOIP and so is choked, not blocked. I could read the New
 York Times, but today's paper would take until next week to load. One can
 still type over Skype, but not talk, so the anti-VOIP is based on
 identifying VOIP and choking the traffic, not blocking it.

 Fortunately, ofps4, meek, and Snowflake circumvent the choke.

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

Re: [tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 I think the reason is that preferences `network.http.accept-encoding` and
 `network.http.accept-encoding.secure` have different values, and which one
 is used depends on whether the website uses https or http.

 In the "acceptable" values we are assuming that fpcentral is accessed with
 https, but it is not the case with the .onion address.

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by Hello71):

 how exactly does one "enable weak symbols"? as far as I can tell, on both
 Mac and Linux, this process involves inserting `__attribute__((weak))` or
 `#pragma weak` in the actual source files that reference the symbol in
 question. even in cases of shared libraries, AIUI, if executable `a` NEEDS
 library `b.so`, and `a` has a weak symbol `f` with no default, and `b.so`
 has an undefined symbol `f`, then `a` will fail to start.

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-dos tor-hs performance  |  Actual Points:
Parent ID:  #14006  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by asn):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Pushing this to 034 since we lack a plan. Let's work on #14006 in 033 if
 we can.

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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion   |
Parent ID:  #24962   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Sorry for being pessimistic here, but do we think this is really worth the
 effort?

 IIUC this ticket is meant to protect tor2web clients who connect to single
 onions. Do we think there are actual tor2web clients who care to be
 protected? My understanding is that all tor2web clients are just
 `onion.to`-type of services and I bet they don't care about their
 anonymity. If an actual person went through all the effort to compile
 their Tor into tor2web mode and then configured their browser to use that,
 I bet they kinda know what's going on. What's the class of people we are
 trying to protect here, and is it worth going through all that effort?

 Or are we doing just that to demotivate attackers from camping into RPs?
 What kind of attackers would do that if they understood the above?

 Sorry if I'm misunderstanding something but the top-post is quite vague in
 its attacks description, so I'm not sure I'm up to date here. 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] #24269 [Core Tor/Tor]: Raise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directory

[Tor Bug Tracker & Wiki]

#24269: Raise a FATAL error if the user tried to combine v2 and prop224 hidden
service in same directory
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.3
 Reviewer:  |Sponsor:
+
Changes (by asn):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Pushing this to 034, I think we have more important prop224 stuff to fix.
 Please put it back in 033 if you disagree!

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * cc: alex_y_xu@… (added)


Comment:

 also, the following also fails to compile (on x86-64 Linux):

 a.c:
 {{{
 void a() __attribute__((weak));
 void b();

 int main() {
 a();
 b();
 return 0;
 }
 }}}

 b.c:

 {{{
 void a();

 void b() {
 a();
 }
 }}}

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

Re: [tor-bugs] #24909 [Core Tor/Tor]: Update dir-spec for new compression options

[Tor Bug Tracker & Wiki]

#24909: Update dir-spec for new compression options
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-dir, review-  |  Actual Points:
  group-31   |
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 It wasn't mentioned anywhere, no, but the current document looks good to
 me. Maybe add the HS section as an extra patch?

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

Re: [tor-bugs] #25188 [Core Tor/Tor]: Spec bug in formal definition of Document in dir-spec.txt

[Tor Bug Tracker & Wiki]

#25188: Spec bug in formal definition of Document in dir-spec.txt
--+
 Reporter:  witchof0x20   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Hm. I like this change, but it wouldn't match the current implementation.
 We should decide whether or not we like this better than the current
 behavior, and (if we want to change it) how to change it in a maximally
 privacy-friendly way.

 The current implementation is something more like 'a keyword may not be "
 -BEGIN"'.

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

Re: [tor-bugs] #22275 [Core Tor/Tor]: Update dir-spec.txt to reflect prop278.

[Tor Bug Tracker & Wiki]

#22275: Update dir-spec.txt to reflect prop278.
--+
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by ahf):

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


Comment:

 This is a duplicate of #24909.

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

Re: [tor-bugs] #24909 [Core Tor/Tor]: Update dir-spec for new compression options

[Tor Bug Tracker & Wiki]

#24909: Update dir-spec for new compression options
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-dir, review-  |  implemented
  group-31   |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged; added an extra paragraph as 9ddf104ae43c0a.  Thank you!

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by nickm):

 oh!  I hadn't known that a ffi-panic would be UB.  We should fix that too,
 if there's an easy way around 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] #25192 [Core Tor/Tor]: change of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumption

[Tor Bug Tracker & Wiki]

#25192: change of bandwidth accounting intveral from 4 to 24 hours results in
unreasonable memory consumption
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  regression, memory, performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => regression, memory, performance
 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #25192 [Core Tor/Tor]: change of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumption

[Tor Bug Tracker & Wiki]

#25192: change of bandwidth accounting intveral from 4 to 24 hours results in
unreasonable memory consumption
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  regression, memory, performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 The change was made in #23856.  It sure wasn't ''supposed'' to make memory
 consumption rise...

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

Re: [tor-bugs] #25192 [Core Tor/Tor]: change of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumption

[Tor Bug Tracker & Wiki]

#25192: change of bandwidth accounting intveral from 4 to 24 hours results in
unreasonable memory consumption
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  regression, memory, performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 How did you make this analysis?  The only memory allocations I can find
 based on the values that changed in #23856 (commit 8be50ca3ea90ac0) are
 ones that actually got slightly _smaller_ as a result of the change.

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

Re: [tor-bugs] #24940 [Core Tor/Tor]: Make authorities post authority_certificate to other authorities

[Tor Bug Tracker & Wiki]

#24940: Make authorities post authority_certificate to other authorities
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, tor-dirauth-offline,|  Actual Points:
  needs-proposal-maybe   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 But, certificates are included verbatim in votes, and as such are already
 uploaded to all the other authorities.  So this ''should'' work...

 (It's the part of the vote beginning with `dir-key-certificate-version`
 and ending with `dir-key-certification`.)

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

Re: [tor-bugs] #25191 [Applications/Quality Assurance and Testing]: FPCentral: Unacceptable "Accept-Encoder" value?

[Tor Bug Tracker & Wiki]

#25191: FPCentral: Unacceptable "Accept-Encoder" value?
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Thanks for that, maybe it should be mentioned in the TB#Hacking trac wiki?

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

Re: [tor-bugs] #24992 [Core Tor/Tor]: SingleOnion (and Tor2web?) connections may need better expiry, lots left open

[Tor Bug Tracker & Wiki]

#24992: SingleOnion (and Tor2web?) connections may need better expiry, lots left
open
+
 Reporter:  alecmuffett |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.9
 Severity:  Normal  | Resolution:
 Keywords:  single-onion, circuits  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by dgoulet):

 Considering 10 intro points (maximum for v2), a service is allowed to
 launch `((10 + 2) * 2)` (see rend_max_intro_circs_per_period()) intro
 points in a 300 seconds window (5 min).

 I expect that some of the intro points failed to establish properly (maybe
 due to the ongoing load on the network?) and then you hit the mark. Some
 INFO log would confirm that or help out greatly understand what is
 happening then?

 For the ~50 TIME_WAIT ... with that amount it is due to network problems
 in some ways, most likely to the relays you are connecting to? That is the
 FIN or final ACK got lost and the connection was stucked there. I would be
 surprised that tor never close() those as at least the other side would
 have?

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

Re: [tor-bugs] #25179 [Applications/Tor Browser]: identity leakage, resolution

[Tor Bug Tracker & Wiki]

#25179: identity leakage, resolution
--+--
 Reporter:  y2875095  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  tbb-team  |Sponsor:
--+--

Comment (by y2875095):

 > make all Tor Browser users as uniform as possible

 Yes, Tor users should be uniform: between each other and among users of
 "real" browsers.

 Until a certain time, the browser **asked to change the resolution** in
 order to "hide"... But more information for fingerprints won't "hide"
 anyone.

 I'm not sure about current or latests versions.

 > 2 Device and Hardware Characteristics ...
 > ... and prefer to either alter functionality to prevent exposing the
 most variable aspects of these characteristics ...

 Resolution and responsive CSS selectors may leak variable resolution

 > 1 Value Spoofing...
 > ... user's configuration details, devices, hardware ...

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

Re: [tor-bugs] #25179 [Applications/Tor Browser]: identity leakage, resolution

[Tor Bug Tracker & Wiki]

#25179: identity leakage, resolution
--+--
 Reporter:  y2875095  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  tbb-team  |Sponsor:
--+--
Changes (by y2875095):

 * status:  closed => reopened
 * resolution:  invalid =>
 * severity:  Normal => Critical


Comment:

 Up to 20 bits of entropy isn't "normal" leak, but severe:
 panopticlick.eff.org

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

Re: [tor-bugs] #14006 [Core Tor/Tor]: Hidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."

[Tor Bug Tracker & Wiki]

#14006: Hidden service error: "We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits..."
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs circuit-management scaling  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 Replying to [comment:20 asn]:
 > I think what I would prefer here is for Tor to rate-limit itself when
 building onion service circuits. Especially so when it has multiple onion
 services, but maybe even when it has only a single one. So instead of
 building all its onion circuits (IPs + hsdir circs) at once, it waits a
 randomized time (around a second?) before building each one.

 The problem with adding a random delay at startup is that it won't solve
 the "32 general purpose circuits are pending" issue. If those circuits a
 really stuck being built, the delay won't help much as they will all end
 up queued up and stuck at some point.

 A wise rate limit is probably what we want so we never go above that 32
 limit and thus no need for a cryptic warning that makes it that you just
 can't do anything but wait or/and panic.

 Now ok, looking a bit closely to the logs above, notice:

 {{{
 Jan 21 10:53:40.000 [warn] Giving up launching first hop of circuit to
 rendezvous point
 $9844B981A80B3E4B50897098E2D65167E6AEF127~$9844B981A80B3E4B50 at
 62.138.7.171 for service eb3w4t.
 }}}

 The above is a service trying to open a circuit to a rendezvous point...
 So I think the bigger issue here is that we have 32 circuits stuck in a
 non OPEN state and just never expire for some reasons? Or they do but we
 open 32 new ones very quickly and they get stalled again in a non OPEN
 state.

 My money is on the later due to the *amount* of suppressed log (see
 below). This looks to me like a service getting a ridiculous amount of
 rendezvous requests, the Guard is chocking so we keep reaching that 32
 limit.

 {{{
 Jan 21 10:37:42.000 [notice] We'd like to launch a circuit to handle a
 connection, but we already have 32 general-purpose client circuits
 pending. Waiting until some finish. [215959 similar message(s) suppressed
 in last 600 seconds]
 }}}

 Quick skim, I don't see anything in `circuit_expire_building()` that would
 make a circuit be ignored in the GUARD_WAIT state so they should in theory
 expire even though they are waiting for the guard to be usable?

 I'm getting indeed more and more convinced that we need a rate limit both
 client and service side. That is a bit like we do with DoS mitigation now
 (#24902) which is some per second rate with burst. Busy hidden service
 will suffer reachability but at least won't break the network. The point
 is that DoS mitigation will prevent as much as possible a client DDoS
 towards a single service and that service will by itself prevent to DDoS
 the network.

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

Re: [tor-bugs] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 I've added a fixup commit to the PR. Remember to autosquash when pulling
 :-)

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

Re: [tor-bugs] #25086 [Metrics/Relay Search]: make clear that bw is about adv. bw.

[Tor Bug Tracker & Wiki]

#25086: make clear that bw is about adv. bw.
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Fixed in 963d0f1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25193 [Core Tor/Tor]: dos: Avoid blacklisting Exit relays

[Tor Bug Tracker & Wiki]

#25193: dos: Avoid blacklisting Exit relays
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Very |  Milestone:  Tor: 0.3.3.x-final
  High   |
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-dos, tor-relay, 029-backport,
 Severity:  Normal   |  031-backport, 032-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 It is possible to do "tor-in-tor" meaning a tor client connection can exit
 the network and come back at a Guard node.

 And if this happens to be detected by the DoS subsystem, we'll blacklist
 the Exit relay for a while. That is *NOT* good.

 Now that we have #25183, we can lookup the inbound address to learn if we
 know it. And if we do, don't consider it a potential malicious client that
 we need to look at.

 That is one part of the solution, the second part is #2667 so we actually
 prevent reentry from Exit but that part won't be backported just yet (if
 ever).

 This work will be part of #24902 so once merge_ready, it will be merged
 into my branch `ticket24902_029_05`.

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

Re: [tor-bugs] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Fixed in 94c6afc

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by Hello71):

 (my point is that if you start fiddling with .c files, you get to play 52
 pickup on your own.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25194 [- Select a component]: Using a different search engine

[Tor Bug Tracker & Wiki]

#25194: Using a different search engine
--+
 Reporter:  kornm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I tried to use Google instead of Duckduckgo and it crashed or entered an
 instable mode. This happened with thw last version.

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

Re: [tor-bugs] #25194 [- Select a component]: Using a different search engine

[Tor Bug Tracker & Wiki]

#25194: Using a different search engine
--+---
 Reporter:  kornm |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information


Comment:

 > I tried to use Google instead of Duckduckgo and it crashed or entered an
 instable mode.

 What do you mean by "it"? Also I assume this happened in the Tor Browser?

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

Re: [tor-bugs] #25087 [Applications/Tor Browser]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #24465

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

Re: [tor-bugs] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host (was: 'missing pluggable transport ' error when trying to connect to Tor using snowflake)

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team snowflake|  Actual Points:
  TorBrowserTeam201802   |
Parent ID:  #24371   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  ux-team snowflake => ux-team snowflake TorBrowserTeam201802
 * owner:  brade => tbb-team
 * status:  needs_information => assigned
 * component:  Applications/Tor Launcher => Applications/Tor Browser


Comment:

 The issue seems to be reproducible per the info provided in #25087.

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * reviewer:  iwakeh =>


Comment:

 Relay Search is now assuming that nicknames are always present.

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by irl):

 * reviewer:   => iwakeh


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

Re: [tor-bugs] #23780 [Obfuscation/Snowflake]: Tor repeatedly tells me that "Your Guard is failing an extremely large amount of circuits" when using snowflake

[Tor Bug Tracker & Wiki]

#23780: Tor repeatedly tells me that "Your Guard is failing an extremely large
amount of circuits" when using snowflake
---+--
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * version:  Tor: 0.3.2.2-alpha => Tor: 0.3.2.9


Comment:

 Still happens.

 {{{
 Your Guard [scrubbed] is failing an extremely large amount of circuits.
 This could indicate a route manipulation attack, extreme network overload,
 or a bug. Success counts are 54/180. Use counts are 60/64. 169 circuits
 completed, 2 were unusable, 113 collapsed, and 7 timed out. For reference,
 your timeout cutoff is 60 seconds.
 }}}

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

Re: [tor-bugs] #24739 [Metrics/Bot]: Use an equal-area projection for TorAtlas bot

[Tor Bug Tracker & Wiki]

#24739: Use an equal-area projection for TorAtlas bot
-+--
 Reporter:  teor |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24717   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 teor: What did you think of the lambert projection?

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

Re: [tor-bugs] #24739 [Metrics/Bot]: Use an equal-area projection for TorAtlas bot

[Tor Bug Tracker & Wiki]

#24739: Use an equal-area projection for TorAtlas bot
-+--
 Reporter:  teor |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24717   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "LAMBERT.png" 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] #25193 [Core Tor/Tor]: dos: Avoid blacklisting Exit relays

[Tor Bug Tracker & Wiki]

#25193: dos: Avoid blacklisting Exit relays
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-relay, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Branch: `ticket25193_029_01`

 This is a very simple patch that does one check when a new client
 connection is seen. Notice that we don't need to do such a thing in the
 "close client connection" because the "is being tracked" flag is never set
 preventing us to decrement the connection counter.

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

Re: [tor-bugs] #24297 [Metrics/Bot]: Rename metrics-bot packages

[Tor Bug Tracker & Wiki]

#24297: Rename metrics-bot packages
-+
 Reporter:  karsten  |  Owner:  irl
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 Fixed in 6e664ba.

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

Re: [tor-bugs] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  reopened
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Thanks Iain for implementing that. Since this is only relevant for ~10 out
 of 8k relays,
 would you mind displaying it only if

 version != 2th word in platform string?

 to reduce the redundant information otherwise?

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

Re: [tor-bugs] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  reopened
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 And maybe lets rename it from just "Version" to "Tor Version"

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

Re: [tor-bugs] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  reopened
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 We've not hidden any other fields when they contain redundant information,
 only when the information doesn't exist, and in most cases we explicitly
 say that the information doesn't exist.

 Maybe though this shouldn't be another field and should instead just be
 "(X.X.X in consensus)" following the platform line if they are different.
 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] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  reopened
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 that is an even better idea!

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

Re: [tor-bugs] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Ok, I'll update it to do that instead.

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

Re: [tor-bugs] #25193 [Core Tor/Tor]: dos: Avoid blacklisting Exit relays

[Tor Bug Tracker & Wiki]

#25193: dos: Avoid blacklisting Exit relays
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-relay, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => accepted
 * reviewer:   => nickm
 * parent:   => #24902


Comment:

 Got a ACK from nickm on this so this has been merged into #24902 main
 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

[tor-bugs] #25195 [Metrics/Relay Search]: eliminate false-positives for red "This relay is running an outdated Tor version" banner

[Tor Bug Tracker & Wiki]

#25195: eliminate false-positives for red "This relay is running an outdated Tor
version" banner
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I came up with an idea to eliminate the false-positives when showing the
 red "This relay is running an outdated Tor version" banner.

 Lets only display that red banner if recommended_version is false and
 'version' and the version in 'platform' match, otherwise do not display
 it.



 example:
 https://atlas.torproject.org/#details/C894CC268A393927EABF4FE8D2C279A7153EE028

 sister ticket: #24974

 this is a nice-to-have feature

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31, SponsorV  |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => merge_ready


Comment:

 Ok at this point, #25193 and #25183 are merged into this branch. They've
 both been ACK by nickm.

 This imo closes the loop for this. Testing is ongoing on the 033 branch so
 then backport should be near.

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

Re: [tor-bugs] #25195 [Metrics/Relay Search]: eliminate false-positives for red "This relay is running an outdated Tor version" banner

[Tor Bug Tracker & Wiki]

#25195: eliminate false-positives for red "This relay is running an outdated Tor
version" banner
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 That's clever. The only case I can think of where there would be a false
 negative is when someone has updated from an outdated relay to another
 outdated version. I like 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] #25195 [Metrics/Relay Search]: eliminate false-positives for red "This relay is running an outdated Tor version" banner

[Tor Bug Tracker & Wiki]

#25195: eliminate false-positives for red "This relay is running an outdated Tor
version" banner
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Yes, I'm accepting the false-negatives for having nearly 0 false-
 positives.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31, SponsorV  |
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by nickm):

 merged that to master  again; still backportable.

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

Re: [tor-bugs] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team snowflake|  Actual Points:
  TorBrowserTeam201802   |
Parent ID:  #24371   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arlolra):

 * cc: arlolra (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] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion   |
Parent ID:  #24962   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:38 asn]:
 > Sorry for being pessimistic here, but do we think this is really worth
 the effort?
 >
 > IIUC this ticket is meant to protect tor2web clients who connect to
 single onions.

 No, it's meant to protect relays from knowing both client and service IP
 addresses. And it's meant to protect relays from being turned into single-
 hop proxies. It's like the single-hop exit ban.

 > Do we think there are actual tor2web clients who care to be protected?
 My understanding is that all tor2web clients are just `onion.to`-type of
 services and I bet they don't care about their anonymity.

 Some of them are automated hidden service scanners, too.

 > If an actual person went through all the effort to compile their Tor
 into tor2web mode and then configured their browser to use that, I bet
 they kinda know what's going on. What's the class of people we are trying
 to protect here, and is it worth going through all that effort?

 Relay operators from attacks or legal threats, and relays from DDoS or
 overload.

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

Re: [tor-bugs] #24739 [Metrics/Bot]: Use an equal-area projection for TorAtlas bot

[Tor Bug Tracker & Wiki]

#24739: Use an equal-area projection for TorAtlas bot
-+--
 Reporter:  teor |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24717   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 It looks fine. 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] #25037 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#25037: Add press clips to website
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * status:  needs_review => 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] #25193 [Core Tor/Tor]: dos: Avoid blacklisting Exit relays

[Tor Bug Tracker & Wiki]

#25193: dos: Avoid blacklisting Exit relays
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-dos, tor-relay, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Merged into master. Will be backported through #24902.

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

Re: [tor-bugs] #25183 [Core Tor/Tor]: Implement a way to tell if an IP address is a known relay

[Tor Bug Tracker & Wiki]

#25183: Implement a way to tell if an IP address is a known relay
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-dos, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Merged into master. Will be backported through #24902.

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

Re: [tor-bugs] #16883 [HTTPS Everywhere/HTTPS Everywhere: Chrome]: Manual rules are neither saved nor loaded in incognito mode

[Tor Bug Tracker & Wiki]

#16883: Manual rules are neither saved nor loaded in incognito mode
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  HTTPS Everywhere/HTTPS Everywhere:   |Version:
  Chrome |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * 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] #24739 [Metrics/Bot]: Use an equal-area projection for TorAtlas bot

[Tor Bug Tracker & Wiki]

#24739: Use an equal-area projection for TorAtlas bot
-+
 Reporter:  teor |  Owner:  irl
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #24717   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 Awesome!

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

Re: [tor-bugs] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me, other than the Rust test failures that are presumably
 due to #25127.  Hopefully those will resolve upon merge.

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 Potential patch in https://oniongit.eu/ahf/tor/merge_requests/6

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

Re: [tor-bugs] #24062 [Core Tor/Tor]: CPU profiling of Tor on Android device

[Tor Bug Tracker & Wiki]

#24062: CPU profiling of Tor on Android device
+
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  s8-perf, s8-201710  |  Actual Points:
Parent ID:  #24061  | Points:
 Reviewer:  |Sponsor:  Sponsor8
+
Changes (by ahf):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 This is a tracker bug. Moving forward to 0.3.4.

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

Re: [tor-bugs] #25049 [Webpages/Blog]: blog page RELOADED without my request and "Reply" Disappeared from existing comments

[Tor Bug Tracker & Wiki]

#25049: blog page RELOADED without my request and "Reply" Disappeared from 
existing
comments
+
 Reporter:  freedomseeker   |  Owner:  hiro
 Type:  defect  | Status:  closed
 Priority:  Low |  Milestone:
Component:  Webpages/Blog   |Version:
 Severity:  Minor   | Resolution:  fixed
 Keywords:  blog, reload, reply, disappearance  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by freedomseeker):

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


Comment:

 == Action Changed to "resolve as fixed"

 This problem has already been fixed. Thank you!

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

Re: [tor-bugs] #22423 [Metrics/Website]: Refactor R code to use modern R packages and methods

[Tor Bug Tracker & Wiki]

#22423: Refactor R code to use modern R packages and methods
+--
 Reporter:  johnbwilliams   |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Website |Version:
 Severity:  Minor   | Resolution:
 Keywords:  plot_networksize()  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 I started making changes and pushing them to
 [https://gitweb.torproject.org/metrics-web.git/log/ master]. No need to do
 the full review process before merging here, it's just presentation. I'll
 make more changes over the next few days.

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

Re: [tor-bugs] #24717 [Metrics/Bot]: Improve design of relay and bridge badges and map overlay

[Tor Bug Tracker & Wiki]

#24717: Improve design of relay and bridge badges and map overlay
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * cc: antonela (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] #24717 [Metrics/Bot]: Improve design of relay and bridge badges and map overlay

[Tor Bug Tracker & Wiki]

#24717: Improve design of relay and bridge badges and map overlay
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "new_design_impl.png" 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

[tor-bugs] #25196 [Metrics/Statistics]: Cut off recent dates from hidserv.csv

[Tor Bug Tracker & Wiki]

#25196: Cut off recent dates from hidserv.csv
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 In [https://gitweb.torproject.org/metrics-
 web.git/commit/?id=8831ecebd4ac186a798c2cb844289ed94318a6ed commit
 8831ece] we stopped cutting off data from CSV files. From the commit
 message: "When graphing data from CSV files it's not our job to make sure
 the data is stable enough to be graphed. That would mean that whoever uses
 our CSV files directly would have to make that sure by themselves. If data
 is too recent to be graphed, it shouldn't be included in the CSV files. As
 a side effect this makes the graphing process a little easier."

 Looks like we should cut off a day or two more from hidserv.csv. I'm going
 to attach a sample graph soon.

 Let's also create new tickets for similar findings.

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

Re: [tor-bugs] #25196 [Metrics/Statistics]: Cut off recent dates from hidserv.csv

[Tor Bug Tracker & Wiki]

#25196: Cut off recent dates from hidserv.csv
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * Attachment "hidserv-frac-reporting-2017-11-10-2018-02-09.png" 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] #25196 [Metrics/Statistics]: Cut off recent dates from hidserv.csv

[Tor Bug Tracker & Wiki]

#25196: Cut off recent dates from hidserv.csv
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 [[Image(hidserv-frac-reporting-2017-11-10-2018-02-09.png, width=700)]]

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

Re: [tor-bugs] #24717 [Metrics/Bot]: Improve design of relay and bridge badges and map overlay

[Tor Bug Tracker & Wiki]

#24717: Improve design of relay and bridge badges and map overlay
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I've mostly implemented the bridge and relay badges now. Attached above is
 a screenshot of how this looks on Twitter. I decided not to add the
 @TorAtlas because it doesn't make sense on Mastodon, and other accounts
 may be added in the future too. I did however add an onion, which will
 disappear if the nickname is long enough to clobber it.

 antonela: Any comments?

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

Re: [tor-bugs] #25196 [Metrics/Statistics]: Cut off recent dates from hidserv.csv

[Tor Bug Tracker & Wiki]

#25196: Cut off recent dates from hidserv.csv
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Hint: it's just the last date, February 9, where the fraction drops off.
 It's February 9 while I'm writing this comment.

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

Re: [tor-bugs] #25119 [Internal Services/Tor Sysadmin Team]: Please create new mailing list metrics-alerts@

[Tor Bug Tracker & Wiki]

#25119: Please create new mailing list metrics-alerts@
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by qbi):

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


Comment:

 I created the list. karsten got the data to access the admin interface.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25197 [Applications/Tor Browser]: Design document isn't precise about "Security" and "Privacy".

[Tor Bug Tracker & Wiki]

#25197: Design document isn't precise about "Security" and "Privacy".
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In Tor Browser, we have a "Security" Slider and various "Privacy"
 features. But these words are not so easily distinguished. Maybe we could
 think of a better words?

 In any case, we should defined the two concepts very clearly in the Design
 document, and we should make sure we don't mix them up. For example,
 section 2.1 is entitled "Security Requirements" but goes on to list what I
 would consider privacy properties and does not include the sort of
 security intended to be provided by the Slider.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25198 [Community/Tor Browser Manual]: User manual should explain Tor Browser features more

[Tor Bug Tracker & Wiki]

#25198: User manual should explain Tor Browser features more
--+---
 Reporter:  arthuredelstein   |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The user manual is excellent at describing how to use Tor Browser, but it
 could do with more explanation on the first page of the privacy and
 security features of Tor Browser, or how Tor Browser is different from
 other browsers.

 Things we could consider include:
 * A clearer definition of fingerprinting protectino
 * First-party isolation (in lay terms)
 * Disk avoidance
 * Hardening/sandboxing
 * Proxy enforcement

 All this should be kept super simple and brief! But right now the
 description is incomplete, I would say.

 Also, in the Security Slider section, we should explain why users would
 use it, what protections we are trying to provide, and what the tradeoffs
 are.

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

Re: [tor-bugs] #25198 [Community/Tor Browser Manual]: User manual should explain Tor Browser features more

[Tor Bug Tracker & Wiki]

#25198: User manual should explain Tor Browser features more
--+---
 Reporter:  arthuredelstein   |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Description changed by arthuredelstein:

Old description:

> The user manual is excellent at describing how to use Tor Browser, but it
> could do with more explanation on the first page of the privacy and
> security features of Tor Browser, or how Tor Browser is different from
> other browsers.
>
> Things we could consider include:
> * A clearer definition of fingerprinting protectino
> * First-party isolation (in lay terms)
> * Disk avoidance
> * Hardening/sandboxing
> * Proxy enforcement
>
> All this should be kept super simple and brief! But right now the
> description is incomplete, I would say.
>
> Also, in the Security Slider section, we should explain why users would
> use it, what protections we are trying to provide, and what the tradeoffs
> are.

New description:

 The user manual is excellent at describing how to use Tor Browser, but it
 could do with more explanation on the first page of the privacy and
 security features of Tor Browser, or how Tor Browser is different from
 other browsers.

 Things we could consider include:
 * A clearer definition of fingerprinting protection
 * First-party isolation (in lay terms)
 * Disk avoidance
 * Hardening/sandboxing
 * Proxy enforcement

 All this should be kept super simple and brief! But right now the
 description is incomplete, I would say.

 Also, in the Security Slider section, we should explain why users would
 use it, what protections we are trying to provide, and what the tradeoffs
 are.

--

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

Re: [tor-bugs] #24886 [Metrics/Bot]: Hide the HSDir, Guard, and maybe Exit flags on bridges on Metrics Bot

[Tor Bug Tracker & Wiki]

#24886: Hide the HSDir, Guard, and maybe Exit flags on bridges on Metrics Bot
-+
 Reporter:  teor |  Owner:  irl
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #24817   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 Fixed in d3df892.

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

Re: [tor-bugs] #24717 [Metrics/Bot]: Improve design of relay and bridge badges and map overlay

[Tor Bug Tracker & Wiki]

#24717: Improve design of relay and bridge badges and map overlay
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 It looks great!
 The white on black scheme is striking.
 I wonder if it's readable, it seems to be,

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

Re: [tor-bugs] #25197 [Applications/Tor Browser]: Design document isn't precise about "Security" and "Privacy".

[Tor Bug Tracker & Wiki]

#25197: Design document isn't precise about "Security" and "Privacy".
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 This ticket started when I saw tor browser devs saying things like "that's
 security, not privacy", which is a recipe for confusion in our modern "you
 have to choose between security and privacy" world.

 I think we have been using two notions:

 * Code security, or implementation security, which is about whether the
 browser can be exploited, which of course then could lead to
 deanonymization, identification, etc.

 * Privacy, which includes fingerprinting defense, but also proxy bypass
 defense, so in a sense it's all of the ways that things can go wrong for
 the user without implementation bugs.

 Our name "security slider" is strictly supposed to be the first one. That
 is, all settings of the security slider are intended to provide all of our
 privacy protections. That is, if a Tor Browser dev ever says "well you set
 your security slider to low so i figured i shouldn't enable that expensive
 tracking protection", then that is a mistake.

 (Arthur correctly points out that reducing surface area, which primarily
 aims to reduce exposure to implementation bugs aka exploits, can also
 improve things against fingerprinting and tracking and so on. That blurry
 line certainly confuses the issue, but it doesn't by itself mean we aren't
 talking about two different topics.)

 The suggestion in this ticket is to (a) have a section towards the top of
 the design doc explaining this distinction between the two goals, and then
 (b) make sure that the rest of the design doc uses these two goals
 correctly, i.e. doesn't confusingly switch between one word and the other.

 It's also worth brainstorming more intuitive terms for each of these
 goals. I think "code security" or "implementation security" is a pretty
 good one for the first, but the privacy one is broad enough that it's not
 obvious which term would be best. Let's not let a lack of the best term
 slow us down too much though. :)

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

Re: [tor-bugs] #24067 [Metrics/Bot]: Document the XML configuration

[Tor Bug Tracker & Wiki]

#24067: Document the XML configuration
-+
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 Fixed in 6e89a75.

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

Re: [tor-bugs] #25190 [Internal Services/Service - trac]: Why "Add to CC" is already set to "tor-dev" email address?

[Tor Bug Tracker & Wiki]

#25190: Why "Add to CC" is already set to "tor-dev" email address?
--+
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 I removed the email address from the cypherpunks account. It doesn't make
 sense to have an email address with this account.

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

Re: [tor-bugs] #24828 [Metrics/Relay Search]: Remove tabs when no data is available for graphs

[Tor Bug Tracker & Wiki]

#24828: Remove tabs when no data is available for graphs
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:  #24155| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Really this was a duplicate of #24829.

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

Re: [tor-bugs] #24831 [Metrics/Relay Search]: Consider providing more/less fine grained data for Realy Search graphs

[Tor Bug Tracker & Wiki]

#24831: Consider providing more/less fine grained data for Realy Search graphs
--+-
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:  #24155| Points:
 Reviewer:|Sponsor:
--+-
Changes (by irl):

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


Comment:

 Ok, waiting for a single history object in Onionoo before making changes
 here.

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

Re: [tor-bugs] #24155 [Metrics/Relay Search]: Prepare for increase in bandwidth statistics reporting interval from 4 to 24 hours

[Tor Bug Tracker & Wiki]

#24155: Prepare for increase in bandwidth statistics reporting interval from 4 
to
24 hours
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 With the Onionoo fixes in place, there is nothing that really needs to be
 done at the moment on Relay Search. There should be work in the near
 future to split out the weights graphs from the bandwidths and only show
 tabs for graphs that exist, but that is not directly related to this
 issue.

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

Re: [tor-bugs] #25197 [Applications/Tor Browser]: Design document isn't precise about "Security" and "Privacy".

[Tor Bug Tracker & Wiki]

#25197: Design document isn't precise about "Security" and "Privacy".
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Code security or implementation security are more precise, but I feel they
 have the drawback that they may not mean much to users who are not
 programmers themselves.

 Right now the Security Slider uses the terms "Standard", "Safer",
 "Safest". So we could call it the Safety Slider instead. (It's really a
 Safety-Usability tradeoff slider.) But again, Safety is not entirely
 distinct from Privacy.

 It might be good on the Security Slider itself, to say something like "All
 Privacy Protections are active at every level."

 Interestingly, I just noticed it says on the [https://tb-
 manual.torproject.org/en-US/security-slider.html Security Slider page] in
 the Tor Browser manual:

 > Tor Browser includes a “Security Slider” that lets you increase your
 security by disabling certain web features that can be used to attack your
 security and anonymity.

 Mentioning anonymity here seems to imply that dialing privacy protections
 is a purpose of the Slider, which is true in a technical sense but not our
 intention.

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

Re: [tor-bugs] #25198 [Community/Tor Browser Manual]: User manual should explain Tor Browser features more

[Tor Bug Tracker & Wiki]

#25198: User manual should explain Tor Browser features more
--+---
 Reporter:  arthuredelstein   |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25021| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arthuredelstein):

 * parent:   => #25021


Comment:

 Adding a parent in case we want to address this issue in upcoming
 revisions to the document.

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

Re: [tor-bugs] #25197 [Applications/Tor Browser]: Design document isn't precise about "Security" and "Privacy".

[Tor Bug Tracker & Wiki]

#25197: Design document isn't precise about "Security" and "Privacy".
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-spec  |  Actual Points:
Parent ID:  #25021| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * parent:   => #25021


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

Re: [tor-bugs] #25198 [Community/Tor Browser Manual]: User manual should explain Tor Browser features more

[Tor Bug Tracker & Wiki]

#25198: User manual should explain Tor Browser features more
--+---
 Reporter:  arthuredelstein   |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arthuredelstein):

 * parent:  #25021 =>


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