Re: [tor-bugs] #26423 [Applications/Tor Browser]: Tor 7.5.5 crashes after opening

[Tor Bug Tracker & Wiki]

#26423: Tor 7.5.5 crashes after opening
--+--
 Reporter:  jllover   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by jllover):

 I found one different crash in the Application Log with d2d1.dll as the
 faulting module:
 Faulting application name: firefox.exe, version: 52.8.1.6607, time stamp:
 0x
 Faulting module name: d2d1.dll, version: 6.2.9200.16765, time stamp:
 0x528bf6b2
 Exception code: 0xc005
 Fault offset: 0x002cf8cb
 Faulting process id: 0x608
 Faulting application start time: 0x01d4083cccafd2d1
 Faulting application path: C:\Development\Tor Browser\Browser\firefox.exe
 Faulting module path: C:\Windows\system32\d2d1.dll
 Report Id: 213bd9a7-7430-11e8-b607-0021919111a5

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

Re: [tor-bugs] #26423 [Applications/Tor Browser]: Tor 7.5.5 crashes after opening

[Tor Bug Tracker & Wiki]

#26423: Tor 7.5.5 crashes after opening
--+--
 Reporter:  jllover   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jllover):

 * owner:  (none) => tbb-team
 * component:  Core Tor => Applications/Tor Browser


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

Re: [tor-bugs] #26423 [Core Tor]: Tor 7.5.5 crashes after opening

[Tor Bug Tracker & Wiki]

#26423: Tor 7.5.5 crashes after opening
--+--
 Reporter:  jllover   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by jllover):

 This is occurring on Windows 7 Ultimate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26423 [Core Tor]: Tor 7.5.5 crashes after opening

[Tor Bug Tracker & Wiki]

#26423: Tor 7.5.5 crashes after opening
--+--
 Reporter:  jllover   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 After opening Tor, moving the mouse over a tab or over the hamburger menu
 on the right causes a Tor crash. In some cases, this happens before I
 enter a URL.  Windows error reporting shows the following:
 Faulting application name: firefox.exe, version: 52.8.1.6607, time stamp:
 0x
 Faulting module name: mozglue.dll, version: 52.8.1.6607, time stamp:
 0x
 Exception code: 0xc005
 Fault offset: 0x34a7
 Faulting process id: 0x1e60
 Faulting application start time: 0x01d4083d5977c60b
 Faulting application path: C:\Development\Tor Browser\Browser\firefox.exe
 Faulting module path: C:\Development\Tor Browser\Browser\mozglue.dll
 Report Id: ce384295-7430-11e8-b607-0021919111a5

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

Re: [tor-bugs] #26251 [Applications/Tor Browser]: Adapt macOS snowflake compilation to new toolchain

[Tor Bug Tracker & Wiki]

#26251: Adapt macOS snowflake compilation to new toolchain
--+---
 Reporter:  gk|  Owner:  tbb-team, sukhbir
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sukhbir):

 * owner:  tbb-team => tbb-team, sukhbir
 * status:  new => assigned


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

Re: [tor-bugs] #26327 [Core Tor/Tor]: Add Vagrant configurations for multiple different systems to contrib

[Tor Bug Tracker & Wiki]

#26327: Add Vagrant configurations for multiple different systems to contrib
+--
 Reporter:  rl1987  |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:  Tor:
|  unspecified
 Severity:  Minor   | Resolution:
 Keywords:  vagrant dev-tools compilation easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by chelseakomlo):

 We have an infrastructure page for community efforts like this:
 https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure

 I'll wait for Nick's final word on this, but I think this configuration
 should live externally and we can reference it as we do with other helpful
 infrastructure tools that rely on external (possibly optional) tooling.

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

Re: [tor-bugs] #26322 [Applications/Tor Browser]: Circuit display - UI bug - Long v3 name

[Tor Bug Tracker & Wiki]

#26322: Circuit display - UI bug - Long v3 name
+--
 Reporter:  antonela|  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 I discussed with Antonela, and we're going to leave this ticket open for
 now, and test the current behavior in the next alpha. Then we can consider
 wrapping the domain or other possible solutions.

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

Re: [tor-bugs] #26220 [Core Tor/Tor]: Experiment with building/running Tor inside Docker container

[Tor Bug Tracker & Wiki]

#26220: Experiment with building/running Tor inside Docker container
--+--
 Reporter:  rl1987|  Owner:  rl1987
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by chelseakomlo):

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


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

Re: [tor-bugs] #26220 [Core Tor/Tor]: Experiment with building/running Tor inside Docker container

[Tor Bug Tracker & Wiki]

#26220: Experiment with building/running Tor inside Docker container
--+--
 Reporter:  rl1987|  Owner:  rl1987
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 We have created a page to track community projects like this- feed free to
 update it with this once you've moved it to an external project. Thanks
 for experimenting with this.

 https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure

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

Re: [tor-bugs] #26227 [Core Tor/Stem]: Review existing stem.client code

[Tor Bug Tracker & Wiki]

#26227: Review existing stem.client code
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by atagar):

 > LinkProtocol __eq__, future direction

 Sure. All attributes of the LinkProtocol are derived from its integer
 version, so it would be perfectly fine to do equality and hash on that.

 > do you envision we might turn it into something beyond a NamedTuple in
 the future, for version-specific behavior?

 Good question. I don't have any plans to extend it at present but I'd be
 happy to chat if you think it would be useful to do so.

 > I also saw a change to the circ_id allocation algorithm.

 If you the LinkProtocol addition then nope, I didn't change it. Just moved
 it. The part that concerns us is a
 [https://gitweb.torproject.org/torspec.git/tree/tor-
 spec.txt?id=4df184021b7c84cc47e2ed19a601b1e790b5b4fb#n930 few paragraphs
 later]...

 {{{
 With protocol version 3 or lower, a client with no public key
 MAY choose any CircID it wishes, since clients never need to process a
 CREATE cell.

 In link protocol version 4 or higher, whichever node initiated the
 connection sets its MSB to 1, and whichever node didn't initiate the
 connection sets its MSB to 0.
 }}}

 > I really liked ​84e4e657b4785e4888e567fbc04c8ea29fd43cc4 - I was
 contemplating how we might do that, and having an unused attribute makes a
 lot of sense!

 Neat, glad ya like it!

 > Do you think it might make more sense to call it padding, though?

 Actually, initially I did call it that until I realized the name
 conflicted with PADDING and VPADDING cells. I kinda like the name 'unused'
 since it makes it clear that it's bytes that have no impact.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26422 [Internal Services/Service - git]: Please create user/ahf/{tor, tor-browser} repositories on git.torproject.org

