Re: [tor-bugs] #23893 [Applications/Tor Browser]: Tor Browser page tabs crash on initial loading of sites including Tor

[Tor Bug Tracker & Wiki]

#23893: Tor Browser page tabs crash on initial loading of sites including Tor
--+--
 Reporter:  rollingstone  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rollingstone):

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


Comment:

 i can't use tor on either of my laptops. :(

 i thought it might be ipVanish but tor crashes regardless of whether i use
 it or not.  Now i have downloaded the latest update and as soon as i try
 to go from start page to this site it crashes.  Reloading does not do
 anything.

 Both laptops running windows 10. one is a sony viao the other is a dell
 xps.  Using windows defender for antivirus.

 I don't have any other programs exhibiting bizarre behavior.

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

Re: [tor-bugs] #23957 [Obfuscation/BridgeDB]: Add support for bridge-distribution descriptor lines in BridgeDB

[Tor Bug Tracker & Wiki]

#23957: Add support for bridge-distribution descriptor lines in BridgeDB
---+--
 Reporter:  isis   |  Owner:  isis
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/BridgeDB   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  bridgedb-parsers, bridgedb-db  |  Actual Points:  1.5
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorM
---+--
Changes (by isis):

 * status:  new => closed
 * keywords:  bridgedb-parsers => bridgedb-parsers, bridgedb-db
 * resolution:   => fixed
 * actualpoints:   => 1.5


Comment:

 Okay… gag me with a spoon; I had to write a bit of SQL also.

 This is done; it's in my `feature/23957`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/23034
 branch]. Feel free to review, but I'm probably just going to merge because
 otherwise this would sadly sit around waiting forever.

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

Re: [tor-bugs] #23987 [Internal Services/Service - jenkins]: Stop using --enable-fatal-warnings on GCC 0.2.8 builds

[Tor Bug Tracker & Wiki]

#23987: Stop using --enable-fatal-warnings on GCC 0.2.8 builds
-+
 Reporter:  nickm|  Owner:  weasel
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 
https://gitweb.torproject.org/project/jenkins/tools.git/commit/?id=a717268fdcba6e79cd5dc33fdfadb2e7ce02bbe2

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

Re: [tor-bugs] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  needs_review
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Okay, the fuzzers didn't find anything.  What do you think of
 `hsdescv3_fuzz_more`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24036 [Metrics]: Create a unified package naming scheme for all metrics code bases

[Tor Bug Tracker & Wiki]

#24036: Create a unified package naming scheme for all metrics code bases
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The discussion behind #24028 made me think whether we could find a unified
 package naming scheme for all metrics code bases.

 I reserve the right to come up with an even smarter plan after today, but
 sharing my thoughts here might allow us to come up with an even smarterer
 plan together.

 ||='''Current code base''' ||='''Current package and classes, starting
 with `org.torproject.`''' ||='''Suggested package, starting with
 `org.torproject.metrics.`''' ||='''Suggested code base, only if
 different''' ||
 || CollecTor || collector (1) || collector || ||
 || CollecTor || collector.bridgedescs (3) || collector.bridgedescs || ||
 || CollecTor || collector.conf (5) || collector.conf || ||
 || CollecTor || collector.cron (3) || collector.cron || ||
 || CollecTor || collector.exitlists (1) || collector.exitlists || ||
 || CollecTor || collector.index (1) || index || metrics-lib (*1) ||
 || CollecTor || collector.onionperf (2) || collector.onionperf || ||
 || CollecTor || collector.persist (12) || collector.persist || ||
 || CollecTor || collector.relaydescs (6) || collector.relaydescs || ||
 || CollecTor || collector.sync (4) || collector.sync || ||
 || ExoneraTor || exonerator.ExoneraTorDatabaseImporter || exonerator || ||
 || ExoneraTor || exonerator.ExoneraTorServlet || web || metrics-web (*2)
 ||
 || ExoneraTor || exonerator.QueryServlet || exonerator || ||
 || ExoneraTor || exonerator.QueryResponse || exonerator || metrics-lib
 (*3) ||
 || metrics-lib || descriptor (28) || descriptor || ||
 || metrics-lib || descriptor.impl (31) || descriptor.impl || ||
 || metrics-lib || descriptor.index (4) || index (*4) || ||
 || metrics-lib || descriptor.internal (1) || util (*5) || ||
 || metrics-web || metrics.advbwdist (1) || stats.advbwdist || ||
 || metrics-web || metrics.clients (1) || stats.clients || ||
 || metrics-web || metrics.collectdescs (1) || stats.collectdescs || ||
 || metrics-web || metrics.connbidirect (1) || stats.connbidirect || ||
 || metrics-web || metrics.hidserv (11) || stats.hidserv || ||
 || metrics-web || ernie.cron (6) || stats.servers (*6) || ||
 || metrics-web || metrics.onionperf (1) || stats.onionperf || ||
 || metrics-web || metrics.webstats (1) || stats.webstats || ||
 || metrics-web || metrics.web (27) || web || ||
 || metrics-web || metrics.web.graphs (7) || web.graphs || ||
 || metrics-web || metrics.web.research (1) || web (*7) || ||
 || Onionoo || onionoo.cron (1) || onionoo.cron || ||
 || Onionoo || onionoo.docs (21) || onionoo.docs || metrics-lib (*8) ||
 || Onionoo || onionoo.server (15) || onionoo.server || ||
 || Onionoo || onionoo.updater (18) || onionoo.updater || ||
 || Onionoo || onionoo.util (1) || util || metrics-lib (*9) ||
 || Onionoo || onionoo.writer (8) || onionoo.writer || ||

 (*1) Right now, only CollecTor produces an index.json file, but with
 #23285 we might extend that to metrics-web producing an index.json file of
 available stats files.

 (*2) This is part of moving all presentation things to metrics-web,
 including ExoneraTor (#23549), and once we do that we'll have to write and
 read the QueryResponse from two different code bases.

 (*3) See (*2).

 (*4) These classes don't depend on the descriptor-parsing part of metrics-
 lib but are generally useful for other metrics code bases.

 (*5) See (*4), though we might rename "internal" to "util" to focus what
 this package is for (utility classes) rather than who it's not for
 (external folks).

 (*6) The old package name is so legacy, let's take the opportunity to pick
 a more useful name now. It's all about servers and bandwidth (provided by
 servers).

 (*7) This servlet class is the last survivor of the "research" package and
 could as well join the other servlets.

 (*8) Moving the docs to metrics-lib would allow metrics-bot and other Java
 Onionoo clients to use Onionoo documents without writing their own parser.

 (*9) We could gather all utility-type classes that are truly independent
 of their respective code bases in metrics-lib.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24035 [Internal Services/Service - jenkins]: It would be great to have a rust builder on jenkins

