Re: [tor-bugs] #22653 [Core Tor/Tor]: upgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to build circuits

[Tor Bug Tracker & Wiki]

#22653: upgrading Tor-0.2.9.10 to Tor-0.3.0.8 or Tor-0.3.1.3_alpha fails to 
build
circuits
-+-
 Reporter:  t0r  |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard tor-bridge obfs4proxy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by t0r):

 * priority:  Medium => High
 * keywords:  tor-guard => tor-guard tor-bridge obfs4proxy


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

Re: [tor-bugs] #22660 [Core Tor/Tor]: Guard against stack smashing attacks in tor

[Tor Bug Tracker & Wiki]

#22660: Guard against stack smashing attacks in tor
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hardening, security  |  Actual Points:
  029-backport 030-backport 031-backport |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:2 nickm]:
 > We already have -fstack-protector-all, but I guess it doesn't include
 this?
 >
 > Also, we should never be installed SUID, yeah?

 tor relays often launch tor as root, but I don't know of any common setups
 that allow a local unprivileged user to influence its torrc.

 I'd be more worried about network attacks based on research like this: the
 researchers couldn't rule them out.

 > When I try to build with this, I get many `/usr/bin/ld: warning: -z
 noexecheap ignored.` warnings.  I don't know if that's something I should
 be concerned about.

 I wonder if your linker supports noexecheap?

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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+--
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [comment:13 isis]:
 > Replying to [comment:12 arma]:
 > > A) You could do it by specifying "PublishServerDescriptor v3" if you
 wanted.
 >
 > This one sounds like a bug?

 That "feature" (in quotes) is around from the old days, when we were
 writing an overlay network and people wanted to put the pieces together as
 they saw fit -- you run a relay, and you publish to wherever you want to
 be collecting your relay descriptors.

 I could see taking it out, in that "closing a door of what Tor can be"
 sort of way, but also I don't see any harm in leaving it in.

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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+--
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * 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] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+---
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+---

Comment (by isis):

 Replying to [comment:12 arma]:
 > A) You could do it by specifying "PublishServerDescriptor v3" if you
 wanted.

 This one sounds like a bug?

 > B) I could take your bridge descriptor and upload it to moria1. Then
 moria1 would include it in its v3 vote, and the other dir auths would
 learn about it and fetch the descriptor from moria1, and then it would be
 a relay.

 This is more convincing.

 > Not the end of the world, but it seems cleaner for bridges to say what
 they wanted to be when they're writing it up and signing it.

 Yep, this makes sense and shouldn't be too hard, and I see it's already
 marked as a good intro ticket. :)

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

Re: [tor-bugs] #22277 [Core Tor/Tor]: Make sure RSOS is documented in specifications

[Tor Bug Tracker & Wiki]

#22277: Make sure RSOS is documented in specifications
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, rsos, single-onion  |  Actual Points:
Parent ID:  #21554   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => merge_ready


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

Re: [tor-bugs] #22277 [Core Tor/Tor]: Make sure RSOS is documented in specifications

[Tor Bug Tracker & Wiki]

#22277: Make sure RSOS is documented in specifications
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, rsos, single-onion  |  Actual Points:
Parent ID:  #21554   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   => prop224, rsos, single-onion


Comment:

 There are no dir-spec changes for single onion services.

 prop#224 contains an onion service descriptor entry for single onion
 services in the encrypted section, that belongs in rend-spec. Let's
 explain single onion services there when we merge prop#224 into rend-spec:

 Single onion services connect directly to introduction and rendezvous
 points. They use a 3-hop path to connect to HSDirs, to avoid malicious
 HSDirs rejecting descriptors by service IP address.

 We could even add this to rend-spec now if we wanted to, but that would
 duplicate the info once prop224 merges.

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

Re: [tor-bugs] #22277 [Core Tor/Tor]: Make sure RSOS is documented in specifications

[Tor Bug Tracker & Wiki]

#22277: Make sure RSOS is documented in specifications
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21554| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  teor =>


Comment:

 Teor is pretty sure that there aren't any undocumented changes from
 prop260. All that's left to do is scan through the proposal and confirm,
 then mark the proposal closed.

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

Re: [tor-bugs] #22502 [Core Tor/Tor]: Investigate Zstandard decompression error

[Tor Bug Tracker & Wiki]

#22502: Investigate Zstandard decompression error
-+
 Reporter:  ahf  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor4
-+
Changes (by nickm):

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


Comment:

 Merged `bug22502_redux_031`.

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

Re: [tor-bugs] #22670 [Core Tor/Tor]: Clean up warning behavior of decompression code in connection_dir_client_reached_eof()

[Tor Bug Tracker & Wiki]

#22670: Clean up warning behavior of decompression code in
connection_dir_client_reached_eof()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .2
Parent ID:| Points:  .2
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * parent:  #22502 =>


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

Re: [tor-bugs] #22669 [Core Tor/Tor]: When sending cached_dir_t objects compressed with zlib, do not claim zstd compression.

[Tor Bug Tracker & Wiki]

#22669: When sending cached_dir_t objects compressed with zlib, do not claim 
zstd
compression.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #22502| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #22672 [Core Tor/Tor]: Defensive programming: ensure no infinite COMPRESS_OK loops

[Tor Bug Tracker & Wiki]

#22672: Defensive programming: ensure no infinite COMPRESS_OK loops
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merging!

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

Re: [tor-bugs] #22629 [Core Tor/Tor]: tor_compress_impl() ignores trailing input garbage when decompressing

[Tor Bug Tracker & Wiki]

#22629: tor_compress_impl() ignores trailing input garbage when decompressing
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #22502| Points:  0.2
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

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


Comment:

 Merged

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

Re: [tor-bugs] #16844 [Core Tor/Tor]: Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting

[Tor Bug Tracker & Wiki]

#16844: Slow clients can't bootstrap because they expire their consensus fetch 
but
then receive all the bytes from it anyway, making them expire their next
fetch, putting them in a terrible loop
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, low-bandwidth,   |  Actual Points:
  sponsor4, bootstrap|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:  tor-client, low-bandwidth, sponsor4 => tor-client, low-
 bandwidth, sponsor4, bootstrap


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

Re: [tor-bugs] #8786 [Core Tor/Tor]: Add extra-info line that tracks the number of consensus downloads over each pluggable transport

[Tor Bug Tracker & Wiki]

#8786: Add extra-info line that tracks the number of consensus downloads over 
each
pluggable transport
-+-
 Reporter:  asn  |  Owner:  karsten
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  pt, tor-bridge, metrics privcount-   |  Actual Points:
  maybe needs-design |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by teor):

 * keywords:  pt, tor-bridge, metrics privcount needs-design => pt, tor-
 bridge, metrics privcount-maybe needs-design


Comment:

 PrivCount doesn't do bridge or PT statistics yet, nor does it do consensus
 downloads yet.

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

Re: [tor-bugs] #13194 [Core Tor/Tor]: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

[Tor Bug Tracker & Wiki]

#13194: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, needs-design  |  Actual Points:
  privcount-maybe metrics performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Tracking the related PrivCount work here:
 Rend: https://github.com/privcount/privcount/issues/344

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

Re: [tor-bugs] #13195 [Core Tor/Tor]: Collect aggregate stats around hidden service descriptor publishes and fetches

[Tor Bug Tracker & Wiki]

