[tor-bugs] #20178 [Core Tor/Tor]: The fallback update script should log stem connection errors at warning level

[Tor Bug Tracker & Wiki]

#20178: The fallback update script should log stem connection errors at warning
level
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 Currently, they're logged at info-level, in order to filter out the
 "connecting to" messages. It would be great to keep those at info level,
 and log the "error connecting" messages at WARNING level.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20177 [Core Tor/Tor]: When checking existing fallbacks, report those fallbacks at warning log level

[Tor Bug Tracker & Wiki]

#20177: When checking existing fallbacks, report those fallbacks at warning log
level
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 When the fallback script excludes some relays, it only logs at info level.
 This is usually what we want, but when checking existing fallbacks, it
 would be great to see any message about those fallbacks at WARNING log
 level.

 This would make it easier to work out why fallbacks are broken.

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

[tor-bugs] #20176 [Core Tor/Tor]: current_consensus is an unmarked hazard

[Tor Bug Tracker & Wiki]

#20176: current_consensus is an unmarked hazard
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+
 current_md_consensus is a static variable.
 current_ns_consensus is a static variable.

 {{{
 #define current_consensus   \
   (we_use_microdescriptors_for_circuits(get_options()) ?\
current_md_consensus : current_ns_consensus)
 }}}

 We should at the very least rename this to a CURRENT_CONSENSUS macro.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20175 [Core Tor/Tor]: Allow the fallback script to ignore temporary IPv6 addresses

[Tor Bug Tracker & Wiki]

#20175: Allow the fallback script to ignore temporary IPv6 addresses
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  fallback, ipv6
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 When updateFallbackDirs.py checks relay addresses, it makes sure that the
 IPv4 and IPv6 addresses and ports match the relay's whitelist entry.

 If a relay's IPv6 address is temporary, it should not be included in the
 whitelist.

 But this means the relay will never be selected, because its descriptor
 has an IPv6 address, and that address doesn't match the (missing) address
 in the whitelist.

 We should add a way to say ipv6=ignored or something.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20174 [Core Tor/Tor]: Automate checking existing fallbacks

[Tor Bug Tracker & Wiki]

#20174: Automate checking existing fallbacks
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 I use a manual process to check existing fallbacks. It would be great if
 the updateFallbackDirs.py script would automatically read
 src/or/fallback_dirs.inc, and check each fallback for errors.

 For details, see:
 
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors

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

Re: [tor-bugs] #19481 [Applications/Tor Browser]: Change app.update.url to point to aus1.tpo

[Tor Bug Tracker & Wiki]

#19481: Change app.update.url to point to aus1.tpo
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201609R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Replying to [comment:3 gk]:
 > weasel said there is no key pinning for aus1.tpo nor for cdn.tpo right
 now. It might come in the future.

 This shouldn't be done at all till it's possible to pin the cert chain for
 aus1.tpo over a prolonged period of time (not the rather short 3 months
 imposed by the Let's Encrypt cert lifespan).

 WHile the scope of potential problems from not doing so should be limited
 to adversaries withholding updates (since the MARs are signed), that feels
 suboptimal.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201609, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-
Changes (by teor):

 * parent:   => #20172


Comment:

 I wrote a wiki page here:
 
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors

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

Re: [tor-bugs] #20170 [Core Tor/Tor]: Backport 0.2.9 fallback list to 0.2.8?

[Tor Bug Tracker & Wiki]

#20170: Backport 0.2.9 fallback list to 0.2.8?
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.7
 Severity:  Normal  | Resolution:
 Keywords:  028-backport, fallback  |  Actual Points:
Parent ID:  #20172  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * parent:   => #20172


Comment:

 We should do the following things before backporting:
 * inform the relay operators their relays have been selected for 0.2.9,
 and
 * check the list before the 0.2.9 stable release to ensure the relays are
 still working.

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

Re: [tor-bugs] #20171 [Community]: Tell 0.2.8 fallback directory operators that their relays are on the list

[Tor Bug Tracker & Wiki]

#20171: Tell 0.2.8 fallback directory operators that their relays are on the 
list
---+-
 Reporter:  teor   |  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #20172 | Points:  2
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * parent:   => #20172


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20173 [Community]: Tell 0.2.9 fallback directory operators that their relays are on the list

[Tor Bug Tracker & Wiki]

#20173: Tell 0.2.9 fallback directory operators that their relays are on the 
list
---+--
 Reporter:  teor   |  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal |   Keywords:  fallback
Actual Points: |  Parent ID:  #20172
   Points:  2  |   Reviewer:
  Sponsor: |
---+--
 Thank them, and remind them to keep their relay details the same.


 I am hoping the community team can help me out with this, if I provide a
 list.

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

[tor-bugs] #20172 [Core Tor/Tor]: Fallback Tasks for 2016

[Tor Bug Tracker & Wiki]

#20172: Fallback Tasks for 2016
--+--
 Reporter:  teor  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:  0 |   Reviewer:
  Sponsor:|
--+--
 This is the top-level task for fallback directory mirror tickets in 2016,
 typically in 0.2.8 or 0.2.9.

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

Re: [tor-bugs] #20171 [Community]: Tell 0.2.8 fallback directory operators that their relays are on the list

[Tor Bug Tracker & Wiki]

#20171: Tell 0.2.8 fallback directory operators that their relays are on the 
list
---+-
 Reporter:  teor   |  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * milestone:  Tor: 0.2.??? =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20171 [Community]: Tell 0.2.8 fallback directory operators that their relays are on the list

[Tor Bug Tracker & Wiki]

#20171: Tell 0.2.8 fallback directory operators that their relays are on the 
list
---+--
 Reporter:  teor   |  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Community  |Version:
 Severity:  Normal |   Keywords:  fallback
Actual Points: |  Parent ID:
   Points:  2  |   Reviewer:
  Sponsor: |
---+--
 Thank them, and remind them to keep their relay details the same.

 I am hoping the community team can help me out with this, if I provide a
 list.

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

Re: [tor-bugs] #20168 [Core Tor/Tor]: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif

[Tor Bug Tracker & Wiki]

#20168: Clarify our #if{n}def by commenting what they are at the 
#elif/#else/#endif
--+--
 Reporter:  dgoulet   |  Owner:  cjb
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy, lorax   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cjb):

 * status:  accepted => 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] #20168 [Core Tor/Tor]: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif

[Tor Bug Tracker & Wiki]