[Tor Bug Tracker & Wiki]

#24035: It would be great to have a rust builder on jenkins
-+
 Reporter:  nickm|  Owner:  weasel
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 This is an "I want a pony" task for now, but it would be really cool: it
 would be great if there were a Jenkins builder that built Tor with rust
 enabled -- ideally, it would do make check, and then do  distcheck with
 `AM_DISTCHECK_CONFIGURE_FLAGS="--enable-rust --enable-cargo-online-mode
 --enable-fatal-warnings"` or something like that.

 This isn't going to be 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] #24034 [Core Tor/TorDNSEL]: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6

[Tor Bug Tracker & Wiki]

#24034: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 Dupe of #16947

 Also, see https://www.fredericjacobs.com/blog/2016/08/18/torcheck-ipv6/
 and #19940

 And an ml thread Mike wrote called "Ownership for check.torproject.org?"

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

Re: [tor-bugs] #24034 [Core Tor/TorDNSEL]: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6

[Tor Bug Tracker & Wiki]

#24034: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 (bug reported by a user who was trying to handle abuse by a Tor user to
 their website, and found that ipv6 connections and addresses were totally
 missing from our metrics infrastructure)

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

Re: [tor-bugs] #24034 [Core Tor/TorDNSEL]: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6

[Tor Bug Tracker & Wiki]

#24034: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * cc: arlolra, karsten (added)


Comment:

 Adding Arlo and Karsten as two hopefully interested parties.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24034 [Core Tor/TorDNSEL]: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6

[Tor Bug Tracker & Wiki]

#24034: exitaddresses, and bulkexitlist, (and check?), don't know about IPv6
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 https://check.torproject.org/cgi-
 bin/TorBulkExitList.py?ip=69.55.226.35=80
 gives me a pile of ipv4 addresses. I think it parses
 https://check.torproject.org/exit-addresses
 plus maybe descriptors or consensuses to get exit policies.

 But tordnsel was written back when IPv6 was not a thing. So that means
 every step of our pathway is missing the concept of IPv6.

 I guess the most urgent part to fix, which ties into metrics, is that we
 aren't collecting the ipv6 exit addresses of relays, which means we won't
 be able to look back in time and answer questions that have to do with
 ipv6 connections out of Tor.

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

Re: [tor-bugs] #19640 [Metrics/Library]: Review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Great, works for me! Re-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] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  task   | Status:  accepted
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by nickm):

 * owner:  dgoulet => nickm
 * status:  needs_review => accepted


Comment:

 I've got a fuzzer for the decrypted parts, but I should run it for a while
 before uploading.

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