#13195: Collect aggregate stats around hidden service descriptor publishes and
fetches
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs metrics needs- |  Actual Points:
  design privcount-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Tracking the related PrivCount work here:
 HSDir Store: https://github.com/privcount/privcount/issues/336
 HSDir Fetch: https://github.com/privcount/privcount/issues/337

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

Re: [tor-bugs] #13792 [Core Tor/Tor]: HS statistics for private tor network to gather info on services, clients and relays

[Tor Bug Tracker & Wiki]

#13792: HS statistics for private tor network to gather info on services, 
clients
and relays
-+-
 Reporter:  dgoulet  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, performance, metrics,|  Actual Points:
  privcount-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Tracking the related PrivCount work here:
 HSDir Fetch: https://github.com/privcount/privcount/issues/337
 Intro Service: https://github.com/privcount/privcount/issues/342
 Intro Client: https://github.com/privcount/privcount/issues/343
 Rend: https://github.com/privcount/privcount/issues/344

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

Re: [tor-bugs] #13466 [Core Tor/Tor]: Collect aggregate stats of ntor-using hidden service interactions vs tap-using interactions

[Tor Bug Tracker & Wiki]

#13466: Collect aggregate stats of ntor-using hidden service interactions vs 
tap-
using interactions
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, privcount-maybe   |  Actual Points:
  needs-design metrics   |
Parent ID:  #13195   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Tracking the related PrivCount work here:
 Intro Service: https://github.com/privcount/privcount/issues/342
 Intro Client: https://github.com/privcount/privcount/issues/343
 Rend: https://github.com/privcount/privcount/issues/344

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

Re: [tor-bugs] #15272 [Core Tor/Tor]: Think of more research questions that we can answer with statistics

[Tor Bug Tracker & Wiki]

#15272: Think of more research questions that we can answer with statistics
--+
 Reporter:  asn   |  Owner:
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7
 Severity:  Normal| Resolution:
 Keywords:  research, privcount-maybe tor-hs  |  Actual Points:
Parent ID:| Points:
  |  medium/large
 Reviewer:|Sponsor:  SponsorR-
  |  can
--+

Comment (by teor):

 Tracking the related PrivCount work here:
 https://github.com/privcount/privcount/issues/336
 https://github.com/privcount/privcount/issues/337

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

Re: [tor-bugs] #22422 [Core Tor/Tor]: Add noise to PaddingStatistics

[Tor Bug Tracker & Wiki]

#22422: Add noise to PaddingStatistics
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Also, feel free to ping me by email, for some reason the spam filter is
 eating your replies to this ticket.

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

Re: [tor-bugs] #22422 [Core Tor/Tor]: Add noise to PaddingStatistics

[Tor Bug Tracker & Wiki]

#22422: Add noise to PaddingStatistics
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: robgjansen, amj703 (added)
 * keywords:   => privcount


Comment:

 Replying to [comment:6 mikeperry]:
 > To know how many padding cells to expect for a client, we need
 information on how long an average client's connection lasts,

 Using closed connections to count clients (and also not quite the time
 interval you're after):
 "Tor has about 700 thousand unique clients connecting to the network
 during an average 10-minute interval."

 > how often they make connections during a 24 hour interval,

 "Compared to Tor’s own estimate of about 1.75 million clients per day in
 May 2016..., this suggests that the client population turns over about 2.5
 times a day."

 > and what percentage of the time those connections are idle. Do we have
 this data?

 "Somewhat surprisingly, we found that about 130 thousand clients have in-
 active circuits during an average 10 minutes."

 (That is, closed connections with no circuits with more than 8 cells
 either sent or received.)

 > Also, is there a good example of where we add noise in a way
 successfully calculates how to hide a single client's activity? It would
 be helpful to have a reference to work off of.

 Pages 7-8 of the PrivCount paper give the theory behind differential
 noise.
 I am not sure where to find anything similar in the tor code.
 When we add noise, we've done it inconsistently and arbitrarily in the
 past.

 Perhaps Rob or Aaron can help?

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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+---
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 A) You could do it by specifying "PublishServerDescriptor v3" if you
 wanted.

 B) I could take your bridge descriptor and upload it to moria1. Then
 moria1 would include it in its v3 vote, and the other dir auths would
 learn about it and fetch the descriptor from moria1, and then it would be
 a relay.

 Not the end of the world, but it seems cleaner for bridges to say what
 they wanted to be when they're writing it up and signing 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] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+---
 Reporter:  arma   |  Owner:
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+---
Changes (by isis):

 * type:  defect => enhancement


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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+---
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+---
Changes (by isis):

 * status:  new => needs_information


Comment:

 What is the path that gets taken when the operator specifies "BridgeRelay
 1" in their torrc that could lead to the descriptor being uploaded to a
 relay DirAuth?  Is this possible?

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

Re: [tor-bugs] #22679 [Core Tor/Stem]: Tor and stem library : non consistent error message with wrong password

[Tor Bug Tracker & Wiki]

#22679: Tor and stem library : non consistent error message with wrong password
---+
 Reporter:  daftaupe   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cacahuatl):

 From my poking at this, there seems to be some racey code in the handling
 of the control socket connection.

 For example stem is sending a `SETEVENTS` command straight after
 `AUTHENTICATE` without waiting for `AUTHENTICATE` to return a success or
 fail (it of course fails with the wrong password), then Tor kills the
 control connection, as per the spec, and stem seems to try and use the
 closed socket again if it's unlucky on timing.

 I was able to reproduce some of the results from their code but only when
 running on a less powerful CPU, with a more powerful one I got a 100%
 success rate.

 I also found that running `authenticate()` in a tight loop can actually
 entirely lock up the python process. (`stem-1.5.4` with both Tor
 `0.2.9.11` and `0.3.0.8`).

 e.g.

 {{{
 #!/usr/bin/env python2
 from stem.control import Controller
 controller = Controller.from_port()
 for i in range(0,1000):
 try:
 controller.authenticate(password = "wrong")
 except Exception as e:
 print "%s" % e
 }}}

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

Re: [tor-bugs] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, ed25519, review-|  Actual Points:
  group-18   |
Parent ID:  #21888   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorR-can
-+-
Changes (by isis):

 * cc: isis (added)


