Re: [tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by arma):

 * cc: asn, dgoulet (added)


Comment:

 Replying to [comment:6 maqp]:
 > I'm using Tor 0.3.3.2-alpha (that should support v3 Onion Services), so
 I'd assume the revision counter update not happening automatically is
 related to feature not yet in Stem.
 >
 > On a side note, if Stem indeed needs to manage persistent revision
 counter, it would be very helpful if developers could access them via
 something like response.rev_counter and provide them as arguments to
 create_ephemeral_hidden_service, kind of like how persistent keys can be
 provided.

 I am cc'ing dgoulet and asn so they know about this ticket (and can think
 about whether the above is an issue in 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] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by maqp):

 Glad to hear you're feeling better atagar! Hi everyone,

 So the bug is related to applications where the Onion Service uses
 persistent key but where the service goes online and offline frequently.
 Examples of those include file transmission applications like OnionShare,
 and instant messaging like Ricochet or TFC (that I'm working on).

 During development I noticed that by re-using a few times the same long
 term v3 ED25519 private key (passed to
 controller.create_ephemeral_hidden_service), would cause Stem to raise

 stem.OperationFailed(message = 'Failed to upload our hidden service
 descriptor to %s' % ', '.join(failures)) stem.OperationFailed: Failed to
 upload our hidden service descriptor to
 F4263275CF54A6836EE7BD527B1328836A6F06E1 (UPLOAD_REJECTED)... 

 I started to investigate this: I doubled delay between launched services,
 and at the point of one hour, the UPLOAD_REJECTED stopped happening.
 Example code and output here:
 https://gist.github.com/maqp/4817a4d1e71a27536ab9810d75e7b6c1

 The issue happens even with latest Stem dev build that includes
 https://gitweb.torproject.org/stem.git/commit/?id=53e73ad

 Now this is a problem with the applications that are online for short
 periods at a time. Say the computer or client crashes at start. User
 shouldn't have to wait for an hour before they can relaunch the software.

 ---

 I have only skimmed Tor's source code and documentation, but it is my
 understanding that the descriptor is uploaded with something called the
 revision counter. From what I've read I've understood those mean that
 descriptor for same service can be uploaded frequently if the bundled
 revision counter is incremented every time. If the revision counter is not
 incremented, new descritor is only accepted after one hour when the
 descriptor expires.

 I'm using Tor 0.3.3.2-alpha (that should support v3 Onion Services), so
 I'd assume the revision counter update not happening automatically is
 related to feature not yet in Stem.

 On a side note, if Stem indeed needs to manage persistent revision
 counter, it would be very helpful if developers could access them via
 something like response.rev_counter and provide them as arguments to
 create_ephemeral_hidden_service, kind of like how persistent keys can be
 provided.

 ---

 The last thing I'd like to understand is the key expansion and blinding.
 The private key's expansion function in the Gist I posted above was
 modified from Tor's testing code. It works but I'm not sure if developers
 should be doing all that: It's probably something Stem should handle, at
 least with some helper function.

 Related to this is the key blinding aspect. It is my understanding the
 Onion site crawling has been solved by uploading blinded (sub?)keys inside
 the descriptor. It is not at all clear whether this is the job of
 application developers, Stem, or Tor 0.3.3.

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

Re: [tor-bugs] #25322 [Internal Services/Tor Sysadmin Team]: Finding a way to serve search.tpo for the different portals

[Tor Bug Tracker & Wiki]

#25322: Finding a way to serve search.tpo for the different portals
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Sounds like something to get the ux team in on discussing.

 I'd be tempted to move this to the website component too, since it's not
 really a sysadmin thing at this point -- it's still a "how do we want our
 website service to behave" thing.

 One option to explore is whether a proxypass approach can work -- the
 frontend webserver would pass requests to the search backend if they are
 for certain urls.

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

Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  GeorgKoppen201802, TorBrowserTeam201802|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:10 gk]:
 > For those following along at home:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 has all the details.
 Why don't you file your findings under
 https://bugzilla.mozilla.org/show_bug.cgi?id=1257268 to allow Mozillians
 to work on them in parallel?

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

Re: [tor-bugs] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy doc   |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Tor isn't really designed to pin exits like this. You could try using
 NoIsolateDestAddr on your SOCKSPort, but it really isn't safe to use it
 for general browsing.

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

Re: [tor-bugs] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy doc   |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+

Comment (by LittleTorFanAnnie):

 OK, if the error is in the docs and TrackHostExits isn't intended to
 provide that behavior, then is there another way to solve the problem?

 The situation is that I visit a web page that generates a link which is
 just an IP (and not the IP associated with that page).  I need to open
 that link with Tor using the same IP used to visit the page, or it won't
 work  - because it detects the connecting IP.

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

Re: [tor-bugs] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-log, easy, intro, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport-  |
  maybe  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 sounds 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] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by yawning):

 Replying to [comment:4 atagar]:
 > Hi all! Sorry about the delay. Got nailed by a nasty stomach bug that
 took me out of commission for most of February.
 >
 > Finally took a peek and unless I'm missing something v3 hidden service
 support doesn't actually require anything on Stem's side. Added a little
 documentation and an integ test - how does this look?

 That is correct.  The original `ADD_ONION` syntax was deliberately crafted
 with the eventual v3 service support in mind.

 > https://gitweb.torproject.org/stem.git/commit/?id=53e73ad

 Looks fine to me on cursory inspection, but I'm not a python person.

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