Re: [tor-bugs] #24028 [Metrics/Library]: Provide a modernized API for metrics-lib

[Tor Bug Tracker & Wiki]

#24028: Provide a modernized API for metrics-lib
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> In order to provide a more modern API in metrics-lib the interface
> hierarchy needs to be renewed/restructured/changed in backwards
> compatible ways.
>
> A separate discussion led to the following results:
>
> * The new interfaces will be placed in new packages, which allows for
> keeping good names and improving other w/o disturbing the existing
> classes.  Suggested packages:
>   - org.torproject.metrics.descriptor
>   - org.torproject.metrics.descriptor.impl
>   - org.torproject.metrics.index
>   - org.torproject.metrics.internal
>
> * Besides improving the general structure consider different return types
> for all time related values and use java.util.Optional for all optional
> values and other java 8 features (as mentioned in summary ticket #23752).
>

> Possible next steps:
>
> * Use a small, i.e., limited to few classes/interfaces, prototype example
> for finding the right approach to make these two interface hierarchies
> live beside each other and minimize additional implementation.
> * Use the working prototype approach to try new naming rules for methods.
> * Extend the found solution to the entire public API.
> * Choose first code base to use the new interface hierarchy.
> * Possibly improve new interface hierarchy.
> * Use new interfaces in all Metrics products.
>
> The other ticket related to an improved metrics-lib API is obsolete with
> this new approach; for reference: #19640.  There is a pending new
> interfaces, which should be only implemented with the new hierarchy (if
> demand permits): #17861.
> The work-in-progress interfaces (and implementations) for webstats could
> be moved into the new hierarchy already, but could also be easily moved
> later.

New description:

 In order to provide a more modern API in metrics-lib the interface
 hierarchy needs to be renewed/restructured/changed in backwards compatible
 ways.

 A separate discussion led to the following results:

 * The new interfaces will be placed in new packages, which allows for
 keeping good names and improving other w/o disturbing the existing
 classes.  Suggested packages:
   - org.torproject.metrics.descriptor
   - org.torproject.metrics.descriptor.impl
   - org.torproject.metrics.index
   - org.torproject.metrics.internal

 * Besides improving the general structure consider different return types
 for all time related values and use java.util.Optional for all optional
 values and other java 8 features (as mentioned in summary ticket #23752).


 Possible next steps:

 * Use a small, i.e., limited to few classes/interfaces, prototype example
 for finding the right approach to make these two interface hierarchies
 live beside each other and minimize additional implementation.
 * Use the working prototype approach to try new naming rules for methods.
 * Extend the found solution to the entire public API.
 * Choose first code base to use the new interface hierarchy.
 * Possibly improve new interface hierarchy.
 * Use new interfaces in all Metrics products.

 The other ticket related to an improved metrics-lib API is obsolete with
 this new approach; for reference and as improvement-idea resource: #19640.
 There is a pending new interfaces, which should be only implemented with
 the new hierarchy (if demand permits): #17861.
 The work-in-progress interfaces (and implementations) for webstats could
 be moved into the new hierarchy already, but could also be easily moved
 later.

--

Comment (by iwakeh):

 Replying to [comment:2 karsten]:
 > Sounds great. But let's not ignore all the work we put into #19640. The
 ideas on that ticket might be very relevant for the step "Possibly improve
 new interface hierarchy."

 Yes, that's what I intended too.  I'll rephrase the description a bit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Library]: Review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

#19640: Review and improve interface hierarchy
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:19 karsten]:
 > Let's not close this yet. It's true that #24028 is what we should focus
 on now, but that doesn't mean that all the ideas have become
 invalid/irrelevant. Re-opening.

 Oh, the closing action just meant to state that the discussion moved on.
 This ticket is explicitely referenced in #24028 as a resource.  But I
 really want to avoid to open two discussions of one topic.  Moving to the
 new ticket seems better because there is a better structure how to go
 about things than the summary of (surely valid) ideas here.

 I'd rather close this again for this reason, which doesn't mean the ideas
 here were obsolete.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mtigas):

 Replying to [comment:7 ahf]:
 > You mentioned during the mobile session in Montreal that you were going
 to look into adding support for LZMA and Zstandard for OnionBrowser.
 >
 > Do you think this is going to be an issue for you on iOS?

 Actually, my current guess is that this isn't an issue for iOS at all
 because the dependencies (including tor) get built as static libraries and
 then they're all linked into the app's single executable anyway.

 I'm hoping to take a stab at building with liblzma (in Tor.framework /
 Onion Browser) over the next week or so. So maybe I'll have more specific
 feedback for y'all soon.

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

Re: [tor-bugs] #23845 [Core Tor/Tor]: Document a stable tor main function