[Tor Bug Tracker & Wiki]

#26422: Please create user/ahf/{tor,tor-browser} repositories on 
git.torproject.org
-+
 Reporter:  ahf  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I'd like to request two repositories for me on git.torproject.org:

 - user/ahf/tor.git
 - user/ahf/tor-browser.git

 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] #26418 [Core Tor/Tor]: linker failures on 0.3.4 with --disable-module-dirauth

[Tor Bug Tracker & Wiki]

#26418: linker failures on 0.3.4 with --disable-module-dirauth
-+-
 Reporter:  catalyst |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression, tor-dirauth, tor-|  Actual Points:
  modularity |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to 0.3.4 and forward!

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

Re: [tor-bugs] #26421 [Core Tor/Stem]: Include info about the --quiet / -q option in --help

[Tor Bug Tracker & Wiki]

#26421: Include info about the --quiet / -q option in --help
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  dev testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--
Changes (by dmr):

 * status:  assigned => needs_review


Comment:

 A simple patch is available on
 [[https://github.com/torproject/stem/pull/2|this GitHub pull request]].
 (Branch head `c5e28c7bfd64dd940992b8a9b3f7f59c8be782e4`.)

 I reviewed the existing implementation just in case there was more needed.
 (It doesn't look like anything else 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] #26421 [Core Tor/Stem]: Include info about the --quiet / -q option in --help

[Tor Bug Tracker & Wiki]

#26421: Include info about the --quiet / -q option in --help
---+-
 Reporter:  dmr|  Owner:  dmr
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  dev testing
Actual Points: |  Parent ID:
   Points: |   Reviewer:  atagar
  Sponsor: |
---+-
 I was originally going to file a ticket to //implement// the `--quiet`
 option, but in looking at the code, saw that it already exists.

 It doesn't get displayed when we do `run_tests.py --help`, so make it do
 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] #26420 [Core Tor/Stem]: Discuss: Testing - specify literal patterns instead of regex patterns

[Tor Bug Tracker & Wiki]

#26420: Discuss: Testing - specify literal patterns instead of regex patterns
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  dev testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by atagar):

 Hi Dave. I hesitate to mention this but option would be to add an
 assertRaisesWith() method. We already wrap unittest's TextTestRunner to
 record test runtimes and add python 2.6 support for a couple methods...

 https://gitweb.torproject.org/stem.git/tree/stem/util/test_tools.py#n270

 Adding this method would be simple. The only thing that makes me hesitate
 is it's definitely non-standard.

 If you'd care to migrate Stem to a simple assertRaisesWith() method then
 feel free. Or not. Happy to go either way. :)

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

Re: [tor-bugs] #26227 [Core Tor/Stem]: Review existing stem.client code

[Tor Bug Tracker & Wiki]

#26227: Review existing stem.client code
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--

Comment (by dmr):

 Replying to [comment:6 atagar]:
 > Thanks Dave. Finally cobbled together some time to begin reviewing this
 and looks great! I really love how you broke these up - that's making it
 far easier to review.
 Thanks! I'll keep trying to do granular commits. (And hopefully push them
 more often!)

 > I've pushed your first five commits with some tweaks, most notably that
 I added a LinkProtocol class that centralizes the constants which vary by
 version. Mind taking a peek to see what you think?
 Overall: Looks good!

 A few comments...

  LinkProtocol `__eq__`, future direction
 w.r.t.
 