Re: [tor-bugs] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-log, easy, intro, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport-  |
  maybe  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I'd like it at notice, so we find out if Tor gets stuck after receiving a
 404.
 Maybe we can say "that's ok", or "trying another directory server".

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

Re: [tor-bugs] #7961 [Core Tor/Tor]: Publish transports that bind on IPv6 addresses

[Tor Bug Tracker & Wiki]

#7961: Publish transports that bind on IPv6 addresses
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, ipv6 anticensorship  |  Actual Points:
  needs-spec refactor|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-bridge, pt, ipv6 anticensorship needs-spec refactor easy
 => tor-bridge, pt, ipv6 anticensorship needs-spec refactor
 * status:  new => needs_information


Old description:

> Currently, `pt_get_extra_info_descriptor_string()` uses
> `router_pick_published_address()` to retrieve our external IP address so
> that it can write it in our extra-info descriptor along with the TCP port
> that our transport listens on.
>
> The bad news are that `router_pick_published_address()` only returns IPv4
> addresses, and we will probably have to refactor it, or do something like
> this:
> https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775
> for IPv6 addresses.
>
> Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we
> implement it, and how complex the changes are going to be.

New description:

 Currently, `pt_get_extra_info_descriptor_string()` uses
 `router_pick_published_address()` to retrieve our external IP address so
 that it can write it in our extra-info descriptor along with the TCP port
 that our transport listens on.

 The bad news are that `router_pick_published_address()` only returns IPv4
 addresses, and we will probably have to refactor it, or do something like
 this:
 ~~
 
https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775
 ~~
 (wrong commit reference)
 for IPv6 addresses.

 Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we
 implement it, and how complex the changes are going to be.

--

Comment:

 This is not an easy patch.

 Since you've posted implementation questions on two different tickets, I'm
 going to leave you to answer some of the detailed pluggable transport
 questions on this ticket.

 There are four cases in pt_get_extra_info_descriptor_string():
 1. the pluggable transport has told us it is listening on a specific IPv4
 address
   * this case is already handled correctly
 2. the pluggable transport has told us it is listening on a specific IPv6
 address
   * this case is handled correctly for transports that are IPv6-only
   * one address is used for transports that are dual-stack, but which one?
   * do any current pluggable transports (PTs) supply their specific IPv6
 address?
   * what do transports with an IPv4 and an IPv6 address do?
   * how does Tor handle what they do?
 * transport_t only has one address/port field, so dual stack
 transports are not supported
 3. the pluggable transport has told us it is listening on all IPv4
 addresses
   * this case is already handled correctly
 4. the pluggable transport has told us it is listening on all IPv6
 addresses
   * do any current pluggable transports (PTs) say they are listening on
 all IPv6 addresses?
   * how do we distinguish between IPv4 only, IPv4/IPv6 and IPv6 only
 transports?
 * what do transports with an IPv4 and an IPv6 address do?
   * do they give the address as `0.0.0.0`, `::`, or `[::]`?
 * how does Tor handle what they do?
   * transport_t only has one address/port field, so dual-stack
 transports may be ambiguous or not supported
 * what do transports with an IPv6 address do?
   * do they give the address as `0.0.0.0`, `::`, or `[::]`?
 * how does Tor handle what they do?
   * Tor assumes that all null addresses are IPv4

 You can focus on PTs supported by Tor Browser and BridgeDB (obfs3 and
 obfs4, both implemented by https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/ ).

 Replying to [comment:7 fristonio]:
 > I would like to work on this. Do I need to create a wrapper around
 `router_pick_published_address()` which will take family as an argument
 and return the address as IPv4 or IPv6 accordingly, if it exists and
 return -1 otherwise?

 Once you've answered the questions for case 4, you'll know if you need to
 do this or not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 

Re: [tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by atagar):

 * status:  reopened => needs_information