Comment:

 Hi, I know this is a bikesheddy topic… so I'm sorry for adding to it. (And
 also for giving written input very late in the process.)

 However it would not only be safer, but also faster to use Decaf point
 compression as the wire format and key format. We'd need to create code to
 do Schnorr-style signatures within the Decaf group, but this would be
 trivial.  [https://github.com/isislovecruft/tor22006 Here's some code I
 wrote] to benchmark the key validation in the current design, versus if we
 used Decaf instead:

 {{{
 extern crate core;

 #[cfg(all(test, feature = "bench"))]
 extern crate test;

 #[cfg(test)]
 extern crate rand;

 extern crate curve25519_dalek;

 use curve25519_dalek::constants;

 use curve25519_dalek::curve::CompressedEdwardsY;
 use curve25519_dalek::curve::ExtendedPoint;
 use curve25519_dalek::curve::Identity;
 use curve25519_dalek::curve::IsIdentity;

 use curve25519_dalek::decaf::CompressedDecaf;
 use curve25519_dalek::decaf::DecafPoint;


 // The public key for an ed25519 scheme is a compressed edwards point (the
 // Y-coordinate and the sign of X).

 pub fn mult_by_cofactor_and_validate(key: &CompressedEdwardsY) ->
 Option {
 // decompression of Y in any sane curve25519 library should check
 validation
 // by computing:
 //
 //Z ← fe(1)
 //u ← Y² - Z
 //v ← dY² + Z
 //check ← sqrt(u/v)
 //
 // If `v` is nonzero and `check` is okay (meaning that `u/v` is
 square),
 // then the point is valid.
 let p: Option = key.decompress();
 let q: ExtendedPoint;

 match p.is_some() {
 true  => q = p.unwrap().mult_by_cofactor() * constants::l,
 false => return None, // the point was invalid
 }

 // We also need to check that the point is not the identity (the
 // identity point X:Y:Z:T == 0:1:1:0 is a valid point, but we
 // shouldn't accept it as a key)
 match q.is_identity() {
 true  => return None, // point * l * cofactor the identity
 false => return Some(q),
 }
 }

 // Decaf decompression ensures both that the point is a valid point on
 // the curve and that it is within a prime-order group.
 pub fn decaf_decompress(key: &CompressedDecaf) -> Option {
 let p: Option;

 // The constant-time equality check for a decaf point is only
 // defined (in dalek) for the compressed version, and works by byte
 // comparison.
 match *key == CompressedDecaf::identity() {
 true  => return None, // the point was the identity
 false => p = key.decompress(),
 }

 match p.is_some() {
 true  => return p,
 false => return None, // invalid decaf point
 }
 }

 #[cfg(all(test, feature = "bench"))]
 mod bench {
 use super::*;

 use test::Bencher;
 use rand::OsRng;

 use curve25519_dalek::scalar::Scalar;

 #[bench]
 fn current_design(b: &mut Bencher) {
 let mut csprng: OsRng = OsRng::new().unwrap();
 let a: Scalar = Scalar::random(&mut csprng);
 let p: ExtendedPoint = &a * &constants::ED25519_BASEPOINT;
 let key: CompressedEdwardsY = p.compress_edwards();

 b.iter(| | mult_by_cofactor_and_validate(&key) )
 }

 #[bench]
 fn with_decaf_instead(b: &mut Bencher) {
 let mut csprng: OsRng = OsRng::new().unwrap();
 let p: DecafPoint = DecafPoint::random(&mut csprng);
 let key: CompressedDecaf = p.compress();

 b.iter(| | decaf_decompress(&key) )
 }
 }
 }}}

 The results are:

 {{{
 ∃!isisⒶwintermute:(master *)~/code/rust/tor22006 ∴ cargo bench
 --features="bench"
Compiling tor22006 v0.1.0 (file:///home/isis/code/rust/tor22006)
  Finished release [optimized] target(s) in 1.2 secs
 Running target/release/deps/tor22006-4d45ae24d96b617f

 running 2 tests
 test bench::current_design ... bench: 114,570 ns/iter (+/- 30,244)
 test bench::with_

Re: [tor-bugs] #22679 [Core Tor/Stem]: Tor and stem library : non consistent error message with wrong password

[Tor Bug Tracker & Wiki]

#22679: Tor and stem library : non consistent error message with wrong password
---+
 Reporter:  daftaupe   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Interesting find, thanks for reporting this! Repros for me just fine.
 Fiddled with telnet but tor's behaving itself so certainly looks to be a
 stem issue. I'll dig into this more tomorrow.

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

Re: [tor-bugs] #21171 [Metrics/Onionoo]: write a test for NodeDetailsStatusUpdater

[Tor Bug Tracker & Wiki]

#21171: write a test for NodeDetailsStatusUpdater
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by kiki201):

 Replying to [comment:4 iwakeh]:
 > Replying to [comment:3 kiki201]:
 > > Do I need to create mock objects for ReverseDomainNameResolver,
 LookupService, Descriptor and other classes?
 >
 > Only, if you need these to test the fix supplied in #20994.
 >
 > >
 > > Do I need to use reflection to test private methods and do I even need
 to test private methods?
 >
 > Same here, if it provides a shortcut and turns out to be easier you can
 use reflection, no must.
 >
 > As the description of this ticket is quite terse, I try to give some
 more details:
 >
 > Ticket #20994#comment:5 explains the bug, its fix, and supplies the
 fixed code, but no test.
 > So, the aim is to device a test that fails on code before
 
[https://gitweb.torproject.org/onionoo.git/commit/?id=f737faa109ab527a5bfa2ded72bffd1d3063f2fc
 this commit] (and because of the reason described in #20994#comment:5).
 > There are no requirements of having to use mock objects or reflection,
 but they are fine to use for making the test code simpler.
 > This might turn out tricky, just feel free to experiment.

 I didn't understand completely what the test is supposed to do. I am
 supposed to write a test that fails on the code before the given commit.
 Does the test checks if the first_seen timestamp on bridges is not
 "1970-01-01 00:00:00" ? Or does the test have more to do with the lines
 that were commented out in #20994? Also, since this is on an old version
 of the code, I'm going to have to checkout in this branch. Is this
 correct?

 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] #22679 [Core Tor/Stem]: Tor and stem library : non consistent error message with wrong password

[Tor Bug Tracker & Wiki]

#22679: Tor and stem library : non consistent error message with wrong password
---+
 Reporter:  daftaupe   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * cc: arma (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] #22679 [Core Tor/Stem]: Tor and stem library : non consistent error message with wrong password

[Tor Bug Tracker & Wiki]

#22679: Tor and stem library : non consistent error message with wrong password
---+
 Reporter:  daftaupe   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Hello,

 I'm writing a little program trying to connect to Tor (v0.2.9.10) using
 the stem library (v1.5.4).

 The problem is that when I'm trying to use a wrong password on purpose I
 don't get a consistent return. I'm joining both the script I'm using and
 the log that I'm getting when starting the script.

 I start to believe there's a bug somewhere as the code can't really much
 simpler.

 I've taken inspiration from this page :
 [https://stem.torproject.org/api/control.html
 https://stem.torproject.org/api/control.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] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, ed25519, review-|  Actual Points:
  group-18   |
Parent ID:  #21888   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorR-can
-+-

Comment (by isis):

 Hi, I know this is a bikesheddy topic… so I'm sorry for adding to it.

 However it would not only be safer, but also faster to use Decaf point
 compression as the wire format and key format. We'd need to create code to
 do Schnorr-style signatures within the Decaf group, but this would be
 trivial. [https://github.com/isislovecruft/tor22006 Here's some code I
 wrote] to benchmark the key validation in the current design, versus if we
 used Decaf instead:

 {{{
 extern crate core;

 #[cfg(all(test, feature = "bench"))]
 extern crate test;

 #[cfg(test)]
 extern crate rand;

 extern crate curve25519_dalek;

 use curve25519_dalek::curve::CompressedEdwardsY;
 use curve25519_dalek::curve::ExtendedPoint;
 use curve25519_dalek::curve::Identity;

 use curve25519_dalek::decaf::CompressedDecaf;
 use curve25519_dalek::decaf::DecafPoint;


 // The public key for an ed25519 scheme is a compressed edwards point (the
 // Y-coordinate and the sign of X).

 pub fn mult_by_cofactor_and_validate(key: &CompressedEdwardsY) ->
 Option {
 // decompression of Y in any sane curve25519 library should check
 validation
 // by computing:
 //
 //Z ← fe(1)
 //u ← Y² - Z
 //v ← dY² + Z
 //check ← sqrt(u/v)
 //
 // If `v` is nonzero and `check` is okay (meaning that `u/v` is
 square),
 // then the point is valid.
 let p: Option = key.decompress();
 let q: ExtendedPoint;

 match p.is_some() {
 true  => q = p.unwrap().mult_by_cofactor(),
 false => return None, // the point was invalid
 }

 // We also need to check that the point is not the identity (the
 // identity point X:Y:Z:T == 0:1:1:0 is a valid point, but we
 // shouldn't accept it as a key)
 match q.is_small_order() {
 true  => return None, // the point was of small order
 false => return Some(q),
 }
 }

 // Decaf decompression ensures both that the point is a valid point on
 // the curve and that it is within a prime-order group.
 pub fn decaf_decompress(key: &CompressedDecaf) -> Option {
 let p: Option;

 // The constant-time equality check for a decaf point is only
 // defined for the compressed version, and works by byte comparison.
 match *key == CompressedDecaf::identity() {
 true  => return None, // the point was the identity
 false => p = key.decompress(),
 }

 match p.is_some() {
 true  => return p,
 false => return None, // invalid decaf point
 }
 }

 #[cfg(all(test, feature = "bench"))]
 mod bench {
 use super::*;

 use test::Bencher;
 use rand::OsRng;

 use curve25519_dalek::constants;
 use curve25519_dalek::scalar::Scalar;

 #[bench]
 fn current_design(b: &mut Bencher) {
 let mut csprng: OsRng = OsRng::new().unwrap();
 let a: Scalar = Scalar::random(&mut csprng);
 let p: ExtendedPoint = &a * &constants::ED25519_BASEPOINT;
 let key: CompressedEdwardsY = p.compress_edwards();

 b.iter(| | mult_by_cofactor_and_validate(&key) )
 }

 #[bench]
 fn with_decaf_instead(b: &mut Bencher) {
 let mut csprng: OsRng = OsRng::new().unwrap();
 let p: DecafPoint = DecafPoint::random(&mut csprng);
 let key: CompressedDecaf = p.compress();

 b.iter(| | decaf_decompress(&key) )
 }
 }
 }}}

 The results are:

 {{{
 ∃!isisⒶwintermute:(master #)~/code/rust/tor22006 ∴ cargo bench
 --features="bench"
Compiling tor22006 v0.1.0 (file:///home/isis/code/rust/tor22006)
Finished release [optimized] target(s) in 1.4 secs
 Running target/release/deps/tor22006-4d45ae24d96b617f

 running 2 tests
 test bench::current_design ... bench:  21,857 ns/iter (+/- 2,998)
 test bench::with_decaf_instead ... bench:   7,770 ns/iter (+/- 1,238)

 test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out
 }}}

 So you'd be getting ''better'' safety guaran

Re: [tor-bugs] #22677 [Core Tor/Tor]: Document that Sandbox 1 requires linux and seccomp2. (was: better Sandbox manpage documentation)

[Tor Bug Tracker & Wiki]

#22677: Document that Sandbox 1 requires linux and seccomp2.
---+
 Reporter:  cypherpunks|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  documentation trivial  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.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] #22675 [Applications/Tor Browser]: Tor Browser 7.0.1 opens at 1000x500 resolution

[Tor Bug Tracker & Wiki]

#22675: Tor Browser 7.0.1 opens at 1000x500 resolution
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * keywords:  tor browser, linux, screen size, fingerprinting, 1000x500,
 1000x600 => ff52-esr
 * status:  new => needs_information


Comment:

 What is your screen resolution on Tails?

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

Re: [tor-bugs] #16822 [Core Tor/Tor]: make certificate lifetime accessible through Tor's ControlPort

[Tor Bug Tracker & Wiki]

#16822: make certificate lifetime accessible through Tor's ControlPort
-+-
 Reporter:  proper   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec, tor-control, intro,  |  Actual Points:
  tor-relay  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  needs-proposal, SponsorS-deferred, tor-control => needs-spec,
 tor-control, intro, tor-relay
 * severity:   => Normal


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

Re: [tor-bugs] #16824 [Core Tor/Tor]: Emit a warning message about side channel leaks when using relays as clients

[Tor Bug Tracker & Wiki]

#16824: Emit a warning message about side channel leaks when using relays as
clients
-+-
 Reporter:  starlight|  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  mike-can, tor-client tor-relay   |  Actual Points:
  sidechannel logging easy   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  mike-can => mike-can, tor-client tor-relay sidechannel logging
 easy


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

Re: [tor-bugs] #16826 [Core Tor/Tor]: Add a mechanism to allow callgraph generator to find vtbl-like constructions

[Tor Bug Tracker & Wiki]

#16826: Add a mechanism to allow callgraph generator to find vtbl-like
constructions
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, callgraph, calltool,|  Actual Points:
  needs-insight  |
Parent ID:  #16764   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  testing, SponsorS-deferred => testing, callgraph, calltool,
 needs-insight
 * severity:   => Normal


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

Re: [tor-bugs] #16831 [Core Tor/Tor]: Cover dns.c with unit tests

[Tor Bug Tracker & Wiki]

#16831: Cover dns.c with unit tests
-+-
 Reporter:  rl1987   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  testing, tor-tests-coverage, tor-|  Actual Points:
  tests-unit |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  testing, SponsorS-deferred => testing, tor-tests-coverage,
 tor-tests-unit


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

Re: [tor-bugs] #16841 [Core Tor/Tor]: When configuration fails before log files are open, errors aren't written to the logs.

[Tor Bug Tracker & Wiki]

#16841: When configuration fails before log files are open, errors aren't 
written
to the logs.
--+--
 Reporter:  mphhuni   |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 Closing, per arma's rationale above.

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

Re: [tor-bugs] #22476 [Metrics/metrics-lib]: Replace ImplementationNotAccessibleException with RuntimeException

[Tor Bug Tracker & Wiki]

#22476: Replace ImplementationNotAccessibleException with RuntimeException
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * milestone:  metrics-lib 1.9.0 =>


Comment:

 We're planning to put out 1.9.0 tomorrow, and I'm now creating a pre-
 release tarball and testing it in various applications.  This change
 doesn't seem important enough to delay this.  Moving out of planned
 milestones.

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

Re: [tor-bugs] #19640 [Metrics/metrics-lib]: review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

#19640: review and improve interface hierarchy
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * milestone:  metrics-lib 1.9.0 =>


Comment:

 We decided today not to let this ticket (and #17861) delay the 1.9.0
 release, and 2.0.0 won't be a good target milestone either.  Taking this
 out of planned milestones for now.

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

Re: [tor-bugs] #17861 [Metrics/metrics-lib]: Consider adding a new interface RelayNetworkStatusMicrodescConsensus

[Tor Bug Tracker & Wiki]

#17861: Consider adding a new interface RelayNetworkStatusMicrodescConsensus
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * milestone:  metrics-lib 1.9.0 =>


Comment:

 We decided today not to let this ticket (and #19640) delay the 1.9.0
 release, and 2.0.0 won't be a good target milestone either.  Taking this
 out of planned milestones for now.

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

Re: [tor-bugs] #16845 [Core Tor/Tor]: make unverified consensus ISOTime accessible through Tor's ControlPort

[Tor Bug Tracker & Wiki]

#16845: make unverified consensus ISOTime accessible through Tor's ControlPort
-+-
 Reporter:  proper   |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-control needs-design maybe-bad-  |  Actual Points:
  idea   |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => closed
 * keywords:   => tor-control needs-design maybe-bad-idea
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 Closing this as "wontfix", since there's no safe way to actually use this
 information as far as I can tell.  Please reopen if there is?

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

Re: [tor-bugs] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt tor-dirauth pending-disaster  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, SponsorS-deferred, technical-debut tor-dirauth pending-
 disaster => easy, SponsorS-deferred, technical-debt tor-dirauth
 pending-disaster


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

Re: [tor-bugs] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debut tor-dirauth pending-disaster |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, SponsorS-deferred => easy, SponsorS-deferred, technical-
 debut tor-dirauth pending-disaster
 * priority:  Low => High
 * severity:   => Normal


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

Re: [tor-bugs] #16858 [Core Tor/Tor]: Non-ascii country code in extrainfo descriptor

[Tor Bug Tracker & Wiki]

#16858: Non-ascii country code in extrainfo descriptor
-+
 Reporter:  atagar   |  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay geoip  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:   => tor-relay geoip
 * status:  new => closed
 * resolution:   => fixed
 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


Comment:

 We currently suspect that was caused by #22490. Closing for now, but
 please reopen if this happens in 0.3.1.3-alpha or later.

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

Re: [tor-bugs] #22659 [Applications/Tor Browser]: Changes to `intl.accept.languages` get overwritten after restart

[Tor Bug Tracker & Wiki]

#22659: Changes to `intl.accept.languages` get overwritten after restart
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201706, GeorgKoppen201706|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 mcs]:
 > So far I cannot reproduce this problem when testing on OSX without the
 patch for #21999. Here is what I did:
 > 1. Opened a clean copy of the es-ES variant of Tor Browser 7.0.1 (no
 preexisting TorBrowser-Data directory).
 > 2. Clicked `Conectar` during startup.
 > 3. Opened about:config and noted that the value for
 `intl.accept_languages` was `en-US, en` as expected.
 > 4. Used about:config to toggle `extensions.torbutton.spoof_english` to
 `false` and noted that the `intl.accept_languages` value had been changed
 to `es-ES, es, en-US, en` (the default value).
 > 5. Restarted the browser and checked the `intl.accept_languages` one
 more time. The value was still `es-ES, es, en-US, en`.

 I followed those five steps and I get `en-US, en` as result. Could you
 test on a Linux box (I did that)? Maybe that's the difference (although
 this would be even weirder)...

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

Re: [tor-bugs] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * milestone:  metrics-lib 1.9.0 =>


Comment:

 We already achieved some of the aspects here by merging #22141, and now we
 ran out of time for the 1.9.0 release which is scheduled for tomorrow.
 Let's work more on the remaining aspects here when 1.9.0 and 2.0.0 are
 out.  Removing from planned milestones.

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

Re: [tor-bugs] #16894 [Core Tor/Tor]: Check all logging output is appropriately escaped / escaped_safe_str_client

[Tor Bug Tracker & Wiki]

#16894: Check all logging output is appropriately escaped / 
escaped_safe_str_client
-+-
 Reporter:  teor |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  security, logging, lorax, intro  |  Actual Points:
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  security, logging, lorax => security, logging, lorax, intro
 * points:   => 10
 * severity:   => Normal


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

Re: [tor-bugs] #16895 [Obfuscation/Pluggable transport]: allow Tor to parse bridge information copied and pasted verbatim from bridges.torproject.org

[Tor Bug Tracker & Wiki]

#16895: allow Tor to parse bridge information copied and pasted verbatim from
bridges.torproject.org
-+-
 Reporter:  proper   |  Owner:  asn
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt tor-bridge usability needs-   |  Actual Points:
  design |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-pt, lorax => tor-pt tor-bridge usability needs-design
 * cc: linda (added)
 * severity:   => Normal


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

Re: [tor-bugs] #22514 [Metrics/metrics-lib]: Replace DescriptorReader's setMaxDescriptorFilesInQueue() with setMaxMemory()

[Tor Bug Tracker & Wiki]

#22514: Replace DescriptorReader's setMaxDescriptorFilesInQueue() with
setMaxMemory()
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.9.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Now that #22141 is merged, we can close this ticket.  It's implemented.

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

Re: [tor-bugs] #21365 [Metrics/metrics-lib]: metrics-lib might not be thread-safe

[Tor Bug Tracker & Wiki]

#21365: metrics-lib might not be thread-safe
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  task | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Note: Also look into #22678 when working on this.

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

[tor-bugs] #22678 [Metrics/metrics-lib]: Look into existing Java Collections classes as replacement for BlockingIteratorImpl

[Tor Bug Tracker & Wiki]

#22678: Look into existing Java Collections classes as replacement for
BlockingIteratorImpl
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Looks like `java.util.concurrent.BlockingQueue` might be a
 good replacement for our custom `BlockingIteratorImpl`.  Or if
 the interface doesn't exactly match our needs (thinking of end-of-stream
 elements), maybe we can use that class internally rather than building our
 own blocking queue.  This means less code and fewer bugs.  This could
 resolve #21365.

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

Re: [tor-bugs] #22672 [Core Tor/Tor]: Defensive programming: ensure no infinite COMPRESS_OK loops

[Tor Bug Tracker & Wiki]

#22672: Defensive programming: ensure no infinite COMPRESS_OK loops
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me.

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

Re: [tor-bugs] #22196 [Metrics/metrics-lib]: Configure descriptor sources using method chaining

[Tor Bug Tracker & Wiki]

#22196: Configure descriptor sources using method chaining
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * milestone:  metrics-lib 1.9.0 =>


Comment:

 As explained in
 [https://trac.torproject.org/projects/tor/ticket/22141#comment:13 this
 comment], we can't just dump the parse history and replace it with a
 `minLastModified` timestamp.  We should reconsider which of these changes
 we can make, and we won't be able to do that for 1.9.0 anymore.  Moving
 out of the currently planned milestones.

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

Re: [tor-bugs] #22422 [Core Tor/Tor]: Add noise to PaddingStatistics

[Tor Bug Tracker & Wiki]

#22422: Add noise to PaddingStatistics
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 To know how many padding cells to expect for a client, we need information
 on how long an average client's connection lasts, how often they make
 connections during a 24 hour interval, and what percentage of the time
 those connections are idle. Do we have this data?

 Also, is there a good example of where we add noise in a way successfully
 calculates how to hide a single client's activity? It would be helpful to
 have a reference to work off of.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22677 [Core Tor/Tor]: better Sandbox manpage documentation

[Tor Bug Tracker & Wiki]

#22677: better Sandbox manpage documentation
--+---
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  documentation trivial
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 As far as I have read Sandbox 1 uses seccomp, so it does not do anything
 when enabled on non-Linux systems?
 If that is the case state that in the man page.



 https://en.wikipedia.org/wiki/Seccomp

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

Re: [tor-bugs] #16821 [Core Tor/Tor]: additional /var/run/tor/log default log

[Tor Bug Tracker & Wiki]

#16821: additional /var/run/tor/log default log
+--
 Reporter:  proper  |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  downstream, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => downstream, logging, tor-relay
 * priority:  Medium => Low
 * severity:   => Normal


Comment:

 Is there a good rationale to do this in tor, instead of having downstream
 packages do it?  We don't usually set logging policy ourselves...

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

Re: [tor-bugs] #16811 [Core Tor/Tor]: Mark TestingTorNetwork PREDICT_UNLIKELY

[Tor Bug Tracker & Wiki]

#16811: Mark TestingTorNetwork PREDICT_UNLIKELY
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  lorax, easy, needs-analysis  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:  SponsorS-can
-+-
Changes (by nickm):

 * keywords:  lorax, easy => lorax, easy, needs-analysis
 * priority:  Medium => Very Low
 * severity:  Normal => Trivial


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

Re: [tor-bugs] #16803 [Core Tor/Tor]: Unit tests for sandbox failures

[Tor Bug Tracker & Wiki]

#16803: Unit tests for sandbox failures
-+--
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, intro, sandbox  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+--
Changes (by nickm):

 * keywords:  testing, intro, SponsorS-deferred => testing, intro, sandbox
 * severity:   => Normal


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

Re: [tor-bugs] #16799 [Core Tor/Tor]: Raise utility testing over 95%

[Tor Bug Tracker & Wiki]

#16799: Raise utility testing over 95%
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, tor-tests-coverage, tor-|  Actual Points:
  tests-unit |
Parent ID:  #17288   | Points:  4.5
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Update:
 {{{
 util_bug.c.gcov 12 30 71.43
 util.c.gcov 397 1401 77.92
 util_format.c.gcov 1 167 99.40
 util_process.c.gcov 2 38 95.00
 workqueue.c.gcov 22 136 86.08
 memarea.c.gcov 0 102 100.00
 address.c.gcov 73 676 90.25
 log.c.gcov 170 392 69.75
 TOTAL 677 2942 81.29
 }}}

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

Re: [tor-bugs] #16798 [Core Tor/Tor]: Raise compat_* testing to over 80%

[Tor Bug Tracker & Wiki]

#16798: Raise compat_* testing to over 80%
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, tor-tests-coverage, tor-|  Actual Points:
  tests-unit |
Parent ID:  #17288   | Points:  4.5
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Latest from make check:
 {{{
 compat.c.gcov 276 550 66.59
 compat_libevent.c.gcov 33 61 64.89
 compat_pthreads.c.gcov 22 94 81.03
 compat_rust.c.gcov 0 9 100.00
 compat_threads.c.gcov 31 127 80.38
 compat_time.c.gcov 19 100 84.03
 TOTAL 381 941 71.18
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22676 [Applications/Tor Messenger]: Check if key exists before fetching pref

[Tor Bug Tracker & Wiki]

#22676: Check if key exists before fetching pref
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 User reported error on irc,

 {{{
 ERROR (@ prpl-irc: ircHandlers._handleMessage
 resource:///modules/ircHandlers.jsm:188)
 Error running command sasl with handler SASL CAP:
 {"rawMessage":":lechuck.hackint.org CAP * LS :account-notify away-notify
 cap-notify chghost extended-join multi-prefix sasl tls userhost-in-
 names","command":"CAP","params":["*","LS","account-notify away-notify cap-
 notify chghost extended-join multi-prefix sasl tls userhost-in-
 
names"],"origin":"lechuck.hackint.org","tags":{},"source":"","cap":{"subcommand":"LS","parameter":"sasl","disable":false,"sticky":false,"ack":false}
 Component returned failure code: 0x8000 (NS_ERROR_UNEXPECTED)
 [nsIPrefBranch.getCharPref]
 }}}

 https://developer.mozilla.org/en-US/Add-
 ons/Code_snippets/Preferences#check_For_Existence

 Probably from,

 {{{
 let ecdsa =
 this.imAccount.wrappedJSObject.prefBranch.getCharPref("ecdsa");
 }}}

 in ircSASL.jsm

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

Re: [tor-bugs] #16795 [Core Tor/Tor]: Process-related utility code should have unit test coverage over 95%

[Tor Bug Tracker & Wiki]

#16795: Process-related utility code should have unit test coverage over 95%
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, tor-tests-coverage, tor-|  implemented
  tests-unit |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 *lagging

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

Re: [tor-bugs] #16795 [Core Tor/Tor]: Process-related utility code should have unit test coverage over 95%

[Tor Bug Tracker & Wiki]

#16795: Process-related utility code should have unit test coverage over 95%
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  testing, tor-tests-coverage, tor-|  implemented
  tests-unit |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

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


Comment:

 These modules are over 75% now, and are no longer logging seriously behind
 the rest of the world. Closing.

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

Re: [tor-bugs] #22399 [Applications/Tor Launcher]: Tor launcher third-party censorship circumvention tools support

[Tor Bug Tracker & Wiki]

#22399: Tor launcher third-party censorship circumvention tools support
---+-
 Reporter:  iry|  Owner:  brade
 Type:  project| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by gk):

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


Comment:

 Okay, I think that means WONTFIX for now.

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

Re: [tor-bugs] #16782 [Core Tor/Tor]: systemd unit file is not compatible with the AppArmorProfile= directive

[Tor Bug Tracker & Wiki]

#16782: systemd unit file is not compatible with the AppArmorProfile= directive
-+-
 Reporter:  intrigeri|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  systemd, apparmor, debian,   |  Actual Points:
  packaging  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  systemd, apparmor => systemd, apparmor, debian, packaging


Comment:

 Is there any way we can devolve responsibility here to the distributors? I
 don't think we have anybody on the core tor programming team who is expert
 in systemd or apparmor.

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

Re: [tor-bugs] #16764 [Core Tor/Tor]: Simplify Tor's control flow graph to the extent we can.

[Tor Bug Tracker & Wiki]

#16764: Simplify Tor's control flow graph to the extent we can.
-+-
 Reporter:  nickm|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  blob, tor-modularity, callgraph, |  Actual Points:
  technical-debt |
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * keywords:  blob, tor-modularity => blob, tor-modularity, callgraph,
 technical-debt


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

Re: [tor-bugs] #16723 [Core Tor/Tor]: randomize HH:MM in AccountingStart for a more even distribution of hibernating relay resources

[Tor Bug Tracker & Wiki]

#16723: randomize HH:MM in AccountingStart for a more even distribution of
hibernating relay resources
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  needs_information => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 per comments above, closing: this isn't actually a good 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] #16696 [Core Tor/Tor]: BWauth no-consensus fallback logic may need revision

[Tor Bug Tracker & Wiki]

#16696: BWauth no-consensus fallback logic may need revision
+--
 Reporter:  starlight   |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth bwauth measurement  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => tor-dirauth bwauth measurement
 * severity:   => Normal


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

Re: [tor-bugs] #16682 [Core Tor/Tor]: Deploy TCP Fast Open at exits (and maybe inter-node?)

[Tor Bug Tracker & Wiki]

#16682: Deploy TCP Fast Open at exits (and maybe inter-node?)
-+-
 Reporter:  mikeperry|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance tor-relay exit needs-|  Actual Points:
  analysis term-project  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  performance => performance tor-relay exit needs-analysis term-
 project
 * status:  reopened => new
 * severity:   => Normal


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

Re: [tor-bugs] #16680 [Core Tor/Tor]: make Ed25519 master key, signing key and cert ascii-armored on disk by default

[Tor Bug Tracker & Wiki]

#16680: make Ed25519 master key, signing key and cert ascii-armored on disk by
default
--+
 Reporter:  s7r   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.2.7.2-alpha
 Severity:  Normal| Resolution:  wontfix
 Keywords:  ed25519, keys, ascii-armored  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #16648 [Core Tor/Tor]: Libevent configuration doesn't use pkg-config

[Tor Bug Tracker & Wiki]

#16648: Libevent configuration doesn't use pkg-config
---+---
 Reporter:  mmcc   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-build libevent pkg-config  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => tor-build libevent pkg-config
 * severity:   => Normal


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

Re: [tor-bugs] #16556 [Core Tor/Tor]: NEWDESC clarification

[Tor Bug Tracker & Wiki]

#16556: NEWDESC clarification
--+--
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  new => closed
 * keywords:  tor-spec, needs-proposal => tor-spec
 * resolution:   => fixed
 * severity:   => Normal


Comment:

 What was I thinking when I marked this needs-proposal? It's just a spec
 clarification.

 Closed in ccd21c0bb735dd

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22675 [Applications/Tor Browser]: Tor Browser 7.0.1 opens at 1000x500 resolution

[Tor Bug Tracker & Wiki]

#22675: Tor Browser 7.0.1 opens at 1000x500 resolution
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tor browser, linux,
 Severity:  Normal   |  screen size, fingerprinting,
 |  1000x500, 1000x600
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Tor Browser 7.0.1 opens at 1000x500 resolution instead of 1000x600 on
 Linux. I am on Tails 3.0.

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

Re: [tor-bugs] #16558 [Core Tor/Tor]: Dir auths should vote about Invalid like they do about BadExit

[Tor Bug Tracker & Wiki]

#16558: Dir auths should vote about Invalid like they do about BadExit
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dirauth  |  Actual Points:
Parent ID:  #16538  | Points:  6
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:  tor-hs => tor-hs tor-dirauth


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

Re: [tor-bugs] #16562 [Core Tor/Tor]: Harmonize curve25519-signature format with what others are doing

[Tor Bug Tracker & Wiki]

#16562: Harmonize curve25519-signature format with what others are doing
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay x25519 cross-signature |  Actual Points:
  needs-design   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => tor-relay x25519 cross-signature needs-design


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

Re: [tor-bugs] #16562 [Core Tor/Tor]: Harmonize curve25519-signature format with what others are doing

[Tor Bug Tracker & Wiki]

#16562: Harmonize curve25519-signature format with what others are doing
--+--
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * cc: isis, hdevalance (added)
 * severity:   => Normal


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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+--
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * cc: isis (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] #16579 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#16579: (Sandbox) Caught a bad syscall attempt (syscall socket)
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport tor-client tor-relay|  Actual Points:
  linux sandbox 32bit|
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  029-backport => 029-backport tor-client tor-relay linux
 sandbox 32bit


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

Re: [tor-bugs] #16585 [Core Tor/Tor]: Network activity from scheduler_run() creates multiple side channel information leaks

[Tor Bug Tracker & Wiki]

#16585: Network activity from scheduler_run() creates multiple side channel
information leaks
---+---
 Reporter:  starlight  |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.6.10
 Severity:  Normal | Resolution:
 Keywords:  tor-client guard side-channel  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => tor-client guard side-channel
 * severity:   => Normal


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

Re: [tor-bugs] #16608 [Core Tor/Tor]: "time published in the consensus network status" seems to be wrong

[Tor Bug Tracker & Wiki]

#16608: "time published in the consensus network status" seems to be wrong
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  unsolved needs-diagnosis tor-relay   |  Actual Points:
  time   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  unsolved => unsolved needs-diagnosis tor-relay time


Comment:

 Could it be that we're launching requests for a consensus before it's
 actually live?

 Here's my theory: If we happen to start a directory cache after a new
 consensus is made and signed, but before it is live, the authorities give
 it to us anyway, and we get nervous because it's published in the future.

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

Re: [tor-bugs] #22139 [Metrics/metrics-lib]: last_restarted and platform missing even though it is available in descriptor

[Tor Bug Tracker & Wiki]

#22139: last_restarted and platform missing even though it is available in
descriptor
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.9.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 This issue will be fixed in 1.9.0 with #22141 being just merged to master.
 The change is also backward-compatible, because we added a new
 `readDescriptors(File...)` method that can handle single malformed
 descriptors (by returning a `UnparseableDescriptor`), so we didn't have to
 wait for 2.0.0 to make this change.  The `readDescriptors()` method that
 doesn't support single malformed descriptors is now deprecated and will be
 removed in 2.0.0.  That means we can now close this ticket, which I'll do.

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

Re: [tor-bugs] #16636 [Core Tor/Tor]: Add AccountingSetBytesRead/Written

[Tor Bug Tracker & Wiki]

#16636: Add AccountingSetBytesRead/Written
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, accounting needs-design,  |  Actual Points:
  lorax, easy tor-control|
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay, needs-design, lorax, easy => tor-relay, accounting
 needs-design, lorax, easy tor-control
 * priority:  Medium => Low


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

Re: [tor-bugs] #16646 [Core Tor/Tor]: Cannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)

[Tor Bug Tracker & Wiki]

#16646: Cannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)
-+-
 Reporter:  asn  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, performance, research,   |  Actual Points:
  prop247, tor-hs|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs, performance, research => tor-hs, performance,
 research, prop247, tor-hs


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

Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
--+-
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by isis):

 * keywords:   => ci
 * cc: patrickod (added)


Comment:

 CCing Patrick from NoiseTor on this, since (IIRC) it was originally his
 idea and I believe he is still interested in working on this.

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

Re: [tor-bugs] #16598 [Core Tor/Tor]: fsync ed25519 master key files before closing them.

[Tor Bug Tracker & Wiki]

#16598: fsync ed25519 master key files before closing them.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Very Low  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ed25519 tor-relay fsync easy  |  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  ed25519 => ed25519 tor-relay fsync easy


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

Re: [tor-bugs] #16458 [Core Tor/Tor]: torspec references UTC, but tor uses unix time (leap second handling)

[Tor Bug Tracker & Wiki]

#16458: torspec references UTC, but tor uses unix time (leap second handling)
-+-
 Reporter:  teor |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec documentation easy gmt utc  |  Actual Points:
  time   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)


Comment:

 If "Unix time" means POSIX seconds-since-the-epoch, it won't differ by ~30
 seconds from UTC.  If you're using the "right" time zones from the TZ
 database (which purport to count SI seconds since the POSIX epoch), you'll
 get such a difference but you're no longer using POSIX time.  I'm hoping
 that people don't run the "right" time zones in production, but some of
 the BSDs used to default to it.

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

Re: [tor-bugs] #22674 [Metrics/metrics-lib]: Consider changing instance methods to static methods

[Tor Bug Tracker & Wiki]

#22674: Consider changing instance methods to static methods
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:1 iwakeh]:
 > I think the entire structure needs some improvement.

 Agreed.

 > This small change is useful to mark methods that don't rely on instance
 variables/methods as 'static'.
 > Anyway, `parseDescriptors` used to be static before and that was just
 changed (I missed the reason).

 Ah, heh, mainly because I thought it was an oversight that it was static
 before.  Happy to reconsider (without the time constraint of
 wanting/needing to put out two releases within 10 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] #22671 [Webpages/Blog]: Implement design changes to blog.torproject.org

[Tor Bug Tracker & Wiki]

#22671: Implement design changes to blog.torproject.org
---+--
 Reporter:  linda  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by linda):

 Replying to [comment:3 cypherpunks]:
 > It definitely looks much better, great work!

 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] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 This seems fine.
 If additional test runs (system tests) don't reveal anything problematic.
 Another CollecTor release could simply contain the switch to 1.9.0 or/and
 2.0.0

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

Re: [tor-bugs] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * component:  Metrics/metrics-lib => Metrics/CollecTor


Comment:

 Looks pretty good.  Please review [https://gitweb.torproject.org/karsten
 /metrics-
 db.git/commit/?h=task-22652&id=728a9cd1f4e5906b12a04f70dc153de5b24993d9
 this additional commit] though.  Let's revisit once metrics-lib 1.9.0 is
 out and we're confident that we'll get 2.0.0 out by end of the month.
 Moving to the CollecTor component.

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

Re: [tor-bugs] #22674 [Metrics/metrics-lib]: Consider changing instance methods to static methods

[Tor Bug Tracker & Wiki]

#22674: Consider changing instance methods to static methods
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 I think the entire structure needs some improvement.
 This small change is useful to mark methods that don't rely on instance
 variables/methods as 'static'.
 Anyway, `parseDescriptors` used to be static before and that was just
 changed (I missed the reason).

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

Re: [tor-bugs] #12931 [Core Tor/Tor]: TOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txt

[Tor Bug Tracker & Wiki]

#12931: TOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txt
-+-
 Reporter:  yawning  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  pluggable, transports, pt-spec,  |  Actual Points:  0
  review-group-18|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 okay. thanks for the reply!  Closing this ticket.

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

Re: [tor-bugs] #16294 [Core Tor/Tor]: Unable to bootstrap when no relays meet criteria; logging messages unhelpful (was: Unable to bootstrap when no relays meet criteria)

[Tor Bug Tracker & Wiki]

#16294: Unable to bootstrap when no relays meet criteria; logging messages
unhelpful
+--
 Reporter:  atagar  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client, bootstrap, logging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => tor-client, bootstrap, logging
 * severity:   => Normal


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

Re: [tor-bugs] #16366 [Core Tor/Tor]: tor hangs for 30 seconds when parsing torrc ending in backslash-newline

[Tor Bug Tracker & Wiki]

#16366: tor hangs for 30 seconds when parsing torrc ending in backslash-newline
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.8
 Severity:  Normal   | Resolution:
 Keywords:  lorax tor-relay tor-client   |  Actual Points:
  configuration newline osx torrc|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  lorax => lorax tor-relay tor-client configuration newline osx
 torrc
 * severity:   => Normal


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

Re: [tor-bugs] #16350 [Core Tor/Tor]: tor.pid should be deleted on exit in every case possible, like assert termination, and catchable signals

[Tor Bug Tracker & Wiki]

#16350: tor.pid should be deleted on exit in every case possible, like assert
termination, and catchable signals
---+--
 Reporter:  yurivict271|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-relay cleanup  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * keywords:   => tor-relay cleanup
 * points:  small => 3
 * severity:   => Normal


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

Re: [tor-bugs] #16372 [Core Tor/Tor]: tor uses getaddrinfo even if DisableNetwork is set

[Tor Bug Tracker & Wiki]

#16372: tor uses getaddrinfo even if DisableNetwork is set
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-relay documentation easy  |  Actual Points:
Parent ID:  #16366| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  lorax => tor-relay documentation easy
 * severity:   => Normal


Comment:

 This could be an easy fix, if we say that the right answer is to change
 the documentation of DisableNetwork.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22674 [Metrics/metrics-lib]: Consider changing instance methods to static methods

[Tor Bug Tracker & Wiki]

#22674: Consider changing instance methods to static methods
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 There's a [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?id=fc04e540b86c7e9d375084c879c02280f8fd60ee patch] that we
 didn't merge yet that makes methods without instance references static.
 I'm including that patch here in bulk, just in case it gets lost when the
 branch gets deleted:

 {{{
 From fc04e540b86c7e9d375084c879c02280f8fd60ee Mon Sep 17 00:00:00 2001
 From: iwakeh 
 Date: Mon, 19 Jun 2017 15:08:45 +
 Subject: Make methods without instance references 'static'.


 diff --git
 a/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 b/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 index a0be85c..ec04901 100644
 ---
 a/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 +++
 b/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 @@ -69,7 +69,7 @@ public class DescriptorParserImpl implements
 DescriptorParser {
  NL + Key.NETWORK_STATUS_VERSION.keyword + SP + "3"))
  && firstLines.contains(
  NL + Key.VOTE_STATUS.keyword + SP + "consensus" + NL))) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.NETWORK_STATUS_VERSION,
 RelayNetworkStatusConsensusImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type network-status-vote-3 1.")
 @@ -79,7 +79,7 @@ public class DescriptorParserImpl implements
 DescriptorParser {
  NL + Key.NETWORK_STATUS_VERSION.keyword + SP + "3" + NL))
  && firstLines.contains(
  NL + Key.VOTE_STATUS.keyword + SP + "vote" + NL))) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.NETWORK_STATUS_VERSION, RelayNetworkStatusVoteImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type bridge-network-status 1.")
 @@ -90,42 +90,42 @@ public class DescriptorParserImpl implements
 DescriptorParser {
descriptorFile, fileName,
 this.failUnrecognizedDescriptorLines));