[Tor Bug Tracker & Wiki]

#23845: Document a stable tor main function
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-

Comment (by ahf):

 Yep, the fixup looks good.

 Let's await and see what the mobile people say.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Library]: Review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Let's not close this yet. It's true that #24028 is what we should focus on
 now, but that doesn't mean that all the ideas have become
 invalid/irrelevant. Re-opening.

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

Re: [tor-bugs] #24028 [Metrics/Library]: Provide a modernized API for metrics-lib

[Tor Bug Tracker & Wiki]

#24028: Provide a modernized API for metrics-lib
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Sounds great. But let's not ignore all the work we put into #19640. The
 ideas on that ticket might be very relevant for the step "Possibly improve
 new interface hierarchy."

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

Re: [tor-bugs] #20549 [Metrics/CollecTor]: Implement SanitizedBridgeServerDescriptor class that encapsulates the sanitizing logic for bridge server descriptors

[Tor Bug Tracker & Wiki]

#20549: Implement SanitizedBridgeServerDescriptor class that encapsulates the
sanitizing logic for bridge server descriptors
---+--
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID:  #20542 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Replying to [comment:5 karsten]:
 > "While working on this patch I considered taking a different approach
 where we'd include placeholders for parts that we cannot sanitize yet and
 fill them in after finishing to read the original descriptor. This could
 be a `List` to retain order of original lines and where
 we'd keep references to some `StringBuilder`s that we need to sanitize
 after reading. Still something to think about. Let's do that after fixing
 this ugly bug."

 I started an implementation in [https://gitweb.torproject.org/karsten
 /metrics-
 db.git/commit/?h=task-20549=fcfc2b5f2fc02c17896fb40659c4d8e19f5017ad my
 task-20549 branch] that doesn't get us all the way to implementing this
 ticket yet, but which may be a start. Feedback welcome!

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

Re: [tor-bugs] #19647 [Core Tor/Tor]: HS Descriptors should only contain printable ASCII

[Tor Bug Tracker & Wiki]

#19647: HS Descriptors should only contain printable ASCII
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs,  prop224  |  Actual Points:
Parent ID:  #24033| Points:
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by nickm):

 * parent:   => #24033


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

Re: [tor-bugs] #18938 [Core Tor/Tor]: Authorities should reject non-ASCII content in ExtraInfo descriptors

[Tor Bug Tracker & Wiki]

#18938: Authorities should reject non-ASCII content in ExtraInfo descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal tor-dirauth needs-|  Actual Points:
  spec easy  |
Parent ID:  #24033   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:   => #24033


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24033 [Core Tor/Tor]: Require all directory documents to be utf-8

[Tor Bug Tracker & Wiki]

#24033: Require all directory documents to be utf-8
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust-wants needs-proposal
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 There are only a few places that directory documents can have arbitrary
 bytes today, and almost nobody is using them to encode anything besides
 UTF-8.  let's standardize on UTF-8 while we still can.

 Step one will be for the authorities to start rejecting these documents.
 Once they're rejecting them, everybody else can begin rejecting them too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24032 [Core Tor/Tor]: Add comments everywhere that C and Rust must stay in sync

[Tor Bug Tracker & Wiki]

#24032: Add comments everywhere that C and Rust must stay in sync
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, doc
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There are places in protover.rs where, if we were to change our C code
 without a corresponding change, we could break things.  We should mark the
 C and the Rust code in all of those places.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This probably doesn't matter in practice, but: it would be cool if
 protover.rs used a smarter representation for sets of protocol versions
 than `HashSet`.  Maybe a BTreeSet of (low,high) tuples?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24030 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#24030: Wrap types in protover.rs
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our rust protover implementation throws around HashSet and HashMap with
 wild abandon.  We should probably wrap those types in struct declarations,
 to make the intent more clear.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24029 [Core Tor/Tor]: Test all rust functions' behavior when called from C with bad UTF8

[Tor Bug Tracker & Wiki]

#24029: Test all rust functions' behavior when called from C with bad UTF8
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should make sure that the various rust implementations of our protover
 functions will correctly detect and reject strings that aren't UTF-8

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

Re: [tor-bugs] #23845 [Core Tor/Tor]: Document a stable tor main function

[Tor Bug Tracker & Wiki]

#23845: Document a stable tor main function
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-

Comment (by nickm):

 >  isn't it useful in both cases?

 If you can run Tor as a separate process, I think you should probably just
 use exec*() to launch it, rather than having it linked in as part of your
 binary.  I've tried to clarify in a fixup commit.  Does it look better
 now?

 Also, I think I should wait for the mobile people to comment too, so we
 know if they like the API

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