[[https://gitweb.torproject.org/stem.git/commit/?id=76c17caabc13b21dde7a5930fe30a59ffea9b2fe|76c17caabc13b21dde7a5930fe30a59ffea9b2fe]],
 would it make sense to have the LinkProtocol `__eq__` method allow an
 integer argument to be checked against the LinkProtocol.version attribute?
 (Or e.g. would that be considered non-Pythonic?)

 Also regarding the `LinkProtocol` class - do you envision we might turn it
 into something beyond a `NamedTuple` in the future, for version-specific
 behavior? Or do you expect we'll keep it limited to constants? (this
 touches a bit on #26226)
  circ_id allocation
 I also saw a change to the circ_id allocation algorithm. The spec says
 this is arbitrary ("[[https://gitweb.torproject.org/torspec.git/tree/tor-
 spec.txt?id=4df184021b7c84cc47e2ed19a601b1e790b5b4fb#n914|The CircID for a
 CREATE cell is an arbitrarily chosen nonzero integer,]]"), but I think it
 might be useful to factor this out. It is trivially network-observable
 behavior to the guard, and thus might be used to distinguish stem.client
 connections and treat them differently.

 Maybe the spec //ought to// specify it, at least a SHOULD behavior? I
 suppose it depends on the threat model the spec itself is trying to cover.
 Please let me know your thoughts!
  Cell.unused -> Cell.padding?
 I really liked
 
[[https://gitweb.torproject.org/stem.git/commit/?id=84e4e657b4785e4888e567fbc04c8ea29fd43cc4|84e4e657b4785e4888e567fbc04c8ea29fd43cc4]]
 - I was contemplating how we might do that, and having an `unused`
 attribute makes a lot of sense!
 Do you think it might make more sense to call it `padding`, though? There
 was some discussion about terminology in #26228, and it's not fully
 resolved therein, but a few opinions did come up that padding bytes are
 not a payload, even in the `[V]PADDING` cells.
  Testing literals
 For the side point of testing literals you brought up in
 
[[https://gitweb.torproject.org/stem.git/commit/?id=7711050619af1a2f8ecf4aa87f774baa5f367b3b|7711050619af1a2f8ecf4aa87f774baa5f367b3b]],
 I filed a separate ticket - see #26420. (I was already planning to file
 this.)

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

Re: [tor-bugs] #26363 [Applications/Tor Browser]: Don't use old mar-tools after the watershed for generating 64bit Tor Browser MAR files for Windows

[Tor Bug Tracker & Wiki]

#26363: Don't use old mar-tools after the watershed for generating 64bit Tor
Browser MAR files for Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:  #26050| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

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


Comment:

 #23561 is now fixed, which should fix this issue too.

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

Re: [tor-bugs] #26420 [Core Tor/Stem]: Discuss: Testing - specify literal patterns instead of regex patterns

[Tor Bug Tracker & Wiki]

#26420: Discuss: Testing - specify literal patterns instead of regex patterns
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  dev testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+--
Changes (by dmr):

 * status:  assigned => needs_review


Comment:

 Switching to `needs_review`. I feel that makes the most sense to bounce
 the discussion forward to you, atagar! :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26420 [Core Tor/Stem]: Discuss: Testing - specify literal patterns instead of regex patterns

[Tor Bug Tracker & Wiki]

#26420: Discuss: Testing - specify literal patterns instead of regex patterns
---+-
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  dev testing
Actual Points: |  Parent ID:
   Points: |   Reviewer:  atagar
  Sponsor: |
---+-
 w.r.t.
 
[[https://gitweb.torproject.org/stem.git/commit/?id=7711050619af1a2f8ecf4aa87f774baa5f367b3b|7711050619af1a2f8ecf4aa87f774baa5f367b3b]],
 I was planning to file this ticket anyways, so might as well now for the
 discussion.

 atagar linked [[https://stackoverflow.com/questions/8672754/how-to-show-
 the-error-messages-caught-by-assertraises-in-unittest-in-
 python2-7/8673096#8673096|this StackOverflow answer]] in the commit
 message.

 (I was a bit behind on filing this ticket, but already started doing the
 literal `re.escape()` bit in my test cases. Hence atagar's comment in the
 commit.)

 Anyway, here's the ticket text I had started to prep - now //slightly//
 tweaked:
 ===
 The testing codebase makes pretty extensive use of
 `unittest.TestCase.assertRaisesRegexp()`.
 An example is
 
[[https://gitweb.torproject.org/stem.git/tree/test/integ/client/connection.py?id=0192b29a4784465e5f69f11ced584a54644e4a90#n36|here]]:
 {{{
   def test_no_common_link_protocol(self):
 """
 Connection without a commonly accepted link protocol version.
 """

 for link_protocol in (1, 2, 6, 20):
   self.assertRaisesRegexp(stem.SocketError, 'Unable to establish a
 common link protocol with 127.0.0.1:1113', Relay.connect, '127.0.0.1',
 test.runner.ORPORT, [link_protocol])
 }}}
 The second argument is treated as a regex pattern, so it will actually
 match more than intended - possibly leading to some false negatives
 (although unlikely in this example).

 The use of `unittest.TestCase.assertRaisesRegexp()` without `re.escape()`
 for a literal expression is decently common - the use of it intended for a
 regex is fairly rare (I haven't come across a test yet that I can recall).

 Having a "literal" check is possible in (at least) two ways:
 {{{
 with self.assertRaises(SomeException) as cm:
   do_something(some_param)
 self.assertEqual(str(cm.exception), expected_literal)
 }}}
 {{{
 self.assertRaisesRegexp(SomeException, '^%s$' %
 re.escape(expected_literal), do_something, some_param)
 }}}

 Importantly, both of these check for //exact// string.
 Much of the codebase doesn't use `re.escape()`, and where it does, I
 didn't see any `^` or `$` (although I didn't search exhaustively), so that
 could match on substrings, also allowing for subtle bugs.

 So we may consider a helper class `StemTestCase(unittest.TestCase)` which
 adds an `assertRaisesLiteral()` method, to make it easier to do this. (Or
 some other means of adding that in.)

 We could of course take the second option with `re.escape()`, but since a
 lot of the codebase already doesn't seem to do that, it's probably quite
 easy to forget, especially the `'^%s$' % ` part.

 atagar: thoughts on these options? or leave things as-is / `wontfix`?

 (Filing this as a //task// ticket, as it's probably a discussion point
 more than anything else. I'd expect from the edge cases, there //could//
 be some defects, some enhancements.)

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

Re: [tor-bugs] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

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


Comment:

 I pushed `bug_23561_v6` to master as commit
 `951b1a7e01000f3dc1529c497b64d32cc0e58339`.

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201805  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by arthuredelstein):

 As part of this work, we could consider the phrasing for the security
 options. Ideas at the Mozilla All Hands included the changing the settings
 names to "strict, stricter, strictest" and using "feature filter" instead
 of "security slider". Further discussion may be needed!

 (I personally lean toward "safe" over "strict" and keeping the word
 "security" but agree there might be a better terminology.)

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

Re: [tor-bugs] #26419 [Applications/Tor Browser]: TBA - Evaluate Android Intent Referrers

[Tor Bug Tracker & Wiki]

#26419: TBA - Evaluate Android Intent Referrers
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #5709 | Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * priority:  Medium => High


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

Re: [tor-bugs] #26321 [Applications/Tor Browser]: Circuit display - Let's remove link from the Tor Button

[Tor Bug Tracker & Wiki]

#26321: Circuit display - Let's remove link from the Tor Button
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display,  |  Actual Points:
  TorBrowserTeam201806   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Tor Browser window height is a little more than 600px-ish, with this
 change the hamburger menu will dip below the window, and much more if
 there's an update notification. Is this a good compromise? (I myself don't
 care too much about that but it's a thing the UX team should consider.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26419 [Applications/Tor Browser]: TBA - Evaluate Android Intent Referrers

[Tor Bug Tracker & Wiki]

#26419: TBA - Evaluate Android Intent Referrers
-+-
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:  #5709
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Currently Fennec listens for the installation referrer
 `com.android.vending.INSTALL_REFERRER`. This is used for tracking
 installations (source of install, when it was installed, etc). We probably
 do not want this.

 See
 `mobile/android/base/java/org/mozilla/gecko/distribution/ReferrerReceiver.java`
 and (proxied) network calls in
 `mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java`

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

Re: [tor-bugs] #24546 [Core Tor/Tor]: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses

[Tor Bug Tracker & Wiki]

#24546: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4
addresses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, ipv6,   |  Actual Points:
  033-triage-20180320, 033-removed-20180320  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by neel):

 * cc: neel@… (added)


Comment:

 When I was grepping the instances of `->family == AF_INET`, I got this:

 {{{
 neel@flex:~/code/tor/tor/src % grep -R tor_addr_is_v4 */*.h
 common/address.h:int tor_addr_is_v4(const tor_addr_t *addr);
 neel@flex:~/code/tor/tor/src % grep -R "[-][>]family == AF_INET" *
 common/address.c:  if (addr->family == AF_INET) {
 common/address.c:  } else if (addr->family == AF_INET6) {
 common/address.c:  if (for_listening && addr->family == AF_INET
 common/address.h:  return a->family == AF_INET6 ? >addr.in6_addr :
 NULL;
 common/address.h:  tor_assert(a->family == AF_INET6);
 common/address.h:  return a->family == AF_INET ? a->addr.in_addr.s_addr :
 0;
 common/address.h:  if (a->family == AF_INET6) {
 common/address.h:  return a->family == AF_INET ? >addr.in_addr : NULL;
 common/address.h:  return a->family == AF_INET ? (tor_addr_to_ipv4h(a) ==
 u) : 0;
 neel@flex:~/code/tor/tor/src %
 }}}

 My questions are that:

 1. Should I change the `a->family == AF_INET` in `address.h` to
 `tor_addr_is_v4(a)` (along with changing `addr->family == AF_INET` to
 `tor_addr_is_v4(addr)`)?
 2. Is it okay if I implement a `tor_addr_is_v6()` which is like
 `tor_addr_is_v4()` but with IPv6/`AF_INET`, and replace `addr->family ==
 AF_INET6` and the like with `tor_addr_is_v6(addr)`?
 3. If I do #2 on this list, then should I reject IPv6 mapped IPv4
 addresses in `tor_addr_is_v6()`?

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

Re: [tor-bugs] #25697 [Applications/Tor Browser]: Create UI for Torbutton (prefs, security slider...)

[Tor Bug Tracker & Wiki]

#25697: Create UI for Torbutton (prefs, security slider...)
--+--
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team, tbb-mobile   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+--

Comment (by arthuredelstein):

 As part of this work, we should consider the phrasing for the security
 slider. Ideas at the Mozilla All Hands included the changing the settings
 names to "strict, stricter, strictest" and using "feature filter" instead
 of "security slider". Further discussion needed!

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

Re: [tor-bugs] #26418 [Core Tor/Tor]: linker failures on 0.3.4 with --disable-module-dirauth

[Tor Bug Tracker & Wiki]

#26418: linker failures on 0.3.4 with --disable-module-dirauth
-+-
 Reporter:  catalyst |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-dirauth, tor-|  Actual Points:
  modularity |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 Added potential patch in: https://github.com/torproject/tor/pull/163

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

Re: [tor-bugs] #26039 [Applications/Tor Browser]: /preferences/extension-overrides.js will not be loaded in ESR 60

[Tor Bug Tracker & Wiki]

#26039: /preferences/extension-overrides.js will not be loaded in 
ESR
60
-+-
 Reporter:  mcs  |  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #26039 [Applications/Tor Browser]: /preferences/extension-overrides.js will not be loaded in ESR 60

[Tor Bug Tracker & Wiki]

#26039: /preferences/extension-overrides.js will not be loaded in 
ESR
60
-+-
 Reporter:  mcs  |  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 You mean `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] #26322 [Applications/Tor Browser]: Circuit display - UI bug - Long v3 name

[Tor Bug Tracker & Wiki]

#26322: Circuit display - UI bug - Long v3 name
+--
 Reporter:  antonela|  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 Hi Antonela -- I was able to reproduce this problem with the build you
 tested. It seems this behavior (cutting off long domains) was fixed in a
 later build. For example, I tried the latest nightly build:

 http://f4amtbsowhix7rrf.onion/tor-browser-builds/2018-06-19/nightly-linux-
 x86_64/

 and the doorhanger is wide enough to accommodate the onion address (see
 below). So what do you think? Should we leave this as is, or would it be
 better to wrap the long domain name to two lines anyway?

 [[Image(v3onion_circuit_display.png)]]

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

Re: [tor-bugs] #26322 [Applications/Tor Browser]: Circuit display - UI bug - Long v3 name

[Tor Bug Tracker & Wiki]

#26322: Circuit display - UI bug - Long v3 name
+--
 Reporter:  antonela|  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * Attachment "v3onion_circuit_display.png" added.


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

Re: [tor-bugs] #26418 [Core Tor/Tor]: linker failures on 0.3.4 with --disable-module-dirauth

[Tor Bug Tracker & Wiki]

#26418: linker failures on 0.3.4 with --disable-module-dirauth
-+-
 Reporter:  catalyst |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-dirauth, tor-|  Actual Points:
  modularity |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

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


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

[tor-bugs] #26418 [Core Tor/Tor]: linker failures on 0.3.4 with --disable-module-dirauth

[Tor Bug Tracker & Wiki]

#26418: linker failures on 0.3.4 with --disable-module-dirauth
-+-
 Reporter:   |  Owner:  (none)
  catalyst   |
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  regression, tor-dirauth, tor-
 Severity:  Normal   |  modularity
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 At some point the maint-0.3.4 branch started to fail with linker errors if
 configured with `--disable-module-dirauth`.  See https://api.travis-
 ci.org/v3/job/393834946/log.txt

 Please ignore the Rust failure for now; those are covered by separate
 tickets.

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

Re: [tor-bugs] #26214 [Core Tor/Tor]: Check stream SENDME against max

[Tor Bug Tracker & Wiki]

#26214: Check stream SENDME against max
---+
 Reporter:  mikeperry  |  Owner:  mikeperry
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-circuit, tor-cell  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:  SponsorV-can
---+
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok I responded to your comment on
 https://github.com/torproject/tor/pull/123, and added a new commit for the
 comment explaining why this change won't trigger against well-behaved
 clients.

 However, the branch now has conflicts, so I rebased it on top of
 maint-0.3.4 and created a new pull request:
 https://github.com/torproject/tor/pull/162 (The rust tests are failing but
 that is not because of me -- I only changed the comment and fixed a
 conflict... the other builds pass).

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

Re: [tor-bugs] #26415 [Core Tor/Tor]: doctests in src/rust/crypto fail compilation

[Tor Bug Tracker & Wiki]

#26415: doctests in src/rust/crypto fail compilation
-+
 Reporter:  catalyst |  Owner:  catalyst
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-tests  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Patch at https://github.com/torproject/tor/pull/161

 Note there are still linker errors.  You'll probably have to `cargo test
 --doc` explicitly to get verify that the doctests compile.  (The regular
 tests failing to link prevents cargo from attempting the doctests.)

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

Re: [tor-bugs] #26039 [Applications/Tor Browser]: /preferences/extension-overrides.js will not be loaded in ESR 60

[Tor Bug Tracker & Wiki]

#26039: /preferences/extension-overrides.js will not be loaded in 
ESR
60
-+-
 Reporter:  mcs  |  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * keywords:  ff60-esr, TorBrowserTeam201806 => ff60-esr,
 TorBrowserTeam201806R
 * status:  assigned => needs_revision


Comment:

 Changed the build process to append the (partially generated) extension-
 overrides.js settings to 000-tor-browser.js

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26417 [Applications/Tor Browser]: Tor Browser build is not working with the runc version in debian testing

[Tor Bug Tracker & Wiki]

#26417: Tor Browser build is not working with the runc version in debian testing
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 ahf reported that building tor browser on Debian testing fails with the
 following error:
 {{{
 Error: Error starting remote:

 json: cannot unmarshal array into Go struct field Process.capabilities of
 type specs.LinuxCapabilities

 Makefile:66: recipe for target 'nightly-osx-x86_64' failed
 }}}

 The output of `runc --version` on Debian testing is:
 {{{
 $ /usr/sbin/runc --version
 runc version spec: 1.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] #26039 [Applications/Tor Browser]: /preferences/extension-overrides.js will not be loaded in ESR 60

[Tor Bug Tracker & Wiki]

#26039: /preferences/extension-overrides.js will not be loaded in 
ESR
60
+---
 Reporter:  mcs |  Owner:  pospeselr
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by pospeselr):

 * Attachment "0001-Bug-26039-profiledir-preferences-extension-
 overrides.patch" 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] #26412 [Core Tor/Stem]: KeyError in can_exit_to caused by lru_cache

[Tor Bug Tracker & Wiki]

#26412: KeyError in can_exit_to caused by lru_cache
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by juga):

 * keywords:   => tor-bwauth


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

Re: [tor-bugs] #26300 [Core Tor/Tor]: Attempt by … to open a stream on first hop of circuit. Closing.

[Tor Bug Tracker & Wiki]

#26300: Attempt by … to open a stream on first hop of circuit. Closing.
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_information


Comment:

 Oook... I've contacted one of the relay operator for which this warning
 came from to validate a series of theories like "Is the relay being used
 as a hidden service or/and client?"... Did the config changed when the
 warning appeared. And other questions like that.

 I hope we'll get more information so I can try to reproduce this and
 understand it. For now, I'll put that in `needs_information` since I do
 not know how to go forward on this one without a way to reproduce.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26416 [Internal Services/Service - git]: Please create a few repositories for pospeselr

[Tor Bug Tracker & Wiki]

#26416: Please create a few repositories for pospeselr
-+
 Reporter:  pospeselr|  Owner:  tor-gitadm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Hi, I'd a like a few public git repos (read everyone, write me):

 - tor-browser
 - tor-browser-build
 - torbutton
 - tor-launcher

 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

[tor-bugs] #26415 [Core Tor/Tor]: doctests in src/rust/crypto fail compilation

[Tor Bug Tracker & Wiki]

#26415: doctests in src/rust/crypto fail compilation
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal|   Keywords:  rust, tor-tests
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 After #26378 fixed compilation of regular tests in src/rust/crypto,
 compilation errors remain in the doctests.

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

Re: [tor-bugs] #19979 [Core Tor/Tor]: Use OpenSSL 1.1.0 HKDF in Tor when available.

[Tor Bug Tracker & Wiki]

#19979: Use OpenSSL 1.1.0 HKDF in Tor when available.
-+-
 Reporter:  nickm|  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  openssl110, easy, refactor, code-|  Actual Points:
  removal|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 https://github.com/torproject/tor/pull/160

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26414 [Core Tor/Tor]: Assertion onionkey failed in get_onion_key

[Tor Bug Tracker & Wiki]

#26414: Assertion onionkey failed in get_onion_key
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The following assert() happened when I made a tor client become also a
 relay (testing in chutney).

 Originally, as a client, only the `SocksPort` was set. Then I changed the
 torrc to have the `ORPort` and `DirPort` including the `ExitRelay 1`
 option. Upon the HUP of the process, this stacktrace appeared.

 {{{
 Jun 19 12:09:27.618 [err] tor_assertion_failed_(): Bug:
 src/or/router.c:202: get_onion_key: Assertion onionkey failed; aborting.
 (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: Assertion onionkey failed in get_onion_key
 at src/or/router.c:202. Stack trace: (on Tor 0.3.5.0-alpha-dev
 f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: /usr/lib/x86_64-linux-
 gnu/libasan.so.4(+0x558c0) [0x7efeb074c8c0] (on Tor 0.3.5.0-alpha-dev
 f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(log_backtrace+0x45)
 [0x561dacedcca5] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(tor_assertion_failed_+0x103) [0x561dacf41873] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(+0x787a36)
 [0x561dacb3ca36] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(router_build_fresh_descriptor+0x1d7a) [0x561dacb4c95a]
 (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(router_rebuild_descriptor+0x14f) [0x561dacb4dabf] (on
 Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(router_get_my_routerinfo_with_err+0x197)
 [0x561dacb4ddf7] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(check_descriptor_bandwidth_changed+0x26)
 [0x561dacb51646] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(+0x68fc1c)
 [0x561daca44c1c] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(+0x6f6a6a)
 [0x561dacaaba6a] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(rescan_periodic_events+0x1f9) [0x561daca4de29] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(rend_service_prune_list+0xde0) [0x561dacb064d0] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(hs_config_service_all+0x1fe5) [0x561dace68545] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(set_options+0x5402)
 [0x561daccf8522] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(options_init_from_string+0x1206) [0x561daccffb56] (on
 Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug:
 ../tor/src/or/tor(options_init_from_torrc+0x9cb) [0x561dacd00b8b] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(+0x69a769)
 [0x561daca4f769] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x1e97a) [0x7efeaff0997a] (on Tor 0.3.5.0-alpha-dev
 f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7efeaff0a33f] (on Tor
 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(do_main_loop+0x3fc)
 [0x561daca5120c] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(tor_run_main+0x535)
 [0x561daca54185] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(tor_main+0x86)
 [0x561daca40536] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(main+0x1c)
 [0x561daca3d2dc] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xe7) [0x7efeade88b97] (on Tor 0.3.5.0
 -alpha-dev f3267741e45c7944)
 Jun 19 12:09:27.619 [err] Bug: ../tor/src/or/tor(_start+0x2a)
 [0x561daca401ea] (on Tor 0.3.5.0-alpha-dev f3267741e45c7944)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list

Re: [tor-bugs] #25386 [Core Tor/Tor]: Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)

[Tor Bug Tracker & Wiki]

#25386: Link Rust Tests to C Dependencies in Tor (allow integration testing from
Rust to C)
-+-
 Reporter:  Hello71  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  SponsorQ
-+-

Comment (by nickm):

 https://github.com/torproject/tor/pull/159 is the PR

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)

[Tor Bug Tracker & Wiki]

#25386: Link Rust Tests to C Dependencies in Tor (allow integration testing from
Rust to C)
-+-
 Reporter:  Hello71  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 I have a variation in `rust_build_script_v3`: It's better documented, and
 it has the tricks necessary to get the sanitizers to work (for me) with
 clang and gcc.

 I was hoping not to need the "linker script" trick, but with clang, it
 turns out to be hard to actually specify "-lclangrt.asan" in a way that
 clang will accept.  I think you might need to list the architecture as
 part of the library's name for that -- so just specifying "static-libasan"
 was indeed easier.  But to pass that to the linker correctly, it needs to
 go near the start of the link line, and for that, we need to have a shell
 script.

 I think we might be needlessly rebuilding our rust modules when we run the
 tests here, because the RUSTFLAGS option is only set when testing. I
 didn't see a way to set RUSTFLAGS from build.rs, but that would be a
 better way around this.

 Note that the tests don't _pass_ yet, but I think that's 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] #26413 [- Select a component]: chaptca broken

[Tor Bug Tracker & Wiki]

#26413: chaptca broken
--+---
 Reporter:  Dollface86|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information
 * component:  Core Tor/Tor => - Select a component
 * milestone:  Tor: unspecified =>


Comment:

 Which captcha?

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

Re: [tor-bugs] #25886 [Core Tor/Tor]: Have frac_nodes_with_descriptors() take and use for_direct_connect

[Tor Bug Tracker & Wiki]

#25886: Have frac_nodes_with_descriptors() take and use for_direct_connect
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge-client, tor-guard,|  Actual Points:
  bootstrap  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ah wow much simpler and this actually makes more sense! Thanks neel!

 I believe that is correct.

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180502  |
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ok, I think we can go in autosquash mode and merge this to master!

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

Re: [tor-bugs] #20700 [Core Tor/Tor]: prop224: Implement standard client authorization

[Tor Bug Tracker & Wiki]

#20700: prop224: Implement standard client authorization
-+-
 Reporter:  dgoulet  |  Owner:  haxxpop
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, |  Actual Points:
  034-triage-20180328|
Parent ID:  #25955   | Points:  3
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorR-can
-+-

Comment (by dgoulet):

 Ok I've got the rest of my review in. There are couple show stopper
 comments that we need to address/discuss. 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] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Branch `bug_23561_v6` is based on the updated commit from comment 25:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23561_v6=951b1a7e01000f3dc1529c497b64d32cc0e58339

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

Re: [tor-bugs] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Branch `bug_23561_v5` has the commit with the two fixups:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23561_v5=0b884dc0c06b5467ef91e23ea0128c9e2c0169bd

 My two builds for x86_64 and i686 are matching, so it seems the build is
 reproducible.

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

Re: [tor-bugs] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 While looking at the commit again, I noticed a small issue: the
 `pe_checksum_fix.py` file is no longer included only in the Windows
 builds. This is fixed by this fixup commit:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23561_v4=e2a135f648cbd0ce3dbc366c62a431f42efdf2b8

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26413 [Core Tor/Tor]: chaptca broken

[Tor Bug Tracker & Wiki]

#26413: chaptca broken
--+--
 Reporter:  Dollface86|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chaptca broken, please help. It keeps telling me to verify that I am not
 spam.
 I have responded a lot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26412 [Core Tor/Stem]: KeyError in can_exit_to caused by lru_cache

[Tor Bug Tracker & Wiki]

#26412: KeyError in can_exit_to caused by lru_cache
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 As pastly reported in https://github.com/pastly/simple-bw-
 scanner/issues/198,
 stem giving this traceback:

 `File "/home/pastly/src/simple-bw-scanner/venv-editable/lib/python3.5
 /site-packages/stem/exit_policy.py", line 285, in can_exit_to`

 `if not self.is_exiting_allowed():KeyError:
 (,)`

 Apparently caused by  a Python bug with `lru_cache`.

 pastly is already trying to find out which Python versions fail, to use
 `stem`'s `lru_cache` for those ones.

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

Re: [tor-bugs] #23561 [Applications/Tor Browser]: Fix nsis builds for Windows 64

[Tor Bug Tracker & Wiki]

#23561: Fix nsis builds for Windows 64
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Replying to [comment:26 gk]:
 > I guess we could try at least for `python-future` the 0.15.2 package
 from Debian.

 This fixup commit is using the `python-future` package from `jessie-
 backports`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23561_v4=8ecea4a935a8f03754234656c94b18ff3b5af568

 I have two matching x86_64 builds, and am waiting for i686 builds to
 finish to check if they match too.

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

Re: [tor-bugs] #26389 [Obfuscation/meek]: meek-client keep roundTripRetries on shutdown

[Tor Bug Tracker & Wiki]

#26389: meek-client keep roundTripRetries on shutdown
--+--
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:3 cypherpunks]:
 > meek is deprecated.

 I don't think so.

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

Re: [tor-bugs] #26389 [Obfuscation/meek]: meek-client keep roundTripRetries on shutdown

[Tor Bug Tracker & Wiki]

#26389: meek-client keep roundTripRetries on shutdown
--+-
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 meek is deprecated.

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

Re: [tor-bugs] #21719 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Can't copy (Ctrl+C) and make search (Ctrl+F) by formulae on feynmanlectures.caltech.edu. FF 18.0.2 works fine

[Tor Bug Tracker & Wiki]

#21719: Can't copy (Ctrl+C) and make search (Ctrl+F) by formulae on
feynmanlectures.caltech.edu. FF 18.0.2 works fine
-+-
 Reporter:  Ilya_SpongeBob   |  Owner:  legind
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere | Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  tbb-usability|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #23125 [HTTPS Everywhere/EFF-HTTPS Everywhere]: www.dailymotion.com is Insecure

[Tor Bug Tracker & Wiki]

#23125: www.dailymotion.com is Insecure
-+-
 Reporter:  cypherpunks  |  Owner:  legind
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 That's because it breaks embedded videos currently.

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

Re: [tor-bugs] #26362 [Applications/Tor Browser]: Use old MAR format when generating the MAR files for the first esr60-based alpha

[Tor Bug Tracker & Wiki]

#26362: Use old MAR format when generating the MAR files for the first 
esr60-based
alpha
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:  #26050   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by boklm):

 I opened #26410 to remove it from the second esr60-based alpha and #26411
 to remove it from the second esr60-based stable release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26411 [Applications/Tor Browser]: Stop using old MAR format in the second esr60-based stable release

[Tor Bug Tracker & Wiki]

#26411: Stop using old MAR format in the second esr60-based stable release
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201809,
 Severity:  Normal   |  ff60-esr
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #26362 we set `MAR_OLD_FORMAT=1` when generating mar files for both
 `release` and `alpha` builds. In #26410 we remove it for the alpha builds
 after the first esr60-based `alpha` is published.

 This ticket is for removing it after the first esr60-based stable release
 is published.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26410 [Applications/Tor Browser]: Stop using old MAR format in the second esr60-based alpha

[Tor Bug Tracker & Wiki]

#26410: Stop using old MAR format in the second esr60-based alpha
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #26362 we set `MAR_OLD_FORMAT=1` when generating mar files for both
 `release` and `alpha` builds.

 After the first esr60-based alpha is released, we should remove
 `MAR_OLD_FORMAT=1` for the `alpha` builds, but keep it for the `release`
 builds (until the first `release` build is released).

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

Re: [tor-bugs] #26362 [Applications/Tor Browser]: Use old MAR format when generating the MAR files for the first esr60-based alpha

[Tor Bug Tracker & Wiki]

#26362: Use old MAR format when generating the MAR files for the first 
esr60-based
alpha
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:  #26050   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by boklm):

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


Comment:

 Replying to [comment:1 gk]:
 > `bug_26362` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26362=befc4910feb0eee2016e1ed31e3fea7ef6b1)
 has a patch for review. I'll file a follow-up ticket keeping track of
 removing `MAR_OLD_FORMAT=1` again, later on.

 This looks good to me. I pushed it to master as commit
 `befc4910feb0eee2016e1ed31e3fea7ef6b1`.

 > boklm: I did not find much about `capture_exec()` but I assumed that the
 env vars set are passed along to it. Let me know if thats not the case and
 I can try to rip those out of the Makefile rules and put them directly
 into the `capture_exec()` calls.

 Yes, like normal `exec` the env vars should be passed along.

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

Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start in localized Windows bundle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start in localized Windows bundle
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201806   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:1 mcs]:
 > Kathy and I can reproduce this on Windows (32-bit de build) but not on
 macOS (de build).
 >
 > It almost seems like an e10s problem, but I am not sure why it would be
 Windows-specific.
 >
 > We also see both the Firefox "spoof language?" prompt as well as the
 Torbutton one. Is there already a ticket open for that issue?

 Now we have: #26409.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26409 [Applications/Tor Browser]: Language prompt is shown twice at first start in Tor Browser based on ESR60

[Tor Bug Tracker & Wiki]

#26409: Language prompt is shown twice at first start in Tor Browser based on 
ESR60
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr, tbb-
 Severity:  Normal   |  torbutton, TorBrowserTeam201806
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The "spoof locale" prompt is shown twice in a non-en-US Tor Browser. I
 guess we can retire the Torbutton version?

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

[tor-bugs] #26408 [Applications/Tor Browser]: Make MAR signature checks clearer when creating incremental MAR files

[Tor Bug Tracker & Wiki]

#26408: Make MAR signature checks clearer when creating incremental MAR files
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We have
 {{{
 # bug 26054: make sure previous macOS version is code signed
 if (($os eq 'osx64') && ! -f
 "$tmpdir/A/Contents/_CodeSignature/CodeResources") {
 exit_error "Missing code signature in $from_version while creating
 $mar_file";
 }
 if ($ENV{CHECK_CODESIGNATURE_EXISTS}) {
 unless (-f "$tmpdir/A/Contents/_CodeSignature/CodeResources"
 && -f "$tmpdir/B/Contents/_CodeSignature/CodeResources") {
 exit_error "Missing code signature while creating $mar_file";
 }
 }
 }}}
 checking twice whether essentially osx64 MAR files are signed. We should
 simplify that and be more verbose about why we are doing that and what the
 differences between both checks are. Otherwise this is easily confusing.

 For simplification, I guess we don't need two separate if-clauses, rather
 the `CHECK_CODESIGNATURE_EXISTS` one could be part of the first one, just
 checking for `$tmpdir/B/Contents/_CodeSignature/CodeResources` (as the
 first condition is already taken care of by the first if-clause).

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

Re: [tor-bugs] #26362 [Applications/Tor Browser]: Use old MAR format when generating the MAR files for the first esr60-based alpha

[Tor Bug Tracker & Wiki]

#26362: Use old MAR format when generating the MAR files for the first 
esr60-based
alpha
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:  #26050   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff60-esr, TorBrowserTeam201806 => ff60-esr,
 TorBrowserTeam201806R
 * status:  new => needs_review


Comment:

 `bug_26362` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26362=befc4910feb0eee2016e1ed31e3fea7ef6b1)
 has a patch for review. I'll file a follow-up ticket keeping track of
 removing `MAR_OLD_FORMAT=1` again, later on.

 boklm: I did not find much about `capture_exec()` but I assumed that the
 env vars set are passed along to it. Let me know if thats not the case and
 I can try to rip those out of the Makefile rules and put them directly
 into the `capture_exec()` calls.

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

Re: [tor-bugs] #25741 [Applications/Tor Browser]: Create tor-browser for mobile branch based on mozilla-central

[Tor Bug Tracker & Wiki]

#25741: Create tor-browser for mobile branch based on mozilla-central
--+-
 Reporter:  gk|  Owner:  sysrqb
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-mobile, TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

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


Comment:

 We'll base TBA on ESR60 instead of follow -release and/or -central. See
 #26401. Once we start to do the automatic rebasing of our patches (which
 is still a good idea) we should open a new bug tracking all the problems
 we hit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26407 [Applications/Tor Browser]: Go over security slider governed preferences and update them where needed

[Tor Bug Tracker & Wiki]

#26407: Go over security slider governed preferences and update them where 
needed
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr, tbb-security-
 Severity:  Normal   |  slider
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While reviewing the patch for #26128 i realized there are new preferences
 we might to add (`javascript.options.wasm_baselinejit` and
 `javascript.options.wasm_ionjit` come to mind) and there might be old ones
 we could remove. We should double-check that during the ESR60
 stabilization.

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

Re: [tor-bugs] #26128 [Applications/Tor Browser]: Make security slider work with NoScript for ESR60

[Tor Bug Tracker & Wiki]

#26128: Make security slider work with NoScript for ESR60
-+--
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201806R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

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


Comment:

 ma1: Thanks!

 I merged `26128+1` to `master` (commit
 1e43e9c6ed448d9ca91235c38f5ea0b4d43c71cb). Arthur: Could you file the
 follow-up tickets you had in mind?

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
-+-
 Reporter:  isabela  |  Owner:
 |  pospeselr
 Type:  project  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, tor-hs, |  Actual Points:
  TorBrowserTeam201806R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good. It seems we are done here, nice work Richard! I applied the
 patches to `master` in our Torbutton repo (commit
 65b5371aadb32835b99ca56fc8feb43bef81a78e) and to `tor-
 browser-60.0.1esr-8.0-1` in our tor-browser repo (commit commit
 06fd55e2e061c7348f86d7f0ced3d64ffac9baad).

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

Re: [tor-bugs] #25765 [Applications/Tor Browser]: TBA - Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#25765: TBA - Communicating security expectations for .onion: what to say about
different padlock states for .onion services
---+--
 Reporter:  antonela   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * parent:  #23247 =>


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

Re: [tor-bugs] #13988 [Core Tor/Tor]: Report bandwidth usage aggregated over a longer period

[Tor Bug Tracker & Wiki]

#13988: Report bandwidth usage aggregated over a longer period
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.2.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-relay stats 025-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by AnubuGoering):

 Replying to [ticket:13988 nickm]:
 > NUM_SECS_BW_SUM_INTERVAL == 15 minutes seems pretty short; can we go up
 to 4 hours or 6 hours or so?
 >
 > Note that while 0.2.2.x was still on the network we couldn't do this:
 > {{{
 > /** How large are the intervals for which we track and report bandwidth
 use? */
 > /*  Watch out! Before Tor 0.2.2.21-alpha, using any other value here
 would
 >  * generate an unparseable state file. */
 > #define NUM_SECS_BW_SUM_INTERVAL (15*60)
 > }}}
 >
 > But now, nobody should be downgrading to 0.2.2.x; this change should be
 approximately trivial.

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

Re: [tor-bugs] #26382 [Internal Services/Tor Sysadmin Team]: Please create support.tpo on the www rotation

[Tor Bug Tracker & Wiki]

#26382: Please create support.tpo on the www rotation
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #26382 [Internal Services/Tor Sysadmin Team]: Please create support.tpo on the www rotation

[Tor Bug Tracker & Wiki]

#26382: Please create support.tpo on the www rotation
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Yes please!

 Isa and hiro are all set to roll this one out as our first of the new
 websites.

 They were waiting to have some plan for integrating search into it, but we
 realized that it's just one big web page, so we don't need to answer all
 of the design questions for integrating search quite yet (and we
 definitely don't need that to block getting this website up).

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

Re: [tor-bugs] #26196 [Core Tor/Tor]: Abort in test_bridges.c

[Tor Bug Tracker & Wiki]

#26196: Abort in test_bridges.c
-+-
 Reporter:  gvanem   |  Owner:  rl1987
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  crash, tests, 029-backport,  |  Actual Points:
  031-backport 032-backport 033-backport |
  034-backport fast-fix  |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-

Comment (by rl1987):

 `bridges/clear_bridge_list` was introduced in
 c2c5b13e5d8a7736028940175f182fda1ec9 and first shipped in
 0.3.4.1-alpha. This specific patch should go to maint-0.3.4 and master.
 Child tickets did apply to earlier series of tor and were merged
 accordingly.

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