Comment:

 Hi all! Sorry about the delay. Got nailed by a nasty stomach bug that took
 me out of commission for most of February.

 Finally took a peek and unless I'm missing something v3 hidden service
 support doesn't actually require anything on Stem's side. Added a little
 documentation and an integ test - how does this look?

 https://gitweb.torproject.org/stem.git/commit/?id=53e73ad

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

Re: [tor-bugs] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-log, easy, intro, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport-  |
  maybe  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Ah ha -- this isn't a time issue, it's an issue of whether that dir
 authority has a consensus it's willing to give you.

 This response from dizum was added in #20511.

 And it could plausibly come from a dir auth that's been down for a while
 and then comes back and doesn't have a fresh consensus to serve quite yet.

 I think teor is right that there's nothing the relay operator can do when
 this happens. I'm tempted to wonder if we can move it to info, since
 notice will still make some people worried. But on the flip side, I'd only
 want to move it to info if we're confident Tor will always tolerate the
 situation well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25417 [Core Tor/Tor]: HSFETCH support for v3 Hidden Services

[Tor Bug Tracker & Wiki]

#25417: HSFETCH support for v3 Hidden Services
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi David, just realized that we probably don't have a tracking ticket for
 our lack of v3 HSFETCH support. Your
 [https://gitweb.torproject.org/torspec.git/commit/?id=59d6453 recent spec
 update] made reference to #20699 but that's no longer open so filing
 another one for 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] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-log, easy, intro, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport-  |
  maybe  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Is it always dizum that gives you this issue? Or does it happen with other
 dir auths 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

Re: [tor-bugs] #7961 [Core Tor/Tor]: Publish transports that bind on IPv6 addresses

[Tor Bug Tracker & Wiki]

#7961: Publish transports that bind on IPv6 addresses
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, ipv6 anticensorship  |  Actual Points:
  needs-spec refactor easy   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by fristonio):

 I would like to work on this. Do I need to create a wrapper around
 `router_pick_published_address()` which will take family as an argument
 and return the address as IPv4 or IPv6 accordingly, if it exists and
 return -1 otherwise?

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

Re: [tor-bugs] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-log, easy, intro, 033-backport,  |  Actual Points:
  032-backport, 031-backport, 029-backport-  |
  maybe  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:   =>
 tor-log, easy, intro, 033-backport, 032-backport, 031-backport, 029
 -backport-maybe
 * version:  Tor: unspecified =>
 * points:   => 0.1
 * milestone:   => Tor: 0.3.4.x-final


Comment:

 This is a problem with the remote relay, not with your relay. You can
 contact the operator of that relay and let them know if you want.

 I think we should downgrade this message from warn to notice, because
 there's nothing that relay operators or clients can do about 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] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.3.2-alpha
 Severity:  Blocker   | Resolution:
 Keywords:  tor-dirauth, crash, 033-must  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => tor-dirauth, crash, 033-must
 * priority:  Medium => High
 * points:   => 0.5
 * severity:  Normal => Blocker


Comment:

 We can't release 0.3.3 with an authority crash bug.

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

Re: [tor-bugs] #25008 [Core Tor/Tor]: Call protocol_list_supports_protocol less often to save time and allocation

[Tor Bug Tracker & Wiki]

#25008: Call protocol_list_supports_protocol less often to save time and 
allocation
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport?, malloc, performance,  |  implemented
  protover, review-group-31  |  Actual Points:
Parent ID:  #23777   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 This patch triggers a crash on authorities when a relay stops advertising
 a protocol list (#25415).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25416 [Core Tor/Tor]: [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.

[Tor Bug Tracker & Wiki]

#25416: [warn] Received http status code 404 ("Consensus is too old") from 
server
'194.109.206.212:80' while fetching consensus directory.
--+--
 Reporter:  toralf|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 the local time is ok :

 {{{
 date -u
 Sat Mar  3 16:18:01 UTC 2018

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

Re: [tor-bugs] #24740 [Core Tor/Tor]: Tor launches two requests for authority certificates on first bootstrap

[Tor Bug Tracker & Wiki]

#24740: Tor launches two requests for authority certificates on first bootstrap
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bootstrap, tor-bandwidth, easy,  |  Actual Points:
  intro  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * version:   => Tor: 0.2.9.1-alpha


Comment:

 Replying to [comment:2 fristonio]:
 > Which part of the codebase is this hinted request made in, what I got
 from the code is that when the bootstrapping process starts Tor parses the
 certificates first from the cached-certs file.

 When Tor first bootstraps, this file does not exist, so there are no
 cached certificates.
 So at this step, Tor does nothing.

 > Then Tor parses microdesc-consensus from the disk and sets the current
 consensus based on them

 When Tor first bootstraps, this file does not exist, so there is no cached
 consensus.
 So at this step, Tor downloads the consensus:
 https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n961

 Then, once it receives the consensus, it sends a request for the certs to
 the same directory mirror that it just got the consensus from, using the
 fingerprint of that directory mirror as a hint:
 https://gitweb.torproject.org/tor.git/tree/src/or/directory.c#n2614
 https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n1887

 > during this process it launches certificate fetch if not enough
 certificate are available to validate the consensus.

 This step always happens on first bootstrap, because there are no cached
 certificates.

 > Then it reloads the router list after this we set up periodic callbacks.
 I couldn't locate where the hinted request is made. Any help :)

 The periodic callbacks also download certificates:
 https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n1242
 This is the source of the duplicate certificate fetch.

 We need to move this line:
 https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n1242

 To here:
 https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n956

 With a comment that says that either:
 * we are waiting for certificates, and we've launched a certificate
 download
 * we are waiting for a consensus, and we've launched a consensus download,
 which will launch a certificate download when it completes

 This is a bugfix on #18963 in 0.2.9.1-alpha.
 But it's only a load issue, so it's not a backport candidate.

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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 Reporter:  karsten  |  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 dcf):

 Replying to [comment:7 irl]:
 > Replying to [comment:6 dcf]:
 > > for one transport, the top countries that use that transport
 >
 > Currently the arguments that are passed to the graphing backend are only
 date ranges and countries, so plotting for any one thing that isn't a
 country won't be supported. In the new approach, would the CSV for all
 countries still be usable for this? If not, we should consider what other
 similar use cases we might be breaking.

 I did take a look at the CSV for all countries (i.e.,
 https://metrics.torproject.org/userstats-bridge-
 combined.csv?start=2017-12-03=2018-03-03=all, what you get
 when you click "CSV" on https://metrics.torproject.org/userstats-bridge-
 combined.html without selecting a country). However, it only gives you the
 sum of all countries together, not the results for each country
 individually:
 {{{
 date,users
 2017-12-03,37760
 2017-12-04,39172
 2017-12-05,40447
 ...
 }}}
 If the "all" CSV link had all the countries in separate rows, then the new
 approach would work for this use case.

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

Re: [tor-bugs] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy doc   |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  doc-maybe => easy doc
 * points:   => 0.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] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc-maybe  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:4 nickm]:
 > TracExitHosts is not supposed to make every destination use the same
 website: it is supposed to make it so that every time you go to the _same_
 destination, you get the _same_ website.
 >
 > Is this something that the documentation should be more clear about?

 Yes. The man page right now says "For each value in the comma separated
 list, Tor will track recent connections to hosts that match this value and
 attempt to reuse the same exit node for each. [...] If one of the values
 is just a '.', it means match everything." To me that means every time you
 get a match, you try to reuse the same exit node as for previous matches,
 and . is always a match.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Ok, 0.3.2.10 runs ok. Sounds like it's an 0.3.3 bug.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

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


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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * version:   => Tor: 0.3.3.2-alpha
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Looks like bug #25008 went into 0.3.3.2-alpha.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Yep, I edited node_supports_ed25519_link_authentication() to print out
 what it's returning, and it is indeed returning 1 because
 supports_ed25519_link_handshake_compat=1.

 ahf points to commit 7e504515b3 which I think is the right commit to look
 at.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Confirmed. I added this patch:
 {{{
 diff --git a/src/or/dirserv.c b/src/or/dirserv.c
 index 0f47a83..0a9420f 100644
 --- a/src/or/dirserv.c
 +++ b/src/or/dirserv.c
 @@ -3393,6 +3393,7 @@ dirserv_single_reachability_test(time_t now,
 routerinfo_t

if (options->AuthDirTestEd25519LinkKeys &&
node_supports_ed25519_link_authentication(node, 1)) {
 +tor_assert(router->cache_info.signing_key_cert);
  ed_id_key = >cache_info.signing_key_cert->signing_key;
} else {
  ed_id_key = NULL;
 }}}

 and it triggers the assert.

 {{{
 (gdb) up
 #2  0x77c34316 in dirserv_single_reachability_test (
 now=, router=0x7fffeb96c880) at
 src/or/dirserv.c:3396
 3396tor_assert(router->cache_info.signing_key_cert);
 (gdb) print router->cache_info
 $1 = {signed_descriptor_body = 0x0, annotations_len = 57,
   signed_descriptor_len = 1648,
   signed_descriptor_digest =
 "õÃ\200\227:Ë\226\225\217Õv\035Pk¯­\215\202³ó",
   identity_digest = "\fÚ0ÍÛRku>K§\t8p;ïl´¸á", published_on = 1520082806,
   extra_info_digest = "\216\214·¬ Æ1Su}m\203ÆÅVÔÑõ\217¤",
   extra_info_digest256 = '\000' , signing_key_cert =
 0x0,
   ei_dl_status = {next_attempt_at = 0, n_download_failures = 0 '\000',
 n_download_attempts = 0 '\000', schedule = DL_SCHED_GENERIC,
 want_authority = DL_WANT_ANY_DIRSERVER,
 increment_on = DL_SCHED_INCREMENT_FAILURE,
 last_backoff_position = 0 '\000', last_delay_used = 0},
   saved_location = SAVED_IN_CACHE, saved_offset = 39789237,
   routerlist_index = 324, last_listed_as_valid_until = 0, do_not_cache =
 0,
   is_extrainfo = 0, extrainfo_is_bogus = 0, send_unencrypted = 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] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I added a log message, and node_supports_ed25519_link_authentication() is
 indeed returning 1.

 Theory: *this* descriptor doesn't have an ed25519 key, but a previous one
 did. So in dirserv_single_reachability_test(), "router" doesn't have an
 ed25519 key, but node_supports_ed25519_link_authentication(node) doesn't
 look at router, it looks at node, and node *does* have an ed25519 key,
 from a previous descriptor that we learned it from.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{
 Mar 03 15:35:52.252 [info] dirserv_router_get_status(): Descriptor from
 router $0CDA30CDDB526B753E4BA70938703BEF6CB4B8E1~matress at 94.16.123.176
 has no Ed25519 key, when we previously knew an Ed25519 for it. Ignoring
 for now, since Ed25519 keys are fairly new.
 }}}

 {{{
 (gdb) print *router
 [...]
   omit_from_vote = 0, pv = {protocols_known = 1, supports_extend2_cells =
 1,
 supports_ed25519_link_handshake_compat = 0,
 supports_ed25519_link_handshake_any = 0, supports_ed25519_hs_intro =
 0,
 }}}

 So node_supports_ed25519_link_authentication() ought to be returning 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] #24805 [Core Tor/Fallback Scripts]: Update fallback whitelist and blacklist

[Tor Bug Tracker & Wiki]

#24805: Update fallback whitelist and blacklist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #24786 | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 An operator wants this relay '''taken off the whitelist and put on the
 blacklist:'''
 9FBEB75E8BC142565F12CBBE078D63310236A334
 It is being shut down.
 See #25414.

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

Re: [tor-bugs] #25414 [Core Tor/Fallback Scripts]: Fallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A334

[Tor Bug Tracker & Wiki]

#25414: Fallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A334
---+---
 Reporter:  svengo |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback-change|  Actual Points:
Parent ID:  #24805 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:   => #24805
 * milestone:   => Tor: 0.3.4.x-final


Comment:

 We'll remove it when we next update the list. We usually update the list
 every 6-12 months.

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

Re: [tor-bugs] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{
 (gdb) up
 #4  0x77c34108 in dirserv_single_reachability_test (
 now=, router=0x7fffeb96c880) at
 src/or/dirserv.c:3405
 3405  chan = channel_tls_connect(_addr, router->or_port,
 (gdb) print ed_id_key
 $5 = (const ed25519_public_key_t *) 0x20
 (gdb) print router->cache_info.signing_key_cert
 $6 = (struct tor_cert_st *) 0x0
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25415 [Core Tor/Tor]: moria1 seg faults on testing relay reachability

[Tor Bug Tracker & Wiki]

#25415: moria1 seg faults on testing relay reachability
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 [...]
 Mar 03 15:09:16.138 [notice] This version of Tor (0.3.3.3-alpha-dev) is
 newer than any recommended version, according to the directory
 authorities. Recommended versions are:
 
0.2.5.16,0.2.5.17,0.2.9.14,0.2.9.15,0.3.1.9,0.3.1.10,0.3.2.8-rc,0.3.2.9,0.3.2.10,0.3.3.1-alpha,0.3.3.2-alpha,0.3.3.3-alpha

  T= 1520107762
 Tor 0.3.3.3-alpha-dev (git-6d44cf66c7cca6e0) died: Caught signal 11
 ../git/src/or/tor(+0x18d2aa)[0x7f7b748152aa]
 ../git/src/or/tor(tor_memeq+0x27)[0x7f7b748355e7]
 ../git/src/or/tor(tor_memeq+0x27)[0x7f7b748355e7]
 ../git/src/or/tor(router_ed25519_id_is_me+0x2a)[0x7f7b7472472a]
 ../git/src/or/tor(connection_or_connect+0x1a8)[0x7f7b747a1ad8]
 ../git/src/or/tor(channel_tls_connect+0xaa)[0x7f7b74758aaa]
 ../git/src/or/tor(dirserv_single_reachability_test+0xa8)[0x7f7b747c4108]
 ../git/src/or/tor(routerlist_descriptors_added+0x90)[0x7f7b7472b0a0]
 ../git/src/or/tor(router_load_routers_from_string+0x438)[0x7f7b747336a8]
 ../git/src/or/tor(+0xab81c)[0x7f7b7473381c]
 ../git/src/or/tor(router_reload_router_list+0x26)[0x7f7b74733926]
 ../git/src/or/tor(do_main_loop+0x2fb)[0x7f7b746db17b]
 ../git/src/or/tor(tor_run_main+0x29b)[0x7f7b746db88b]
 ../git/src/or/tor(tor_main+0x43)[0x7f7b746d61a3]
 ../git/src/or/tor(main+0x19)[0x7f7b746d6039]
 /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f7b731f8d1d]
 ../git/src/or/tor(+0x4df49)[0x7f7b746d5f49]
 Aborted
 }}}

 {{{
 #0  0x77ca55e7 in tor_memeq (a=,
 b=, sz=)
 at src/common/di_ops.c:110
 #1  0x77b9472a in router_ed25519_id_is_me (id=)
 at src/or/routerkeys.c:1248
 #2  0x77c11ad8 in connection_or_connect (_addr=0x7fffe180,
 port=443, id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z",
 ed_id=0x20, chan=0x7ecb8230) at src/or/connection_or.c:1210
 #3  0x77bc8aaa in channel_tls_connect (addr=0x7fffe180,
 port=443,
 id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z",
 ed_id=0x20)
 at src/or/channeltls.c:206
 #4  0x77c34108 in dirserv_single_reachability_test (
 now=, router=0x7fffeb96c880) at
 src/or/dirserv.c:3405
 #5  0x77b9b0a0 in routerlist_descriptors_added (sl=0x7b9b2900,
 from_cache=1) at src/or/routerlist.c:4280
 #6  0x77ba36a8 in router_load_routers_from_string (
 s=0x7fffee9720f8 "", eos=,
 saved_location=, requested_fingerprints=0x0,
 descriptor_digests=0, prepend_annotations=)
 at src/or/routerlist.c:4415
 #7  0x77ba381c in router_reload_router_list_impl
 (store=0x781306c0)
 at src/or/routerlist.c:1565
 #8  0x77ba3926 in router_reload_router_list ()
 at src/or/routerlist.c:1607
 #9  0x77b4b17b in do_main_loop () at src/or/main.c:2671
 #10 0x77b4b88b in tor_run_main (tor_cfg=)
 at src/or/main.c:4064
 #11 0x77b461a3 in tor_main (argc=3, argv=0x7fffe638)
 at src/or/tor_api.c:84
 #12 0x77b46039 in main (argc=,
 argv=) at src/or/tor_main.c:32
 }}}

 {{{
 #0  0x77ca55e7 in tor_memeq (a=,
 b=, sz=)
 at src/common/di_ops.c:110
 110 const uint8_t byte_diff = *ba++ ^ *bb++;
 (gdb) up
 #1  0x77b9472a in router_ed25519_id_is_me (id=)
 at src/or/routerkeys.c:1248
 1248ed25519_pubkey_eq(id, _identity_key->pubkey);
 (gdb) up
 #2  0x77c11ad8 in connection_or_connect (_addr=0x7fffe180,
 port=443, id_digest=0x7fffeb96c8ac "\fÚ0ÍÛRku>K§\t8p;ïl´¸áv\237\232Z",
 ed_id=0x20, chan=0x7ecb8230) at src/or/connection_or.c:1210
 1210  if (server_mode(options) && router_ed25519_id_is_me(ed_id)) {
 }}}

 {{{
 (gdb) print ed_id
 $4 = (const ed25519_public_key_t *) 0x20
 }}}

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

Re: [tor-bugs] #24740 [Core Tor/Tor]: Tor launches two requests for authority certificates on first bootstrap

[Tor Bug Tracker & Wiki]

#24740: Tor launches two requests for authority certificates on first bootstrap
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bootstrap, tor-bandwidth, easy,  |  Actual Points:
  intro  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by fristonio):

 Which part of the codebase is this hinted request made in, what I got from
 the code is that when the bootstrapping process starts Tor parses the
 certificates first from the cached-certs file. Then Tor parses microdesc-
 consensus from the disk and sets the current consensus based on them
 during this process it launches certificate fetch if not enough
 certificate are available to validate the consensus. Then it reloads the
 router list after this we set up periodic callbacks. I couldn't locate
 where the hinted request is made. Any 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] #24540 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Weird site issues with Tor & HTTPSEverywhere

[Tor Bug Tracker & Wiki]

#24540: Weird site issues with Tor & HTTPSEverywhere
-+-
 Reporter:  mroystonward |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere | Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #4187 [Core Tor/Tor]: A verified unverified-consensus should be renamed to cached-consensus

[Tor Bug Tracker & Wiki]

#4187: A verified unverified-consensus should be renamed to cached-consensus
-+-
 Reporter:  anonym   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.33
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, directory, rename, fs,   |  Actual Points:
  easy, 032-unreached|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging in master!

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

Re: [tor-bugs] #25378 [Core Tor/Tor]: Log domain list is out of sync in tor.1.txt

[Tor Bug Tracker & Wiki]

#25378: Log domain list is out of sync in tor.1.txt
---+
 Reporter:  ahf|  Owner:  ahf
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  doc, 033-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 cherry-picking to 0.3.3; adding changes file; merging 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] #25095 [Core Tor/Tor]: Update dir-spec.txt with recent consensus param additions

[Tor Bug Tracker & Wiki]

#25095: Update dir-spec.txt with recent consensus param additions
---+
 Reporter:  arma   |  Owner:  dgoulet
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-spec, tor-dos  |  Actual Points:
Parent ID: | Points:
 Reviewer:  ahf|Sponsor:
---+
Changes (by nickm):

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


Comment:

 merged to torspec!

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

Re: [tor-bugs] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn, teor|Sponsor:
-+
Changes (by nickm):

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


Comment:

 okay, I think you're right.  Merging in 0.3.3.

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

Re: [tor-bugs] #24113 [Core Tor/Tor]: We stop trying to download an md after 8 failed tries

[Tor Bug Tracker & Wiki]

#24113: We stop trying to download an md after 8 failed tries
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #23814 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 #23814 is now merged; this is now 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] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 See also #25117.

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

Re: [tor-bugs] #25251 [Core Tor/Tor]: Fix TROVE-2018-004: bad consensus can trigger null pointer crash. (was: Fix TROVE-2018-004)

[Tor Bug Tracker & Wiki]

#25251: Fix TROVE-2018-004: bad consensus can trigger null pointer crash.
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  033-must, 029-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Old description:



New description:

 When checking their own versions against the subprotocol versions listed
 in a consensus document, Tor instances could be made to crash if the
 consensus was incorrectly formatted.

 This is a low-severity bug, since it can only be exploited by corrupting a
 majority of directory authorities.  (And any attacker who can do that, can
 do far worse.)

 We're tracking this one as TROVE-2018-004.  It was present in
 0.2.9.4-alpha and later.  It is fixed in 0.2.9.15, 0.3.1.10, 0.3.2.10, and
 0.3.3.3-alpha.

--

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

Re: [tor-bugs] #25117 [Core Tor/Tor]: Resolve TROVE-2018-002: bug 24700 KIST use-after-free can be remotely triggered (was: Resolve TROVE-2018-002)

[Tor Bug Tracker & Wiki]

#25117: Resolve TROVE-2018-002: bug 24700 KIST use-after-free can be remotely
triggered
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  033-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Old description:



New description:

 The use-after free KIST bug that we fixed as #24700 can, it turns out, be
 triggered remotely, causing relays to crash.

 This bug only affects relays and bridges, and only if they are running
 0.3.2.1-alpha through 0.3.2.9, or 0.3.3.1-alpha.  It is fixed in 0.3.2.10
 and 0.3.3.2-alpha.

 Tracked as TROVE-2018-002 and CVE-2018-0491.

--

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

Re: [tor-bugs] #25074 [Core Tor/Tor]: TROVE-2018-001: null-pointer crash in directory authority protocol list code

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001: null-pointer crash in directory authority protocol list
code
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  033-must, review-group-33  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by nickm):

 Fixed in 0.2.9.15, 0.3.1.10, 0.3.2.10, and 0.3.3.3-alpha.

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

Re: [tor-bugs] #25074 [Core Tor/Tor]: TROVE-2018-001: null-pointer crash in directory authority protocol list code (was: TROVE-2018-001)

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001: null-pointer crash in directory authority protocol list
code
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  033-must, review-group-33  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by nickm):

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


Old description:

> For details, see:
> https://trac.torproject.org/projects/tor/wiki/TROVE

New description:

 The subprotocol implementation in 0.2.9.4-alpha had a bug where an
 incorrectly formatted relay descriptor could cause directory servers to
 crash when they tried to vote about it.  This does not affect relays or
 clients, since they do not try to vote.

 Tracked as TROVE-2018-001 and CVE-2018-0490.

--

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

Re: [tor-bugs] #25413 [Community/Tor Support]: Concept: Secure Mail Server / Mail Network

[Tor Bug Tracker & Wiki]

#25413: Concept: Secure Mail Server / Mail Network
---+---
 Reporter:  bkapur |  Owner:  phoul
 Type:  project| Status:  new
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords:  email, secure mail system  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by bkapur):

 Thanks cypherpunks. The two look very interesting but not what I am after.
 I will checkout Onion Services.

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

Re: [tor-bugs] #25413 [Community/Tor Support]: Concept: Secure Mail Server / Mail Network

[Tor Bug Tracker & Wiki]

#25413: Concept: Secure Mail Server / Mail Network
---+---
 Reporter:  bkapur |  Owner:  phoul
 Type:  project| Status:  new
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords:  email, secure mail system  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 You mean mail using onion services? Not exactly what you're asking but
 have a look at https://Ricochet.im (there's also https://onionshare.org
 which is similar in concept)

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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 Reporter:  karsten  |  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 irl):

 Replying to [comment:6 dcf]:
 > for one transport, the top countries that use that transport

 Currently the arguments that are passed to the graphing backend are only
 date ranges and countries, so plotting for any one thing that isn't a
 country won't be supported. In the new approach, would the CSV for all
 countries still be usable for this? If not, we should consider what other
 similar use cases we might be breaking.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25414 [Core Tor/Fallback Scripts]: Fallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A334

[Tor Bug Tracker & Wiki]

#25414: Fallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A334
---+-
 Reporter:  svengo |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:  fallback-change
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi!

 Please remove "Lindon" 9FBEB75E8BC142565F12CBBE078D63310236A334 from the
 fallback directory list. The tor node will be shut down in the near
 future.

 Best regards
 Sven

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25413 [Community/Tor Support]: Concept: Secure Mail Server / Mail Network

[Tor Bug Tracker & Wiki]

#25413: Concept: Secure Mail Server / Mail Network
-+-
 Reporter:  bkapur   |  Owner:  phoul
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Community/Tor|Version:
  Support|   Keywords:  email, secure mail
 Severity:  Normal   |  system
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I am totally new to Tor and apologise if this is the wrong place for my
 post.

 Would 2 or more Tor nodes / relays, each hosting a mail server and a web
 mail client be able to exchange email messages and users able to access
 their mail box using a Tor browser? That is, can a private, secure mail
 system be setup by simply adding Tor transport to conventional mail
 servers?

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

Re: [tor-bugs] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc-maybe  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 TracExitHosts is not supposed to make every destination use the same
 website: it is supposed to make it so that every time you go to the _same_
 destination, you get the _same_ website.

 For your example, I would expect every visit to duckduckgo to use some
 exit A, and every visit to nasa.gov to use some exit B, but I wouldn't
 expect "A" and "B" to be the same exit.

 Is this something that the documentation should be more clear about?

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

Re: [tor-bugs] #25412 [Core Tor/Tor]: TrackHostExits option in torrc file not working as documented

[Tor Bug Tracker & Wiki]

#25412: TrackHostExits option in torrc file not working as documented
---+
 Reporter:  LittleTorFanAnnie  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc-maybe  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:   => doc-maybe
 * milestone:   => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #25036 [Core Tor/Tor]: Tor 0.3.2 rejects connections to raw ipv6 addresses

[Tor Bug Tracker & Wiki]

#25036: Tor 0.3.2 rejects connections to raw ipv6 addresses
-+-
 Reporter:  pastly   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, ipv6, 032-backport,  |  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #25409 [Core Tor/Tor]: rip out PortForwarding options

[Tor Bug Tracker & Wiki]

#25409: rip out PortForwarding options
+
 Reporter:  arma|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by yawning):

 Replying to [comment:1 nickm]:
 > IIUC, one of yawning's findings was that a depressingly large number of
 consumer routers can't actually be used this way, since they tend to brick
 themselves when upnp'd too hard.

 While I still stand behind the replacement implementation I wrote, and it
 tries to avoid certain behavior that has historically been troublesome, my
 view is that for users that this sort of tool would be useful for (someone
 that can't configure port forwarding on their own), the support burden for
 "your router doesn't implement UPnP-IGD or NAT-PMP/NAT-PCP correctly"
 would be rather large, because of the vast number of broken/buggy
 implementations of said protocols.

 The general consensus around the time the rewrite was completed was "apart
 from flashproxy, there isn't much use for this sort of thing due to
 consumer grade NAT being horrific", so I support the removal.

 It is somewhat of a shame because the utility will work fine for a
 sizeable fraction of router implementations out there, but when things go
 wrong, they go really wrong, which is a poor fit for a non-technical end
 user oriented piece of software.

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