Re: [tor-bugs] #23740 [Core Tor/Tor]: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.1-alpha 290274dbb5428bc5)

[Tor Bug Tracker & Wiki]

#23740: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403:
service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor
0.3.2.1-alpha 290274dbb5428bc5)
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:  prop224 tor-ipv6, tor-hs  |  Actual Points:
Parent ID:  #23493| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by Parckwart):

 Yes, I set ClientUseIPv6, ClientPreferIPv6ORPort and
 ClientPreferIPv6DirPort to 1.

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

Re: [tor-bugs] #23900 [Core Tor/Tor]: Let programs call tor_main with a preconstructed control socket

[Tor Bug Tracker & Wiki]

#23900: Let programs call tor_main with a preconstructed control socket
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-
Changes (by ahf):

 * cc: mtigas (added)


Comment:

 Adding Mike here as well in case he wants to check out if the interface is
 useful for him.

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

Re: [tor-bugs] #23900 [Core Tor/Tor]: Let programs call tor_main with a preconstructed control socket

[Tor Bug Tracker & Wiki]

#23900: Let programs call tor_main with a preconstructed control socket
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-

Comment (by nickm):

 Okay.  I'll wait a little bit to see if the mobile people have any
 comments.

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

Re: [tor-bugs] #17861 [Metrics/Library]: 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/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Be aware of #24028 when starting to work on this task.

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

Re: [tor-bugs] #24028 [Metrics/Library]: Provide a modernized API for metrics-lib

[Tor Bug Tracker & Wiki]

#24028: Provide a modernized API for metrics-lib
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


Comment:

 Setting to accepted, as I'm looking into providing the minimal use-case
 prototype for further discussion.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Library]: Review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Closing as being superseded by #24028.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24028 [Metrics/Library]: Provide a modernized API for metrics-lib

[Tor Bug Tracker & Wiki]

#24028: Provide a modernized API for metrics-lib
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:  metrics-2017
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 In order to provide a more modern API in metrics-lib the interface
 hierarchy needs to be renewed/restructured/changed in backwards compatible
 ways.

 A separate discussion led to the following results:

 * The new interfaces will be placed in new packages, which allows for
 keeping good names and improving other w/o disturbing the existing
 classes.  Suggested packages:
   - org.torproject.metrics.descriptor
   - org.torproject.metrics.descriptor.impl
   - org.torproject.metrics.index
   - org.torproject.metrics.internal

 * Besides improving the general structure consider different return types
 for all time related values and use java.util.Optional for all optional
 values and other java 8 features (as mentioned in summary ticket #23752).


 Possible next steps:

 * Use a small, i.e., limited to few classes/interfaces, prototype example
 for finding the right approach to make these two interface hierarchies
 live beside each other and minimize additional implementation.
 * Use the working prototype approach to try new naming rules for methods.
 * Extend the found solution to the entire public API.
 * Choose first code base to use the new interface hierarchy.
 * Possibly improve new interface hierarchy.
 * Use new interfaces in all Metrics products.

 The other ticket related to an improved metrics-lib API is obsolete with
 this new approach; for reference: #19640.  There is a pending new
 interfaces, which should be only implemented with the new hierarchy (if
 demand permits): #17861.
 The work-in-progress interfaces (and implementations) for webstats could
 be moved into the new hierarchy already, but could also be easily moved
 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] #23816 [Core Tor/Tor]: Use expontial backoff with jitter and/or tune its parameters

[Tor Bug Tracker & Wiki]

#23816: Use expontial backoff with jitter and/or tune its parameters
-+
 Reporter:  nickm|  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:  review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:  SponsorV
-+
Changes (by catalyst):

 * reviewer:   => catalyst


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

[tor-bugs] #24027 [Webpages/Website]: https://www.torproject.org/projects/torbrowser.html.en still says that Tor Browser is built with Gitian

[Tor Bug Tracker & Wiki]

#24027: https://www.torproject.org/projects/torbrowser.html.en still says that 
Tor
Browser is built with Gitian
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

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

[Tor Bug Tracker & Wiki]

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

 * cc: mtigas (added)


Comment:

 Hey Mike,

 You mentioned during the mobile session in Montreal that you were going to
 look into adding support for LZMA and Zstandard for OnionBrowser.

 Do you think this is going to be an issue for you on iOS?

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

Re: [tor-bugs] #23777 [Core Tor/Tor]: tor spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#23777: tor spends a lot of time in malloc/free
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * Attachment "tor.heaptrack.flamegraph.sanitized.svg.gz" added.

 tor middle relay heaptrack allocations flamegraph

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

Re: [tor-bugs] #23848 [Core Tor/Tor]: Replace all exit() calls with return code style