#20168: Clarify our #if{n}def by commenting what they are at the 
#elif/#else/#endif
--+--
 Reporter:  dgoulet   |  Owner:  cjb
 Type:  enhancement   | Status:  accepted
 Priority:  Very Low  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy, lorax   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cjb):

 * status:  new => accepted
 * owner:   => cjb


Comment:

 > I'd guess it's straightforward to make it count the number of lines
 between the if/else/elif and their endif, and suppress the output if
 that's fewer than N lines.

 I've done this now.  I'll attach my changes to smartcommenter.vba as well
 as the patch against the Tor source.  Some questions:

 1. I set the minimum number of lines between #if..#endif before
 introducing an comment to be 20.  Should it be larger?  My thinking was
 that 20 lines is about a screenful at default terminal size.

 2. In this stanza:
 {{{
 #ifdef FOO
 ...
 #else /* FOO */
 ...
 #endif /* FOO */
 }}}
   Should the #else comment be FOO, or !(FOO)?

 3. In this stanza:
 {{{
 #ifndef FOO
 ...
 #else /* FOO */
 ...
 #endif /* FOO */
 }}}
   Should the #endif comment be FOO or !(FOO)?

 4. The vim plugin is capable of annotating long braced/indented sections
 too.  Is that attractive?

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

Re: [tor-bugs] #19810 [Core Tor/Tor]: Could high-bandwidth ORPort-only relays be fallbacks?

[Tor Bug Tracker & Wiki]

#19810: Could high-bandwidth ORPort-only relays be fallbacks?
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  fallback  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 Duplicate of #19129

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

Re: [tor-bugs] #19129 [Core Tor/Tor]: Allow Fallback Directories with no DirPort

[Tor Bug Tracker & Wiki]

#19129: Allow Fallback Directories with no DirPort
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #7798 | Points:  2
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 #19810 is a duplicate of this. It had the following additional info:

 In 0.2.8, relays automatically support begindir over ORPort, even if they
 don't have a DirPort.

 I wonder if we're missing out on (m)any high-bandwidth relays by excluding
 relays without a DirPort. That said, we wouldn't want too many, because
 relays still use the DirPort to bootstrap off fallbacks. (But if the
 fallback only has an ORPort, the relay will use that.)

 We'd need to make the following changes for this to happen:

 * modify the DirPort requirement during fallback selection to check for
 either a DirPort, or declared begindir support in the descriptor
 * make a DirPort optional for configured FallbackDirs in Tor
   * this may be as simple as setting the DirPort to 0, and disabling the
 validation. The rest of the code might just work, because it ignores 0
 DirPorts
 * test, test, test

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20170 [Core Tor/Tor]: Backport 0.2.9 fallback list to 0.2.8?

[Tor Bug Tracker & Wiki]

#20170: Backport 0.2.9 fallback list to 0.2.8?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:  028-backport, fallback
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 I'm generating a new list of fallback directory mirrors for release 0.2.9
 in #18828.

 We have a few options for dealing with the 0.2.8 list:
 * comment-out any broken fallbacks,
 * backport the 0.2.9 list,
 * do nothing.

 I would prefer to have the same src/or/fallback_dirs.inc in every
 (relevant) Tor release, assuming we do another 0.2.8 series release.
 This is consistent with how we handle directory authorities and geoip.
 Otherwise it becomes hard to check multiple fallback lists at once.

 But I could be convinced to go with either of the other options.

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

Re: [tor-bugs] #6939 [Core Tor/Tor]: Missing IPv6 ORPort reachability check

[Tor Bug Tracker & Wiki]

#6939: Missing IPv6 ORPort reachability check
-+-
 Reporter:  shamrock |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, 026-triaged-1,  |  Actual Points:
  nickm-patch, 027-triaged-1-out |
Parent ID:  #17811   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 To implement this ticket, we need Tor to be able to connect to its own
 IPv6 ORPort, using at least a 3-hop path:
 * This relay
 * Guard
 * Middle that supports IPv6
 * IPv6 ORPort on this relay

 We can definitely choose a middle node that supports IPv6 (maybe this will
 need an API change?), but I'm not sure whether we can tell it to extend
 specifically to an IPv6 address, and how it will react if we do.

 Alternately, we could simply test if we can connect, like the IPv4
 DirPort, but that is sub-optimal.

 In any case, Authorities don't vote on IPv6 addresses unless they can test
 IPv6 reachability, so at least the authorities are checking IPv6 ORPorts.

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

Re: [tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:  030-proposed  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---

Comment (by s7r):

 Replying to [comment:10 teor]:
 > No, the outbound address is left unspecified by Tor unless configured
 explicitly by the user. So the OS determines the outbound address, which
 can vary depending on the destination (routing table) on multi-homed
 systems.

 Sounds good enough. Probably most users who need this setting take care of
 it at upstream level such as routing table or firewall rules - so this
 should be fine. Patching `Address` as you said is the way to go.

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

Re: [tor-bugs] #20070 [Core Tor/Tor]: Make address choice failure log message more informative

[Tor Bug Tracker & Wiki]

#20070: Make address choice failure log message more informative
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  CoreTorTeam201609, ipv6, review- |  Actual Points:  0.2
  group-9|
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 dgoulet]:
 > Quick questions. Only ipv6, not v4?
 >
 > {{{
 > +/* If an authority or fallback directory has a hard-coded IPv6
 address,
 > + * but we receive a descriptor without that address, Tor will
 believe the
 > + * descriptor, and end up here. */
 > }}}

 IPv4 addresses are mandatory: they can be different between hard-coded
 details and descriptor, but they can't be missing in the descriptor or
 hard-coded details, so this case does not apply. (We might get a
 reachability mismatch if the IPv4 addresses aren't the same, I guess that
 would send us here also. I'll revise the comment.)

 {{{
 +/* If an authority or fallback directory has:
 + * - a hard-coded IPv4 address, but we receive a descriptor with a
 different address, or
 + * - a hard-coded IPv6 address, but we receive a descriptor without
 that address,
 + * Tor can find no reachable relays in the consensus, try a fallback
 (or authority)
 + * on its hard-coded address, but ultimately believe the descriptor,
 and end up here. */
 }}}

 > Also, why don't we backtrace in the case of the hard-coded rs?

 Because it's not an unexpected situation (it's entirely normal when a
 fallback drops its IPv6 address) and backtraces alarm users.

 > Else lgtm; Feel free to `merge_ready` this if the you believe my
 questions don't need code modification.
 >
 > actual-review-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] #19963 [Internal Services/Service - trac]: Cannot login to trac through the onion service

[Tor Bug Tracker & Wiki]