return parsedDescriptors;
  } else if (firstLines.startsWith("@type bridge-server-descriptor
 1.")) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.ROUTER, BridgeServerDescriptorImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type server-descriptor 1.")
  || firstLines.startsWith(Key.ROUTER.keyword + SP)
  || firstLines.contains(NL + Key.ROUTER.keyword + SP)) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.ROUTER, RelayServerDescriptorImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type bridge-extra-info 1.")) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.EXTRA_INFO, BridgeExtraInfoDescriptorImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type extra-info 1.")
  || firstLines.startsWith(Key.EXTRA_INFO.keyword + SP)
  || firstLines.contains(NL + Key.EXTRA_INFO.keyword + SP)) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.EXTRA_INFO, RelayExtraInfoDescriptorImpl.class,
this.failUnrecognizedDescriptorLines,
 includeUnparseableDescriptors);
  } else if (firstLines.startsWith("@type microdescriptor 1.")
  || firstLines.startsWith(Key.ONION_KEY.keyword + NL)
  || firstLines.contains(NL + Key.ONION_KEY.keyword + NL)) {
 -  return this.parseDescriptors(rawDescriptorBytes, descriptorFile,
 +  return parseDescriptors(rawDescriptorBytes, descriptorFile,
Key.ONION_KEY, MicrodescriptorImpl.class,
this.f

Re: [tor-bugs] #16387 [Core Tor/Tor]: Improve reachability of hidden services on mobile phones

[Tor Bug Tracker & Wiki]

#16387: Improve reachability of hidden services on mobile phones
---+--
 Reporter:  asn|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs sponsor8-maybe  |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * keywords:  tor-hs => tor-hs sponsor8-maybe
 * points:   => 10
 * actualpoints:  3 =>


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