[Tor Bug Tracker & Wiki]

#23848: Replace all exit() calls with return code style
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, 0.3.5-deferrable,|  Actual Points:
  review-group-24|
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 Thanks for the review!  I've commented on those issues and merged.

 > `c82cc8acb5aa43b3d96490d927dcc622f2c825e3` looks good, but maybe we
 should remove this code if we notice that it is never used during this
 release cycle?

 I've added an  comment about that, but I'm not 100% sure we should: if
 there is some weird bug that makes us not actually exit, I bet it will be
 hard to find.  In that case, it would be good to make sure that Tor didn't
 just keep running once it had been asked to stop.

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

Re: [tor-bugs] #23848 [Core Tor/Tor]: Replace all exit() calls with return code style

[Tor Bug Tracker & Wiki]

#23848: Replace all exit() calls with return code style
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, 0.3.5-deferrable,|  implemented
  review-group-24|  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => 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

[tor-bugs] #24026 [Webpages/Website]: Update "donate options" page

[Tor Bug Tracker & Wiki]

#24026: Update "donate options" page
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://www.torproject.org/donate/donate-options.html.en

 TOP MENU (match items/links to top menu at donate.torproject.org)
 - remove "HOME" and "CONTACT"
 - Keep ABOUT
 - Add "QUESTIONS?" https://donate.torproject.org/donor-faq

 FOOTER
 - update mission to:
 The Tor Project is a US 501(c)(3) non-profit organization advancing human
 rights and freedoms by creating and deploying free and open source
 anonymity and privacy technologies, supporting their unrestricted
 availability and use, and furthering their scientific and popular
 understanding.

 - update privacy policy link to: https://donate.torproject.org/privacy-
 policy
 - update donor FAQ link to: https://donate.torproject.org/donor-faq

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24025 [Core Tor/Tor]: Log warning: Inconsistent ed25519 identities in the nodelist

[Tor Bug Tracker & Wiki]

#24025: Log warning: Inconsistent ed25519 identities in the nodelist
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-relay
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Less than 2 hours ago, I got this warning on both my tor relays.

 This is most likely due to the relay that got flagged `NoEdConsensus`:
 https://atlas.torproject.org/#details/F01D8D6448C8B883D8ACD08D3AA7789D5EE38B7B

 This was triggered because the key in the descriptor (ri) and the
 microdesc (md) aren't the same. See `node_get_ed25519_id()`. Because this
 can happen "naturally", I wonder if we should bring down that warning to
 maybe protocol warn or info? Because else, we got 6.5k relays having that
 warning today.

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

Re: [tor-bugs] #22840 [Core Tor/Tor]: Implement protover in Rust

[Tor Bug Tracker & Wiki]

#22840: Implement protover in Rust
-+-
 Reporter:  chelseakomlo |  Owner:
 |  chelseakomlo
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, rust-pilot, review-  |  implemented
  group-24   |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

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


Comment:

 As discussed on IRC: I've revised protover.c to have a smaller diff,
 disabled the tests that only looked at static functions inside protover.c,
 and added copyright notices.  With that, it's all merged to master!  I'll
 be opening tickets for other issues/questions/concerns.

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

Re: [tor-bugs] #23997 [Applications/Tor Browser]: Add Tor Browser Manual links for new locales

[Tor Bug Tracker & Wiki]

#23997: Add Tor Browser Manual links for new locales
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 The patch 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] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

[Tor Bug Tracker & Wiki]

#23930: Tor Browser 7.x for Mac crashes at startup
-+-
 Reporter:  wga  |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201710  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  assigned => needs_information


Comment:

 Replying to [comment:26 wga]:
 > I removed the fonts again, started Tor Browser, empty
 "system.fonts.whitelist" in about:config.

 I am a little confused by this. Are you able to reproduce the startup
 crash by removing some fonts from your system? If so, can you provide
 steps so we can do the same thing on our OSX systems?

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

Re: [tor-bugs] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

 * status:  accepted => needs_review
 * reviewer:   => asn


Comment:

 It was actually more straight forward than I thought.

 Instead of keeping a star time of current round and time period and what
 not, we actually don't need to do such a thing but rather use the voting
 schedule static object instead. It is updated everytime we get a new
 consensus so using it is as close as we get to the latest.

 Thus, now the SR subsystem only uses that object to compute it stuff.

 Unit test is broken because we have an issue of timestamp being off
 because one function used to take a timestamp "now" but now it only uses
 the voting schedule timings so it needs to be fixed. However, I want to
 know if the approach seems sensible before going further.

 See branch: `ticket23623_032_01`

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

Re: [tor-bugs] #23965 [Metrics/Website]: 500 internal server error when trying to print svg from metrics graph