#19963: Cannot login to trac through the onion service
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Brainstorming:
  * Patch trac to remove the "secure flag" requirement for the onion
 service.
  * Patch it to not require cookies (It's always annoying to log in here
 because I have to go adjust browser settings, but I guess it wouldn't be
 easy to patch).
  * Use a self-signed certificate, but "cheat" and ship it with the Tor
 Browser.
  * Or make a CA constrained to torproject.org and ship that with the
 browser.
  * Patch the browser to set secure=1 for .onion URLs. (Proper review to
 determine the security impact probably makes this not worth the effort.)
  * Figure out how to get a certificate from a CA. Consider it an
 experiment, and document the process so others can do the same.

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

Re: [tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:  030-proposed  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 Replying to [comment:9 s7r]:
 > Correct. We should leave `OutboundBindAddress` for the time being. This
 tor-dev thread confirms adding the algorithm to `OutboundBindAdress` would
 not work for at least this use case:
 >
 > https://lists.torproject.org/pipermail/tor-
 dev/2016-September/011429.html
 >
 > While applying the algorithm to `Address` as described in this ticket
 would fix it, and plenty more use cases. So, we'll leave
 `OutboundBindAddress` aside currently. I don't know, does
 `OutboundBindAddress == Address` unless configured otherwise?

 No, the outbound address is left unspecified by Tor unless configured
 explicitly by the user. So the OS determines the outbound address, which
 can vary depending on the destination (routing table) on multi-homed
 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] #20015 [Internal Services/Service - dist]: Vidalia relay bundles being run accidentally by Tor users

[Tor Bug Tracker & Wiki]

#20015: Vidalia relay bundles being run accidentally by Tor users
--+-
 Reporter:  donncha   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - dist  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Good idea! We should make sure they made it to the packages directory on
 archive.torproject.org, and then blow them away from dist.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rubiate):

 I think that did it. Been running in a start-stop loop for over 45 minutes
 on Debian and OpenBSD with no crash. Without the latest patch it crashes
 within a few minutes, so looks promising.

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

Re: [tor-bugs] #20167 [Applications/Tor Browser]: new

[Tor Bug Tracker & Wiki]

#20167: new
--+
 Reporter:  thaplug   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:  HTTPS-E 3.3
Component:  Applications/Tor Browser  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Blocker   | Resolution:  not a bug
 Keywords:  wees  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorU
--+
Changes (by mcs):

 * status:  new => closed
 * resolution:   => not a 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] #20166 [Applications/Tor Browser]: looking

[Tor Bug Tracker & Wiki]

#20166: looking
--+--
 Reporter:  thaplug   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Torbutton: 1.2.5
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Blocker   | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

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


Comment:

 Welcome, but please avoid creating tickets that do not describe problems
 with the Tor 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

Re: [tor-bugs] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

[Tor Bug Tracker & Wiki]

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201609  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:10 arthuredelstein]:
 > Here's a patch for review that implements option (1), and defers
 applying the settings until the OK button is pressed:
 > https://github.com/arthuredelstein/torbutton/commit/18093

 Kathy and I reviewed this and have a few comments:
 1. The implementation of torbutton_reset_browser_prefs() should be removed
 since that function is no longer used.
 2. You need to pass `document` to the revised
 `torbutton_prefs_reset_defaults()` function.
 3. Normally, when the user tries to check or uncheck the
 torbutton_blockDisk checkbox, a "Restart Tor Browser?" prompt is
 displayed. If "Restore Defaults" modifies that pref, the same prompt
 should be displayed. I think this problem exists without your changes
 though.

 (For 1. and 2., maybe you just forgot to include your preferences.xul and
 torbutton.js changes).

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

Re: [tor-bugs] #20149 [Applications/Quality Assurance and Testing]: Test that static public key pins are working

[Tor Bug Tracker & Wiki]

#20149: Test that static public key pins are working
-+-
 Reporter:  gk   |  Owner:  boklm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Major| Resolution:
 Keywords:  tbb-security |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:3 boklm]:
 > In 59782207d2e5976d11226496f3dec57917cc5962 I added a test that checks
 that key pinning on https://pinning-test.badssl.com/ is working. We are
 checking that the page fails to load, and that the error pages has
 `MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE` as `errorCode`.

 The above test looks OK to me.

 > We are checking that it is working at the current date. I think I can
 add an other test on Linux that uses libfaketime to check that it also
 works at a date 2 or 3 months in the future.

 That seems like a good idea. Should we also check, as part of our build
 process, that the timestamp in security/manager/ssl/StaticHPKPins.h is
 reasonable? I guess that would be a redundant check, but it might still be
 a good idea.

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

Re: [tor-bugs] #19854 [Applications/Tor Browser]: Fix URLs in the downloads.json file

[Tor Bug Tracker & Wiki]

#19854: Fix URLs in the downloads.json file
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201608R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 Replying to [comment:5 yawning]:
 > Ok.  For the sake of my sanity, is the redirect situation to
 `aus1.torproject.org` going to be an ongoing thing, or is the
 `downloads.json` file going to be on `dist.torproject.org`?
 >
 > I'd like the redirect to go away if possible, since I want to pin the
 entire cert chain that I use to fetch said file...

 Currently, the internal updater is using
 http://www.torproject.org/dist/torbrowser/update_2/ URLs, which is
 redirected to dist.tpo for the stable and aus1.tpo for the alpha. At some
 point we want to change the URL to aus1.tpo directly (and have a redirect
 on the old URLs for the older browsers). We have #19481 for that.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 closer and closer.  Try bug20103_028_v2 again ? I just pushed another
 commit.

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

Re: [tor-bugs] #20169 [Core Tor/Tor]: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

[Tor Bug Tracker & Wiki]

#20169: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND
---+--
 Reporter:  grarpamp   |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.7
 Severity:  Normal | Resolution:
 Keywords:  control, spec, tor-hs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * keywords:   => control, spec, tor-hs
 * priority:  Medium => Low
 * type:  defect => enhancement
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.???


Comment:

 Moving that out of 029 for now as I doubt we'll be able to squeeze this in
 in time for the October release. If a spec and code patch comes in though,
 I'll be more than happy to consider it!

 I do like the idea of printing the unparseable descriptor in the case of
 `BAD_DESC`!

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rubiate):

 The same, but different:

 {{{
 ==9107==ERROR: AddressSanitizer: heap-use-after-free on address
 0x60e0004e3b98 at pc 0x7fb130756e46 bp 0x7ffc37f6ce60 sp 0x7ffc37f6ce58
 READ of size 2 at 0x60e0004e3b98 thread T0
 #0 0x7fb130756e45 in tor_addr_family src/common/address.h:155
 #1 0x7fb130756e45 in tor_addr_is_null src/common/address.c:871
 #2 0x7fb130757288 in tor_addr_is_valid src/common/address.c:932
 #3 0x7fb13047dc6b in node_get_all_orports src/or/nodelist.c:836
 #4 0x7fb130734c7a in node_is_a_configured_bridge
 src/or/entrynodes.c:1871
 #5 0x7fb13074173a in any_bridge_supports_microdescriptors
 src/or/entrynodes.c:2487
 #6 0x7fb130468229 in we_use_microdescriptors_for_circuits
 src/or/microdesc.c:924
 #7 0x7fb1304728ec in networkstatus_set_current_consensus
 src/or/networkstatus.c:1680
 #8 0x7fb1306d146c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #9 0x7fb1306d5cc9 in connection_dir_reached_eof
 src/or/directory.c:2471
 #10 0x7fb13067879e in connection_reached_eof src/or/connection.c:4841
 #11 0x7fb13067879e in connection_handle_read_impl
 src/or/connection.c:3528
 #12 0x7fb130453b67 in conn_read_callback src/or/main.c:803
 #13 0x7fb12e6983db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)
 #14 0x7fb130455396 in run_main_loop_once src/or/main.c:2543
 #15 0x7fb130455396 in run_main_loop_until_done src/or/main.c:2589
 #16 0x7fb130455396 in do_main_loop src/or/main.c:2515
 #17 0x7fb13045ab94 in tor_main src/or/main.c:3646
 #18 0x7fb13044865b in main src/or/tor_main.c:30
 #19 0x7fb12cbb9b44 in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x21b44)
 #20 0x7fb13044b01a (tor/src/or/tor+0x56501a)
 }}}

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

Re: [tor-bugs] #19854 [Applications/Tor Browser]: Fix URLs in the downloads.json file

[Tor Bug Tracker & Wiki]

#19854: Fix URLs in the downloads.json file
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201608R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

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


Comment:

 Closing again, since the situation was clarifed.

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

Re: [tor-bugs] #20168 [Core Tor/Tor]: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif

[Tor Bug Tracker & Wiki]

#20168: Clarify our #if{n}def by commenting what they are at the 
#elif/#else/#endif
--+--
 Reporter:  dgoulet   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  easy, lorax   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cjb):

 I wonder if there's a tool that'd do this programmatically!  (At least for
 a first pass.)

 Here's one I just found, it's a vim script:

 https://sites.google.com/site/abudden/contents/Vim-Scripts/smart-brace
 --preprocessor-commenting/smartcommenter.vba?attredirects=0=1

 I'd guess it's straightforward to make it count the number of lines
 between the if/else/elif and their endif, and suppress the output if
 that's fewer than N lines.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20169 [Core Tor/Tor]: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND

[Tor Bug Tracker & Wiki]

#20169: hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Looking at a handful of HS descriptors...

 setevents hs_desc hs_desc_content
 hsfetch 2shgsl6ca3hwqnov

 3 HSDirs - BAD_DESC
 3 HSDirs - NOT_FOUND

 All 6 print...
 650+HS_DESC_CONTENT

 .
 650 OK

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:   => tbb-torbutton, tbb-security, TorBrowserTeam201609R
 * status:  needs_information => needs_review


Comment:

 This requires two patches, one for Tor Launcher and one for Torbutton:

 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20111-01=f221ec51c347a354bd58a6b8bb628f29dee1e284

 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug20111-01=9f6332a4aeb1d3b1a575cebba95903573aab11b4

 Kathy and I propose that we leave the browser defaults as-is. Inside tor-
 browser/browser/app/profile/000-tor-browser.js, we have:
  pref("network.proxy.socks", "127.0.0.1");
  pref("network.proxy.socks_port", 9150);
 That means that a TCP SOCKS port will be used if Tor Launcher is not
 installed, which seems okay since we do not know what path to use for the
 socket.

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

Re: [tor-bugs] #19996 [HTTPS Everywhere]: extensions.torbutton.https_proxy and similar preferences are gone

[Tor Bug Tracker & Wiki]

#19996: extensions.torbutton.https_proxy and similar preferences are gone
--+
 Reporter:  gk|  Owner:  legind
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by legind):

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


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

Re: [tor-bugs] #19996 [HTTPS Everywhere]: extensions.torbutton.https_proxy and similar preferences are gone

[Tor Bug Tracker & Wiki]

#19996: extensions.torbutton.https_proxy and similar preferences are gone
--+--
 Reporter:  gk|  Owner:  legind
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by legind):

 Fixed in https://github.com/EFForg/https-
 everywhere/commit/d42bf29fb03ea5c635814609545992c1e74224f2

 This will be deployed in HTTPSE v 5.2.5

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

Re: [tor-bugs] #19472 [Applications/Tor Browser]: Ongoing downloads icon not working

[Tor Bug Tracker & Wiki]

#19472: Ongoing downloads icon not working
--+---
 Reporter:  torbacchi |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by torbacchi):

 Well, it turns out this is a longstanding bug in Firefox :(

 See: https://bugzilla.mozilla.org/show_bug.cgi?id=785054

 I can reproduce this in both TorBrowser 6.0.5 (based on Mozilla Firefox
 45.4.0) and Firefox 45.3.0, both running on Linux OS, x86 32 bit.

 Since mozilla doesn't allow me to create an account on their BTS via Tor,
 can anyone please add a comment at
 https://bugzilla.mozilla.org/show_bug.cgi?id=785054 linking this page?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20168 [Core Tor/Tor]: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif

[Tor Bug Tracker & Wiki]

#20168: Clarify our #if{n}def by commenting what they are at the 
#elif/#else/#endif
--+--
 Reporter:  dgoulet   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:  easy, lorax
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Ok that's an easy one!

 The idea is to improve our comments in the .h/.c files where we have a
 `#ifdef BLAH` and the corresponding `#endif` is at least a non negligible
 amount of lines after. Of course that goes without saying to also comment
 the `#ifndef`. Pattern would look like this:

 {{{
 #ifdef BLAH
 [some non negligible amount of lines]
 #elif /* BLAH */
 [some other amount of lines]
 #endif /* BLAH */
 }}}

 According to nickm, the current situation is:

 Our headers have 27 #endifs with a comment, and 435 without.

 Good example is `or.h`:
 {{{
 #ifndef TOR_OR_H
 [5000+ lines in between]
 #endif /* TOR_OR_H */
 }}}

 This file `src/or/shared_random.h` is a good example of what it could look
 like.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20166 [Applications/Tor Browser]: looking

[Tor Bug Tracker & Wiki]

#20166: looking
--+--
 Reporter:  thaplug   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Torbutton: 1.2.5
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Blocker   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Looking around i am new

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

[tor-bugs] #20167 [Applications/Tor Browser]: new

[Tor Bug Tracker & Wiki]

#20167: new
--+
 Reporter:  thaplug   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:  HTTPS-E 3.3
Component:  Applications/Tor Browser  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Blocker   |   Keywords:  wees
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorU  |
--+
 Looking

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  yawning
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Replying to [comment:8 gk]:
 > mcs/brade: Do you have a preferred syntax for this fix?

 We do not have a syntax in mind; anything that works well and fits with
 tor's configuration philosophy is good as far as we are concerned. The
 syntax suggested by nickm in #tor-dev would be fine:
  SocksPort unix:"/foo/bar/baz quux/socket" IPv6Traffic PreferIPv6Automap

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

Re: [tor-bugs] #17054 [Applications/Tor Browser]: change lock color for insecure ssl ciphers

[Tor Bug Tracker & Wiki]

#17054: change lock color for insecure ssl ciphers
--+--
 Reporter:  elypter   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jsha):

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