[Tor Bug Tracker & Wiki]

#23965: 500 internal server error when trying to print svg from metrics graph
-+---
 Reporter:  arma |  Owner:  karsten
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Regarding the issue you describe about x axis labels getting cut off a bit
 early: the reason is that we're changing axis labels without changing
 margins. I just fixed that by increasing the right margin a bit. This is
 unrelated to the output format. If you run into similar issues, just file
 a ticket, and we can tweak such parameters.

 Regarding the suspected differences between PDF and SVG output: I just
 created a PDF and an SVG file locally, and they look almost exactly the
 same, except that the SVG had a font problem with the 0 on the y axis. But
 other than that I couldn't spot any differences. To me this means that
 ImageMagick's `convert` is to blame for either not parsing the PDF input
 correctly or not creating an adequate SVG output.

 Can you maybe try out [https://packages.debian.org/stretch/libreoffice-
 pdfimport LibreOffice's PDF import] to import the PDF file directly?

 Otherwise we might consider replacing SVG with another format rather than
 just removing it. The [http://ggplot2.tidyverse.org/reference/ggsave.html
 `ggsave` documentation] says we can produce: ''"eps", "ps", "tex"
 (pictex), "pdf", "jpeg", "tiff", "png", "bmp", "svg" or "wmf" (windows
 only).'' Untested, subject to similar dependency issues that we're seeing
 with SVG right now! If you have any preference for or against one of the
 formats, please say so!

 Another option would be to add a new parameter for the resolution and put
 a "PNG (high-resolution) link on the website for 2 times or 4 times the
 current resolution.

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

Re: [tor-bugs] #23848 [Core Tor/Tor]: Replace all exit() calls with return code style

[Tor Bug Tracker & Wiki]

#23848: Replace all exit() calls with return code style
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, 0.3.5-deferrable,|  Actual Points:
  review-group-24|
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 `09562421589c055a6cb49c802a248f727390d158` and
 `35746a9ee75608e7b2393e4519adca602bf2615f`  looks good.

 In `78cbced45cd244c8aab84e6fb8087b852769f5bc` the documentation string
 around the renamed function `tell_event_loop_to_run_external_code()` is
 still talking about finishing instead of running external code.

 `f0c3b6238168e351835fdc64b5c93b84d6528870` looks good.

 `c82cc8acb5aa43b3d96490d927dcc622f2c825e3` looks good, but maybe we should
 remove this code if we notice that it is never used during this release
 cycle?

 `9bafc3b1efd64b19695cd78fb51070ff8d3939f5`,
 `c247a2df6b7f6b5d997ef9e5ccc25eaaf3918db8`,
 `853e73e815c1be9c9e533160f803de56e7d21147`,
 `1df43aff41eb8198712af0aa14ec2d574b26682c`,
 `3c99b810a46c2aba2ea4108018e78bc8f6a19013`,
 `90daa28df403472d4a6aa7067ce6ab3264cdbe55`,
 `c4a07b261b552c39b64c8d47f1ba75f4bb4f37d6`, and
 `a62f59f000f05ac5f5a7a22387007a1b8c2ee2a4` all  looks good.

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

Re: [tor-bugs] #23845 [Core Tor/Tor]: Document a stable tor main function

[Tor Bug Tracker & Wiki]

#23845: Document a stable tor main function
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 `72b5e4a2db4282002fe50e11c2b8a79e108d30f8` looks fine.

 In `8dd957cb8ae5c82da576e7720b1bb3b846089f98` the comment:

 {{{
  * This interface is intended for use by programs that need to link Tor as
  * a library, and launch it in a separate thread.  If you have the ability
  * to run Tor as a separate process, you probably should.
  **/
 }}}

 reads a bit to me that this API is only useful if you have Tor running in
 a thread (but not as a process) - isn't it useful in **both** cases?

 Otherwise this commit looks good as well. Nice with a documented, public,
 header! :-)

 `a7c126f65438a8dcde5663a731f0f8528e480bcc` looks good.

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

Re: [tor-bugs] #24004 [Core Tor/Chutney]: Chutney should show tor logs when tor fails to launch

[Tor Bug Tracker & Wiki]

#24004: Chutney should show tor logs when tor fails to launch
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * component:  Core Tor/Tor => Core Tor/Chutney


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

Re: [tor-bugs] #24002 [Core Tor/Tor]: Check for ed25519 key is inverted in pick_intro_point()

[Tor Bug Tracker & Wiki]

#24002: Check for ed25519 key is inverted in pick_intro_point()
-+
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #23493   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merged to 0.3.2 and forward.

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