Comment:

 Thank for the suggestion! I agree with fuglede, this is outside of scope
 for HTTPS Everywhere, but might be valuable as a separate one.

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

Re: [tor-bugs] #20148 [Core Tor/Tor]: Add AES256 support to crypto_cipher_t

[Tor Bug Tracker & Wiki]

#20148: Add AES256 support to crypto_cipher_t
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  crypto|  Actual Points:  0.2
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:  SponsorR-can
--+
Changes (by nickm):

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


Comment:

 okay. merging and hoping for the best

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

Re: [tor-bugs] #20117 [Core Tor/Tor]: Update PathsNeededToBuildCircuits man page entry with actual default

[Tor Bug Tracker & Wiki]

#20117: Update PathsNeededToBuildCircuits man page entry with actual default
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  easy doc CoreTorTeam201609 review-   |  Actual Points:
  group-9|
Parent ID:   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged, 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] #3555 [Applications/Tor Browser]: Pin *.torproject.org's certs in TBB

[Tor Bug Tracker & Wiki]

#3555: Pin *.torproject.org's certs in TBB
--+--
 Reporter:  tagnaq|  Owner:  tbb-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-firefox-patch |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * owner:  cyperpunks => tbb-team
 * severity:   => Normal


Comment:

 Despite the recent fail, this ticket can be closed as implemented (since
 FF34).

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

Re: [tor-bugs] #20149 [Applications/Quality Assurance and Testing]: Test that static public key pins are working

[Tor Bug Tracker & Wiki]

#20149: Test that static public key pins are working
-+-
 Reporter:  gk   |  Owner:  boklm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Major| Resolution:
 Keywords:  tbb-security |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #20123 [Applications/Tor Browser]: consider blocking remote jar files at Low Security

[Tor Bug Tracker & Wiki]

#20123: consider blocking remote jar files at Low Security
---+--
 Reporter:  arthuredelstein|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ff52-esr, tbb-security-slider  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by bugzilla):

 Replying to [ticket:20123 arthuredelstein]:
 > Mozilla recently blocked remote jar files by default:
 And you should.
 > Then they had to re-enable the remote jar files again in the release,
 because users of IBM iNotes (some sort of webmail thing) ran into an
 incompatibility.
 IBM fixed it.
 > In any case, Mozilla's intention is to block by default again in the
 future. So when that happens, if not sooner, we should ensure that our
 security slider is not re-enabling remote jar files at Low Security.
 Last time such operation was called "exempt" (#18557).

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

Re: [tor-bugs] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

[Tor Bug Tracker & Wiki]

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201609  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 Here's a patch for review that implements option (1), and defers applying
 the settings until the OK button is pressed:
 https://github.com/arthuredelstein/torbutton/commit/18093

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

Re: [tor-bugs] #17904 [Applications/Tor Browser]: Use sufficient window dimensions in Privacy and Security Settings

[Tor Bug Tracker & Wiki]

#17904: Use sufficient window dimensions in Privacy and Security Settings
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-security-slider, |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by arthuredelstein):

 * status:  new => needs_review
 * keywords:  tbb-security-slider, TorBrowserTeam201609 => tbb-security-
 slider, TorBrowserTeam201609R


Comment:

 Here's a patch that adds a scrollbar when the descriptions are too long
 for the window size. Resizing the window will cause the scrollbar to
 disappear.

 https://github.com/arthuredelstein/torbutton/commit/17904

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

Re: [tor-bugs] #14390 [Applications/Tor Browser]: Browser configuration fingerprinting

[Tor Bug Tracker & Wiki]

#14390: Browser configuration fingerprinting
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 So, users with printers are affected/unique. (?)

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

Re: [tor-bugs] #20149 [Applications/Quality Assurance and Testing]: Test that static public key pins are working

[Tor Bug Tracker & Wiki]

#20149: Test that static public key pins are working
-+-
 Reporter:  gk   |  Owner:  boklm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Major| Resolution:
 Keywords:  tbb-security |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 In 59782207d2e5976d11226496f3dec57917cc5962 I added a test that checks
 that key pinning on https://pinning-test.badssl.com/ is working. We are
 checking that the page fails to load, and that the error pages has
 `MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE` as `errorCode`.

 We are checking that it is working at the current date. I think I can add
 an other test on Linux that uses libfaketime to check that it also works
 at a date 2 or 3 months in the future.

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

Re: [tor-bugs] #20148 [Core Tor/Tor]: Add AES256 support to crypto_cipher_t

[Tor Bug Tracker & Wiki]

#20148: Add AES256 support to crypto_cipher_t
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  crypto|  Actual Points:  0.2
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:  SponsorR-can
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet
 * points:  .2 => 0.2
 * actualpoints:  .2 => 0.2


Comment:

 I guess yes, some sort of ticket to "unify" our aes API.

 lgtm;

 actual-review-point: 0.2

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

Re: [tor-bugs] #20117 [Core Tor/Tor]: Update PathsNeededToBuildCircuits man page entry with actual default

[Tor Bug Tracker & Wiki]

#20117: Update PathsNeededToBuildCircuits man page entry with actual default
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy doc CoreTorTeam201609 review-   |  Actual Points:
  group-9|
Parent ID:   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 lgtm;

 actual-review-point: 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] #1053 [Applications/Torbutton]: TypeError: browser is undefined

[Tor Bug Tracker & Wiki]

#1053: TypeError: browser is undefined
+--
 Reporter:  chiavibianci|  Owner:
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Torbutton  |Version:  Torbutton: 1.2.1
 Severity:  Normal  | Resolution:  invalid
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by bugzilla):

 * status:  new => closed
 * resolution:  None => invalid
 * severity:   => Normal


Comment:

 > Torbutton is dead.

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

Re: [tor-bugs] #20070 [Core Tor/Tor]: Make address choice failure log message more informative

[Tor Bug Tracker & Wiki]

#20070: Make address choice failure log message more informative
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  CoreTorTeam201609, ipv6, review- |  Actual Points:  0.2
  group-9|
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 Quick questions. Only ipv6, not v4?

 {{{
 +/* If an authority or fallback directory has a hard-coded IPv6
 address,
 + * but we receive a descriptor without that address, Tor will believe
 the
 + * descriptor, and end up here. */
 }}}

 Also, why don't we backtrace in the case of the hard-coded rs?

 Else lgtm; Feel free to `merge_ready` this if the you believe my questions
 don't need code modification.

 actual-review-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] #17293 [Core Tor/Tor]: Multiple new anti-DoS designs implemented since Oct 2015

[Tor Bug Tracker & Wiki]

#17293: Multiple new anti-DoS designs implemented since Oct 2015
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
|  implemented
 Keywords:  tor-dos, nickm-check-done-20160905  |  Actual Points:
Parent ID:  | Points:  parent
 Reviewer:  |Sponsor:
|  SponsorU-must
+--
Changes (by nickm):

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


Comment:

 Indeed, we've done a lot of sub-items in this area. I'm leaving two in
 0.2.9, but closing this "must" item as done.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18637, #18320

[Tor Bug Tracker & Wiki]

Batch modification to #18637, #18320 by nickm:
parent to 

Comment:
Leaving these in 0.2.9.x, but un-parenting . They are -can items, and their 
-must parent is closing.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #4581, #7572, #13737, #18346, ...

[Tor Bug Tracker & Wiki]

Batch modification to #4581, #7572, #13737, #18346, #18641, #15516, #17640, 
#17806, #18642, #18643, #18644, #18645, #18646, #19304, #19305, #19306 by nickm:
parent to 

Comment:
Unparenting these from #17293; holding for future work.

--
Tickets URL: 

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

Re: [tor-bugs] #17289 [Core Tor/Tor]: Overall Tor test coverage very high... over 75%?

[Tor Bug Tracker & Wiki]

#17289: Overall Tor test coverage very high... over 75%?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-tests-coverage, nickm-check- |  implemented
  done-20160905  |  Actual Points:
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  SponsorS-must
-+-
Changes (by nickm):

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


Comment:

 We didn't make 75%, but we've made progress. Unit test coverage is way up;
 integration test coverage has also improved.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #16791, #16805, #6313, #16795, ...

[Tor Bug Tracker & Wiki]

Batch modification to #16791, #16805, #6313, #16795, #17288, #17684, #17740 by 
nickm:
parent to 

Comment:
Unparenting.

--
Tickets URL: 

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

Re: [tor-bugs] #17280 [Core Tor/Tor]: Have a suite of >3 anti-dos proposals

[Tor Bug Tracker & Wiki]

#17280: Have a suite of >3 anti-dos proposals
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, tor-dos, tor-dos-|  implemented
  designs, TorCoreTeam-postponed-201604, nickm-  |  Actual Points:
  check-done-20160905|
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-
Changes (by nickm):

 * status:  accepted => 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] [Tor Bug Tracker & Wiki] Batch modify: #18636, #18635, #18638

[Tor Bug Tracker & Wiki]

Batch modification to #18636, #18635, #18638 by nickm:
parent to 

Comment:
Unparenting, to close parent.

--
Tickets URL: 

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

Re: [tor-bugs] #17280 [Core Tor/Tor]: Have a suite of >3 anti-dos proposals

[Tor Bug Tracker & Wiki]

#17280: Have a suite of >3 anti-dos proposals
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, tor-dos, tor-dos-|  Actual Points:
  designs, TorCoreTeam-postponed-201604, nickm-  |
  check-done-20160905|
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-

Comment (by nickm):

 Indeed, we can call this done.  The tickets tagged tor-dos represent a set
 of designs for resisting/preventing/ameliorating DoS.

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

Re: [tor-bugs] #7178 [Applications/Tor Browser]: NoScript (2.5.7) "reset" button does not use TBB defaults

[Tor Bug Tracker & Wiki]

#7178: NoScript (2.5.7) "reset" button does not use TBB defaults
-+-
 Reporter:  Larkdg   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton,|  Actual Points:
  noscript   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  tbb-usability, tbb-torbutton => tbb-usability, tbb-torbutton,
 noscript
 * version:  Tor: 0.2.2.39 =>
 * severity:   => Normal


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

Re: [tor-bugs] #4794 [Applications/Tor Browser]: NoScript Is Not Being Used Properly By The Tor Project

[Tor Bug Tracker & Wiki]

#4794: NoScript Is Not Being Used Properly By The Tor Project
--+---
 Reporter:  DasFox|  Owner:  mikeperry
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  NoScript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

 * status:  closed => reopened
 * component:  Firefox Patch Issues => Applications/Tor Browser
 * resolution:  not a bug =>
 * severity:   => Normal
 * milestone:  TorBrowserBundle 2.2.x-stable =>


Comment:

 This design should be revised.
 Comments of NoScript devs are 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] #19487 [Core Tor/Tor]: Meek and ReachableAddresses

[Tor Bug Tracker & Wiki]

#19487: Meek and ReachableAddresses
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, bridges, pluggable-|  Actual Points:
  transports, regression, CoreTorTeam201609, |
  review-group-9 |
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => dgoulet


Comment:

 actual-review-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] #19487 [Core Tor/Tor]: Meek and ReachableAddresses

[Tor Bug Tracker & Wiki]