Re: [tor-bugs] #23840 [Applications/Tor Browser]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:15 cypherpunks]:
 > >https://coinhive.com/#captcha
 >
 >  off spreading your shitty monero miner. Captcha mustn't require
 javascript.
 Calm down please, such proposals should be met with real arguments (e.g.
 it is extremely slow when JIT is disabled, it drains batteries, ...etc)
 and not insults.

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

Re: [tor-bugs] #23900 [Core Tor/Tor]: Let programs call tor_main with a preconstructed control socket

[Tor Bug Tracker & Wiki]

#23900: Let programs call tor_main with a preconstructed control socket
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, review-group-24  |  Actual Points:
Parent ID:  #23684   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 `5bcd8dc5c482da4da71402cd06b0ecc709f05493`,
 `4eb5753bd29b24fd5a523499add35a6214293cd9`,
 `f0daaf8d60be8bfcfaa99e3a878cd90967a84bb0`, and
 `f1bf9bf8198fcfaf078fdc12eb2ad5adf1901d29` All  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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by asn):

 Just had time to read the [tor-dev] thread. +1 for 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] #24012 [Metrics/Onionoo]: Fix NullPointerExceptions from accessing descriptor parts that may be null

[Tor Bug Tracker & Wiki]

#24012: Fix NullPointerExceptions from accessing descriptor parts that may be 
null
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


Comment:

 Released and working (cf. [https://lists.torproject.org/pipermail/tor-
 dev/2017-October/012526.html announcement]).
 Closing.

 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] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Whatever is easier. That's why I wrote ExoneraTor first, because it is so
 much smaller. And metrics-web is not on fire at the moment. Whatever is
 easier.

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

Re: [tor-bugs] #24022 [Core Tor/Tor]: Make clients avoid retrying slow exits when they time out

[Tor Bug Tracker & Wiki]

#24022: Make clients avoid retrying slow exits when they time out
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, tbb-usability,  |  Actual Points:
  performance, tbb-needs |
Parent ID:  #21394   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:2 teor]:
 > Maybe we could fix that at the client level by keeping an exit failure
 cache?

 Be very careful of a destination dns server that chooses which requests to
 time out on, with the goal of shifting users away from certain exits
 towards others.

 Some amount of that attack is inevitably possible, since if you can't
 reach the site from one exit then you'll end up reaching it from another.

 But any design where the destination dns server can set cross-circuit
 state on the client makes me itch.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by callumw):

 Okay I see what is needed now. I think I dove into this ticket without
 fully understanding it. Cheers.

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

Re: [tor-bugs] #23840 [Applications/Tor Browser]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 >https://coinhive.com/#captcha

 Fuck off spreading your shitty monero miner. Captcha mustn't require
 javascript.

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

Re: [tor-bugs] #23841 [Internal Services/Service - trac]: Some asshole deleted cypherpunks account

[Tor Bug Tracker & Wiki]

#23841: Some asshole deleted cypherpunks account
--+
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 You meant it has been recreated. But before recreation there is an amount
 of time when the account is not recreated. It is possible to remove an
 account by having a bot that tries to login periodically and deletes the
 account. Given that the period of the check is just a bit longer an
 adversary can effectively make the account unusable. You need to hardcode
 the check disallowing deletion or changing the password of the account
 with the name "cypherpunks". It's just 2 if in the right places!

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

Re: [tor-bugs] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 I can also look into this metrics-web issue here first to make instances
 'reproducible'.

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

Re: [tor-bugs] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 From talking to iwakeh: we might want to look into switching ExoneraTor
 and then metrics-web from Tomcat to Jetty, and maybe that will magically
 resolve the JSTL mystery.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24024 [Webpages/Website]: Potentially misleading illustrations suggest that Tor doesn't stick to a single guard node in the overview page

[Tor Bug Tracker & Wiki]

#24024: Potentially misleading illustrations suggest that Tor doesn't stick to a
single guard node in the overview page
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://www.torproject.org/about/overview.html.en

 The entry node in the third image is different from the one in the second
 image

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

Re: [tor-bugs] #23840 [Applications/Tor Browser]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tokotoko):

 Replying to [comment:13 cypherpunks]:
 > Replying to [comment:12 tokotoko]:
 > > Replying to [comment:10 tokotoko]:
 > > > I got this on etsy.com right now, it's not 50/50 lottery.
 > > it's 50/50 lottery*
 > This ticket is about the Google captcha failing and giving an error
 "Your computer or network may be sending automated queries...", are you
 really sure that it gave you that error (which is what this ticket is
 about)?
 I attached image with error with the same text from google recaptcha, so,
 yes, i am sure.

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

Re: [tor-bugs] #23840 [Applications/Tor Browser]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tokotoko):

 * Attachment "1.png" added.

 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