#19487: Meek and ReachableAddresses
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, bridges, pluggable-|  Actual Points:
  transports, regression, CoreTorTeam201609, |
  review-group-9 |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 In `fetch_bridge_descriptors()`, iiuc we log notice with a firewall policy
 message if the bridge transport is not reachable but then we'll try
 anyway. I think that will only bring confusion because why do we warn in
 the first place if the firewall policy doesn't apply to transport?

 Would having this be enough? That is, we only check firewall policy if
 it's _not_ a transport or if we should ask directly and firewall policy
 checks out?

 {{{
   if (!bridge->transport_name ||
   (ask_bridge_directly &&
!fascist_firewall_allows_address_addr(>addr,
 bridge->port,
  FIREWALL_OR_CONNECTION,
 0,
  0))) {

 }}}

 And also, doesn't the `ask_bridge_directly` must really be set to `1` if
 we have a transport? Not too familiar with this part of the code but I
 don't think we want "fetch descriptor directly from bridge" if a transport
 is set. If so, we could reinforce how `ask_bridge_directly = ...` is set I
 guess?

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

Re: [tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:  030-proposed  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---

Comment (by s7r):

 Correct. We should leave `OutboundBindAddress` for the time being. This
 tor-dev thread confirms adding the algorithm to `OutboundBindAdress` would
 not work for at least this use case:

 https://lists.torproject.org/pipermail/tor-dev/2016-September/011429.html

 While applying the algorithm to `Address` as described in this ticket
 would fix it, and plenty more use cases. So, we'll leave
 `OutboundBindAddress` aside currently. I don't know, does
 `OutboundBindAddress == Address` unless configured 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] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * status:  reopened => 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] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

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


Comment:

 Replying to [comment:22 mcs]:
 > Kathy and I have prepared a patch to remove all of them, which we will
 post to #20111 very soon.

 On second thought, the patch belongs in this ticket. Here it is:
 https://gitweb.torproject.org/user/brade/tor-browser-
 bundle.git/commit/?h=bug15852-01=5a7d9c36cd6178fb87f3ea5598b400392120f589

 Georg, please let me know if you would rather have a new ticket for this
 followup fix.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Actually, that _is_ an improvement: the crash is in
 usable_consensus_flavor() now, not download_status_reset(). :)

 But try my branch `bug20103_028_v2`.  Is that any better?

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

Re: [tor-bugs] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

[Tor Bug Tracker & Wiki]

#19317: Sanitize TCP ports in bridge descriptors
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * milestone:  CollecTor 1.2.0 => CollecTor 1.1.0


Comment:

 I think all is done now or transferred to other tickets.
 It'll be fine to close this after merge.

 Setting milestone to 1.1.0 because the changes here are finished and used
 in the main instance, so they can be made 'official' there.

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

Re: [tor-bugs] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Some outdated and unneeded Torbutton preferences are still included with
 default values via the extension-overrides.js file that is part of the Tor
 Browser profile. See:
 https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-
 Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js

 Kathy and I have prepared a patch to remove all of them, which we will
 post to #20111 very 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] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

[Tor Bug Tracker & Wiki]

#19317: Sanitize TCP ports in bridge descriptors
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 [https://lists.torproject.org/pipermail/tor-dev/2016-September/011433.html
 Note posted to tor-dev@].

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

Re: [tor-bugs] #13507 [Applications/Tor Browser]: webgl not working on new version of tor browser for windows

[Tor Bug Tracker & Wiki]

#13507: webgl not working on new version of tor browser for windows
--+--
 Reporter:  keith768  |  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:
--+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 Replying to [comment:3 keith768]:
 >  5. Most important of all, the line of "WebGL Renderer" is completely
 missing on Tor Browser.
 Not everywhere. Found on Win7 with integrated Intel graphics.
 about:support shows:
 {{{
 (#0) Assert Potential driver version mismatch ignored due to missing
 DLLs
 }}}

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  yawning
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by bugzilla):

 You are going to push a socket into the interface intended for a port and
 try to make it work.
 (OT: What about #3501?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20165 [Core Tor/Tor]: When a relay advertises a new, unreachable address, OR reachability can succeed via the old address

[Tor Bug Tracker & Wiki]

#20165: When a relay advertises a new, unreachable address, OR reachability can
succeed via the old address
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 If a relay has advertised a reachable address in the past, and continues
 listening on the old address, clients and relays will continue to contact
 Tor on that address for a few hours.

 If the relay starts advertising a new, unreachable address, ORPort
 reachability will appear to succeed for that new address, because Tor
 doesn't (and probably can't) check the address clients are connecting to
 is the one it actually advertised.

 And Tor doesn't do ongoing reachability checks, so it publishes its
 descriptor based on the mistaken reachability, and assumes everthing is OK
 from then on.

 Fortunately, the mandatory DirPort check catches this in 0.2.8 and 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] #20163 [Core Tor/Tor]: Keep the interface address order returned by the OS

[Tor Bug Tracker & Wiki]

#20163: Keep the interface address order returned by the OS
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed easy intro  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:  029-proposed => 029-proposed easy intro


Comment:

 I can take a patch for this in 029 if somebody writes one on time.

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

Re: [tor-bugs] #17917 [Applications/Tor Browser]: Changelog after update is empty if JS is disabled

[Tor Bug Tracker & Wiki]

#17917: Changelog after update is empty if JS is disabled
+
 Reporter:  gk  |  Owner:  mcs
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-5.5, TorBrowserTeam201601R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by bugzilla):

 Replying to [comment:27 ma1]:
 > Replying to [comment:26 bugzilla]:
 > > is there any hope that TBB-related tickets like
 
https://trac.torproject.org/projects/tor/query?status=!closed=~noscript
 gain more priority? Thx.
 >
 > Yes, definitely, but no matter how disappointed you are for me
 prioritizing "Mozilla's bells and whistles", if NoScript doesn't comply
 first of all with Firefox's roadmap, which is already phasing out not-e10s
 compatible extensions, and then is going after legacy add-ons (i.e. all
 those which are not WebExtensions) there will be no NoScript to be fixed
 at all...
 Well, it seems you were frightened by Mozilla. Look how TBB Team solved
 that in #17248:
 > This is done and Mozilla should be aware of our needs by now.
 One sentence was removed from my message, but it had sense: it's a
 Mozilla's responsibility to port (or make it trivial to port)
 security/popular add-ons to their bells and whistles, and yours - only to
 review that. You can show them this message. But the main thought is that
 this activity shouldn't stall the security-related development.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20164 [Core Tor/Tor]: Warn relay operators when we guess an address from several equally valid alternatives

[Tor Bug Tracker & Wiki]

#20164: Warn relay operators when we guess an address from several equally valid
alternatives
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 When Tor chooses an address based on local network interface addresses,
 warn the operator if there were several valid addresses.

 #20163 makes sure that we use the OS interface order, which is hopefully:
 * stable, and
 * in an order determined by the operator.

 It would be nice to do this if DNS returns several results as well, but
 I'm not sure if that's even possible. And it probably deserves a separate
 ticket if it is.

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

[tor-bugs] #20163 [Core Tor/Tor]: Keep the interface address order returned by the OS

[Tor Bug Tracker & Wiki]

#20163: Keep the interface address order returned by the OS
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal|   Keywords:  029-proposed
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 #17027 unintentionally reorders interface addresses, by using
 SMARTLIST_DEL_CURRENT() in get_interface_address6_list() to delete
 unsuitable addresses, rather than SMARTLIST_DEL_CURRENT_KEEPORDER().

 This makes address selection unstable, because it depends on not only the
 exact order in which the OS returns addresses, but the exact number of
 unsuitable addresses as 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

Re: [tor-bugs] #19958 [Core Tor/Tor]: Implement proposal 264 (protocol versioning)

[Tor Bug Tracker & Wiki]

#19958: Implement proposal 264 (protocol versioning)
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201608, review-group-8  |  Actual Points:  2
Parent ID:  #15055 | Points:  2
 Reviewer:  dgoulet|Sponsor:
---+---

Comment (by nickm):

 asn: done! (in abcb6489e1bfd95591d945bb62b52d6aceb8f39a)

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

Re: [tor-bugs] #20148 [Core Tor/Tor]: Add AES256 support to crypto_cipher_t

[Tor Bug Tracker & Wiki]

#20148: Add AES256 support to crypto_cipher_t
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  crypto|  Actual Points:  .2
Parent ID:| Points:  .2
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by nickm):

 * status:  needs_information => needs_review


Comment:

 Hm. I think that merging the old and new APIs together should probably be
 another 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] #6939 [Core Tor/Tor]: Missing IPv6 ORPort reachability check

[Tor Bug Tracker & Wiki]

#6939: Missing IPv6 ORPort reachability check
-+-
 Reporter:  shamrock |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, 026-triaged-1,  |  Actual Points:
  nickm-patch, 027-triaged-1-out |
Parent ID:  #17811   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:18 teor]:
 > Do we need to check the IPv6 DirPort as well?

 There is now no IPv6 DirPort, it existed for a short while in the 0.2.8
 alpha series, and was effectively removed by mandatory client directory
 fetches over ORPort begindir.

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

Re: [tor-bugs] #17718 [Applications/Tor Browser]: About:config values need changing

[Tor Bug Tracker & Wiki]

#17718: About:config values need changing
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-pref  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:   => tbb-pref


Comment:

 https://github.com/pyllyukko/user.js/blob/master/user.js
 is a really good source for thinking about revising pref policy.
 Particularly, {{{user_pref("privacy.clearOnShutdown.siteSettings",
 false);}}} raises questions...


 #18971 is a duplicate.

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

Re: [tor-bugs] #18971 [Applications/Tor Browser]: Disable Firefox malware by default

[Tor Bug Tracker & Wiki]

#18971: Disable Firefox malware by default
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

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


Comment:

 Closed as a duplicate of #17718.

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

Re: [tor-bugs] #20137 [Internal Services/Service - jenkins]: Add Jenkins builder with --enable-tor2web-mode

[Tor Bug Tracker & Wiki]

#20137: Add Jenkins builder with --enable-tor2web-mode
-+
 Reporter:  teor |  Owner:  weasel
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor2web  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 We have such a build for master now.  Let me know when you want it for all
 the trees.

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

Re: [tor-bugs] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

[Tor Bug Tracker & Wiki]

#19317: Sanitize TCP ports in bridge descriptors
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Thanks for looking at everything!  Merged the two commits to master.
 Regarding the more prominent warning, I'm going to email tor-dev@
 immediately after the switch.

 Is there anything else to be done on this ticket (that is not referenced
 from another ticket like #19755)?

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  yawning
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 If we could this bug back on track for 0.2.9 that would be neat, although
 I guess we want to backport a fix for the tor we ship in Tor Browser
 anyway.

 mcs/brade: Do you have a preferred syntax for this fix?

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  yawning
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  nickm-deferred-20160905 => nickm-deferred-20160905, tbb-needs


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

Re: [tor-bugs] #20146 [Applications/Tor Browser]: Tor browser certificate pinning bypass for addons.mozilla.org and other pinned sites

[Tor Bug Tracker & Wiki]

#20146: Tor browser certificate pinning bypass for addons.mozilla.org and other
pinned sites
--+--
 Reporter:  mancha|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  CVE-2016-5284 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mancha):

 * keywords:   => CVE-2016-5284


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

Re: [tor-bugs] #9240 [Applications/Tor Browser]: Refusing proxy server

[Tor Bug Tracker & Wiki]

#9240: Refusing proxy server
--+--
 Reporter:  edencultures  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  new => closed
 * keywords:  tbb-firefox-patch =>
 * resolution:   => invalid
 * severity:   => Normal


Comment:

 Learn how to configure Norton or better remove 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] #14172 [Applications/Tor Browser]: duckduckgo search engine advertises download to non-official tor browser

[Tor Bug Tracker & Wiki]

#14172: duckduckgo search engine advertises download to non-official tor browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

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


Comment:

 duckduckgo folks fixed it.
 > Please remove the link, and please don't longer make business with these
 spammers.
 Invalid.

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

Re: [tor-bugs] #13958 [Applications/Tor Browser]: possible state leakage in Tor Browser

[Tor Bug Tracker & Wiki]

#13958: possible state leakage in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 It seems there is nothing suspicious in saving that state, except changing
 window size.

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

Re: [tor-bugs] #20161 [Applications/Tor Browser]: Make a proper hardened build target for Tor Browser

[Tor Bug Tracker & Wiki]

#20161: Make a proper hardened build target for Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-gitian, tbb-hardened => tbb-gitian


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

Re: [tor-bugs] #20161 [Applications/Tor Browser]: Make a proper hardened build target for Tor Browser

[Tor Bug Tracker & Wiki]

#20161: Make a proper hardened build target for Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, tbb-hardened  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:  tbb-gitian => tbb-gitian, tbb-hardened


Comment:

 (OT: Don't forget #17983)

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

Re: [tor-bugs] #19955 [Applications/Tor Browser]: Backport - Warning that favicon load request got cancelled is confusing (was: Warning that favicon load request got cancelled is confusing)

[Tor Bug Tracker & Wiki]

#19955: Backport - Warning that favicon load request got cancelled is confusing
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:   => tbb-easy


Comment:

 It's funny that Mozillians "kill off useless warning" instead of fixing
 its reason ;)
 It looks like my report will not be addressed in the next 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