Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ewong):

 Replying to [comment:8 teor]:
 ve you checked that mass replace passes `make check-spaces`?
 >
 > I think this line is too long, and there may be others:
 > {{{
 > static char nil_bytes[16] = { [0]=0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0 };
 > }}}

 ah right.  Point taken.

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I'm not sure if we want to add spaces after integers in structure
 initialisations, or in MOCK_IMPL declarations. But it seems ok to me. I'll
 leave it to nickm to make the final call.

 Also, have you checked that mass replace passes `make check-spaces`?

 I think this line is too long, and there may be others:
 {{{
 static char nil_bytes[16] = { [0]=0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0 };
 }}}

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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  0.7
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * actualpoints:  0.5 => 0.7


Comment:

 I've updated my bug23493 branch.

 Replying to [comment:13 asn]:
 > Here is a short review:
 >
 > - Not a big fan of poking into the guts of service with
 `service->config.is_single_onion` to figure out if SoS or not. I suggest
 now that we are more serious about this feature to use a function like
 `int service_is_single_onion(hs_service_t *)`.

 I was always serious about this feature :-)

 And I agree, it's important to have a read-only accessor when we are
 passing inout references to a copy of that flag.

 See commit 76d25b0b74.

 That said, the existing code doesn't have accessors for any of the other
 flags in config, so it's up to you if you want this flag to be different.

 > - `direct_conn_inout` is a weird variable name. Why `inout` and not
 `out`? Also let's improve variable naming so that this `BUG` makes a bit
 more sense `if (BUG(direct_conn && direct_conn_inout &&
 !*direct_conn_inout)) {`.

 I rewrote the function comment and made the variable naming clearer in
 fixup b51005940d.

 > - `7c3ba98cd` is a bit sketch. I wonder how come that was not needed
 before.

 It's needed to make sure that we don't connect to an address that's banned
 by ReachableAddresses, ClientUseIPv4/6, or similar options, which have
 been around for a long time. In previous releases, we trusted calling code
 to do the right thing.

 > If it was not needed, is it just defense-in-depth?

 Yes, it's defense in depth.

 > Can we add a non-fatal assert to make sure it never triggers?

 We could, but I think a BUG() condition is the right way to go here - it
 allows us to log the error, and respond correctly by refusing to connect
 to the address.

 I also added a comment that explains the change in fixup commit
 79875f084b.

 > Also, is `extend_info_is_a_configured_bridge()` the right thing to do?
 What happens if the bridge has a PT on a different address than the
 bridge?

 `!extend_info_is_a_configured_bridge()` is the right thing to do, because
 bridges with PTs routinely lie about their addresses, and bridges without
 PTs have always been allowed to connect to their configured addresses. PT
 reachable addresses aren't controlled by tor, and are apparently out of
 scope for PT 2.0, too.

 > - It's kinda scary that there is no unittests for any of the SoS HSv3
 logic.

 I agree, but I don't have any time to write any this week. Can we open a
 separate ticket for this in 0.3.2?

 Replying to [comment:14 nickm]:
 > Additional minor notes:
 >
 >   * The log message "Launching a %s circuit" will say "launching a
 anonymous circuit" when "an anonymous circuit" would be correct.

 Fixup 898495e6bd.

 >   * Looks like "make check-spaces" will fail.

 Oops. I had that in my workflow, but it dropped out.

 Fixup 15bc97ee7d.

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

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

[Tor Bug Tracker & Wiki]

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:14 cmm323]:
 > >The other changes in the snowflake branch look good. Please also
 merge/rebase with my commits at
 ​https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628
 (which include the tests for SDP parsing).
 > {{{
 > git remote add dcf https://git.torproject.org/user/dcf/snowflake.git
 > git fetch dcf
 > git merge dcf bug18628 # or rebase, deal with conflicts
 > }}}
 >
 > Done in private repo. You can push to your repo.

 Perfect. Pushed in
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628=421bc5836875aa23bc1b20f600f160e2b34bded9
 421bc583687].

 Now all that remains is to make `remoteIPFromSDP` pass its tests. I have
 an idea for doing that. Let me know if you want me to do it or if you want
 to do it yourself.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 Replying to [comment:54 gk]:
 > `bug_16010_v4` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_16010_v4) has the `tor-browser` patches for review.
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_16010_v4=03833cf4c2a833f6e5420e92368ac2dae1b99c70
 has the additional code changes I needed to apply.
 >
 > Attached is a fix for the `tor-browser-build` site as well as this is
 still needed due to different `.mozconfig` handlings.

 I also had a look and didn't find any obvious errors, though I too am not
 familiar with the problems. I think it might be useful to briefly document
 the compile issues fixed in the first patch, either as comments or in the
 commit message.

 One thing that puzzled me is the section here:
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/diff/security/sandbox/chromium-
 
shim/base/win/sdkdecls.h?h=bug_16010_v4=4f613829fdcbf6dba4e80e8df1d356cb1c0a7de7
 You have changed one constant integer to the uLL suffix, but the others
 remain ui64. I'm wondering it there's a reason 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] #23592 [Core Tor/Tor]: Update longclaw's IPv4 address (after it moves)

[Tor Bug Tracker & Wiki]

#23592: Update longclaw's IPv4 address (after it moves)
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir-auth  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:5 micah]:
 > I am hoping that I can complete the hardware work that needs to be done
 next week. After that it is about another week and then I can move
 longclaw. So I think 2-3 weeks max. My goal is to have this done before
 the tor meeting in Montreal.

 Excellent.
 While longclaw is down, we will only have 3 bandwidth authorities.
 How long will longclaw be down for?

 > I will be able to forward IPs for a while afterwards without any
 trouble.

 This is great, especially for 0.2.5 client bootstrap.

 (Longclaw was introduced in 0.2.4, we no longer support 0.2.4, 0.2.6 or
 0.2.7, and 0.2.8 onwards have fallback directory mirrors for bootstrap.)

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

Re: [tor-bugs] #22805 [Core Tor/Tor]: Remove or_circuit_t.is_first_hop, because it's not accurate any more

[Tor Bug Tracker & Wiki]

#22805: Remove or_circuit_t.is_first_hop, because it's not accurate any more
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, security-review, |  Actual Points:  .3
  review-group-23|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:16 nickm]:
 > Replying to [comment:14 teor]:
 > > I think we can take out all the code that deals with CREATE_FAST,
 including the code around `cfe6b444d652464b0b6bb18b4a4a24b0cfb0da81`
 >
 > I've updated bug22805_v2 with this change.

 Let's get this merged.

 > > and just check for a non-zero identity digest.
 >
 > Hm; that's a bigger change than we'd been talking about here; I think I
 should open another ticket to change it in 0.3.3. Would that be okay with
 you?

 Sounds like a good plan.

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, tor-bug-warning,|  Actual Points:
  030-backport, 031-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  closed => reopened
 * resolution:  fixed =>
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.0.x-final


Comment:

 Hang on, this needed to go back to 0.3.0 as well as 0.3.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] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 O.  `out_len_orig == 0` seems like the problem 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] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Felixix):

 {{{
 Tor 0.3.2.1-alpha (git-290274dbb5428bc5) running on FreeBSD with Libevent
 2.1.8-stable, OpenSSL LibreSSL 2.5.4, Zlib 1.2.8, Liblzma 5.2.2, and
 Libzstd 1.3.1.
 More info on the bug: method == Zstandard compressed, finish == 0,
 *in_len == in_len_orig == 1136, *out_len == out_len_orig == 0
 }}}

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

Re: [tor-bugs] #23592 [Core Tor/Tor]: Update longclaw's IPv4 address (after it moves)

[Tor Bug Tracker & Wiki]

#23592: Update longclaw's IPv4 address (after it moves)
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir-auth  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by micah):

 I am hoping that I can complete the hardware work that needs to be done
 next week. After that it is about another week and then I can move
 longclaw. So I think 2-3 weeks max. My goal is to have this done before
 the tor meeting in Montreal.

 I will be able to forward IPs for a while afterwards without any trouble.

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

Re: [tor-bugs] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Me neither: I'll merge, wait for our CI, and close if it works out.

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

Re: [tor-bugs] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Looks good, but I don't have a readily-accessible 32-bit system to test
 on.

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #7164 [Core Tor/Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1

[Tor Bug Tracker & Wiki]

#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still 
referenced
1 node(s); held_by_nodes == 1
-+-
 Reporter:  jaj123   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-backport, nickm- |  Actual Points:
  should-review  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Branch `bug7164_032` is a rebase of the older attempted fix (possibly
 irrelevant) with the other fix suggested above.

 I don't see how clearing all the md values is necessary in
 nodelist_set_consensus() -- any microdesc value not reached in the main
 loop in that function should get removed later, by nodelist_purge().

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

Re: [tor-bugs] #22501 [Applications/Tor Browser]: Requests via javascript: violate FPI

[Tor Bug Tracker & Wiki]

#22501: Requests via javascript: violate FPI
--+---
 Reporter:  cypherpunks   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 Extra repro step, need to set security slider to 'Medium'

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

Re: [tor-bugs] #23582 [Applications/Tor Browser]: Increased crash rate due to disabled Windows DLL blocklist

[Tor Bug Tracker & Wiki]

#23582: Increased crash rate due to disabled Windows DLL blocklist
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201709,|  Actual Points:
  GeorgKoppen201709, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 The latter (the warnings bug) should not break compilation.

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

Re: [tor-bugs] #23614 [Internal Services/Tor Sysadmin Team]: Switch tp.org Onion Services to "v3"

[Tor Bug Tracker & Wiki]

#23614: Switch tp.org Onion Services to "v3"
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #22805 [Core Tor/Tor]: Remove or_circuit_t.is_first_hop, because it's not accurate any more

[Tor Bug Tracker & Wiki]

#22805: Remove or_circuit_t.is_first_hop, because it's not accurate any more
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, security-review, |  Actual Points:  .3
  review-group-23|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:14 teor]:
 > I think we can take out all the code that deals with CREATE_FAST,
 including the code around `cfe6b444d652464b0b6bb18b4a4a24b0cfb0da81`

 I've updated bug22805_v2 with this change.

 > and just check for a non-zero identity digest.

 Hm; that's a bigger change than we'd been talking about here; I think I
 should open another ticket to change it in 0.3.3. Would that be okay with
 you?

 > If a connecting peer has a zero identity digest, it's a client/bridge,
 if it doesn't, it's a relay. (A listening peer is always a relay.
 Interestingly, bridges look like relays to clients, but look like clients
 to public relays.)
 >
 > If a connecting peer uses CREATE_FAST, it might be an old client, or a
 bootstrapping client, or a bootstrapping relay (on 0.2.9 and later).




 > But I'm unsure what happens after the initial circuit, when a
 bootstrapping relay `A` uses CREATE_FAST to `B`.
 >
 > Does `A` authenticate to the listening relay `B` once `A` has a
 consensus?
 >
 > Or, if `A` has authenticated `B`, but `B` never authenticated `A`:
 > * does `A` discard its early connection to `B`?
 > * does `A` use its early connections for client extends to `B`, but `B`
 doesn't use that connection for client extends to `A`?

 So, authentication decisions aren't made as part of the
 CREATE/CREATE2/CREATE_FAST layer: they all happen as part of the
 connection layer.  Relays ''always'' offer authentication, and they don't
 need a consensus to do so.  So if two relays are talking, then in theory
 they should always do so in an authenticated 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] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Mostly looks good; thanks!  I would suggest adding a sentence or two in
 HowToReview.md and possibly also CodingStandards.md about trying to
 conform to the changes file writing style that release engineers will
 apply in II.1.2 of ReleasingTor.md.  (That way we can hopefully get
 reviewers and patch authors to help take more text writing/editing load
 off of the release engineers.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23614 [Internal Services/Tor Sysadmin Team]: Switch tp.org Onion Services to "v3"

[Tor Bug Tracker & Wiki]

#23614: Switch tp.org Onion Services to "v3"
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Should probably happen until 0.3.2.x stable hits a stable Tor Browser
 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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  crowdfunding,|  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:  #23482   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * cc: phoul (added)


Comment:

 Replying to [comment:9 cypherpunks]:
 > Replying to [comment:1 arthuredelstein]:
 >
 > FWIW there's an error in the French translation: "la puissance de
 resistance numerique" should be ""la puissance de **la** resistance
 numerique.

 Thanks. Colin, is that something you can edit on Transifex?

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

Re: [tor-bugs] #22501 [Applications/Tor Browser]: Requests via javascript: violate FPI

[Tor Bug Tracker & Wiki]

#22501: Requests via javascript: violate FPI
--+---
 Reporter:  cypherpunks   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * status:  new => assigned
 * owner:  tbb-team => pospeselr


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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  crowdfunding,|  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:  #23482   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:1 arthuredelstein]:

 FWIW there's an error in the French translation: "la puissance de
 resistance numerique" should be ""la puissance de **la** resistance
 numerique.

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  crowdfunding,|  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:  #23482   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  crowdfunding, TorBrowserTeam201709R => crowdfunding,
 TorBrowserTeam201709R, tbb-backport
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Alright, looks good now, thanks. This landed on `master` (commit
 b3ff9863db338b2bd612f109e8bbce4c4af7cbd0).

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

Re: [tor-bugs] #23406 [Core Tor/Tor]: Sampled guards are not re-weighted when a new consensus arrives

[Tor Bug Tracker & Wiki]

#23406: Sampled guards are not re-weighted when a new consensus arrives
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  path-selection, tor-guard  |  Actual Points:
Parent ID:  #23318 | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #23374 [Core Tor/Tor]: Circuit dirtiness is inconsistant with MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#23374: Circuit dirtiness is inconsistant with MaxCircuitDirtiness
--+
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_information


Comment:

 Three observations:

 1) Hm. In shadow, maybe we should define TIME_IS_FAST?

 The approx_time() value is updated from second_elapsed_callback(), so if
 it's getting 9 seconds behind time(NULL), that's a very strange sign.

 2) When you say,

 > It happens only for 2 begin cells containing same IP

 That's probably good -- it means IsolateDestAddr is working.
 (IsolateDestAddr is the one that means "never sent connections to
 different targets over the same circuit.")

 3) Have you patched Tor to allow "MaxCircuitDirtiness 1" ?  By default, it
 should be saying:

 {{{
 Sep 21 16:52:54.348 [warn] MaxCircuitDirtiness option is too short;
 raising to 10 seconds.
 }}}

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

Re: [tor-bugs] #20895 [Core Tor/Tor]: Split node_supports_ed25519_link_authentication into two or three separate functions

[Tor Bug Tracker & Wiki]

#20895: Split node_supports_ed25519_link_authentication into two or three 
separate
functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:  #15054| Points:  2
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 (Deferred to 0.3.3, since any problems here are likely to be subtle)

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

Re: [tor-bugs] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Somewhat improved in 2032d7ca6f0d08.  Do you like this now?  If so let's
 close this and its parent.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Why not to use `MOZ_SEH_TRY` and `MOZ_SEH_EXCEPT(expr)`?

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

Re: [tor-bugs] #23564 [Core Tor/Tor]: run make check-changes in CI

[Tor Bug Tracker & Wiki]

#23564: run make check-changes in CI
---+
 Reporter:  catalyst   |  Owner:  nickm
 Type:  task   | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562 | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Squashed and merged; "make check" still passes. :)

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

Re: [tor-bugs] #23564 [Core Tor/Tor]: run make check-changes in CI

[Tor Bug Tracker & Wiki]

#23564: run make check-changes in CI
---+
 Reporter:  catalyst   |  Owner:  nickm
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562 | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


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

Re: [tor-bugs] #23564 [Core Tor/Tor]: run make check-changes in CI

[Tor Bug Tracker & Wiki]

#23564: run make check-changes in CI
---+
 Reporter:  catalyst   |  Owner:  nickm
 Type:  task   | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562 | Points:
 Reviewer: |Sponsor:
---+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good; thanks!  `changes/bug23610` on master needs fixing up when
 merging because it currently fails check-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] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201709R  |  Actual Points:
Parent ID:  #23482   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review
 * keywords:  crowdfunding, TorBrowserTeam201709 => crowdfunding,
 TorBrowserTeam201709R


Comment:

 Another good find. Here is the new version:
 https://github.com/arthuredelstein/torbutton/commit/23483+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] #23582 [Applications/Tor Browser]: Increased crash rate due to disabled Windows DLL blocklist

[Tor Bug Tracker & Wiki]

#23582: Increased crash rate due to disabled Windows DLL blocklist
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201709,|  Actual Points:
  GeorgKoppen201709, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Neat, but aren't you experiencing this
 https://bugzilla.mozilla.org/show_bug.cgi?id=1380103 or any of these
 https://bugzilla.mozilla.org/show_bug.cgi?id=1394433?

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

Re: [tor-bugs] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

[Tor Bug Tracker & Wiki]

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+--
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by isis):

 Replying to [comment:5 cypherpunks]:
 > Replying to [comment:4 gk]:
 > > See #23609 for what they, arma, and I did. There was no response with
 a POST request etc. involved. The CAPTCHA page did not even show up. It
 works now again fwiw. Seems like a WORKSFORME now.
 >
 > I can confirm all of this, didn't even show up the captcha for me then,
 and it worked for me now.

 Cool, thanks for confirming! I'll add some extra debug log messages and
 try to figure out how this happens.

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

Re: [tor-bugs] #23564 [Core Tor/Tor]: run make check-changes in CI

[Tor Bug Tracker & Wiki]

#23564: run make check-changes in CI
---+
 Reporter:  catalyst   |  Owner:  nickm
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562 | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Thanks for the review, catalyst!

 The dotfile thing was wrong, but for another reason: It should have
 applied inside the `listdir` loop, on the outputs of `listdir`.

 I've gone with the non-`walk` approach, since the changes directory does
 not contain directories itself.

 Fixup commit pushed to `ticket23564`. Better now?

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:60 mcs]:
 > Kathy and I reviewed the proposed changes. They seem fine although we
 admit that we do not understand this stuff very well. We do have a couple
 of questions about the "Bug 16010: Fixing sandbox compile issues" patch:
 >
 > 1. For
 security/sandbox/chromium/sandbox/win/src/sidestep/mini_disassembler_types.h:
 is there a missing `int` in the declaration of `flag_aux_`? This probably
 does not matter because types default to `int` anyway.

 I think you are right, good catch. I'll make a fixup for that.

 > 2. For security/sandbox/chromium/sandbox/win/src/sidestep_resolver.cc:
 do we know what the implications are for the FIXME (making
 `SmartSidestepResolverThunk::SmartStub()` a NOOP)?

 I trust bobowen when he says this one does not get used right now:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1230910#c28. So, we should be
 fine.

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

Re: [tor-bugs] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 I think I've tracked these down. I suggest only fixing them in 0.3.2.

 See branch `bug21800`.

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  crowdfunding, TorBrowserTeam201709R => crowdfunding,
 TorBrowserTeam201709
 * status:  needs_review => needs_revision


Comment:

 Another thing I found:
 {{{
 if (bannerDataJSON.length > 0) {
 }}}
 it's not guaranteed that you have `bannerDataJSON` at all at this stage.
 Can you add a check for that before you query its length?

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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Stem support pushed:
 https://gitweb.torproject.org/stem.git/commit/?id=bac3947

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

Re: [tor-bugs] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

[Tor Bug Tracker & Wiki]

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+--
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:4 gk]:
 > See #23609 for what they, arma, and I did. There was no response with a
 POST request etc. involved. The CAPTCHA page did not even show up. It
 works now again fwiw. Seems like a WORKSFORME now.

 I can confirm all of this, didn't even show up the captcha for me and it
 worked for me now.

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

Re: [tor-bugs] #23564 [Core Tor/Tor]: run make check-changes in CI

[Tor Bug Tracker & Wiki]

#23564: run make check-changes in CI
---+
 Reporter:  catalyst   |  Owner:  nickm
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562 | Points:
 Reviewer: |Sponsor:
---+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 It looks like a good start!  Seems to produce false negatives if
 `$(top_srcdir)` is, say, `.`.  The dotfile check probably should be
 against `os.path.basename(f)` and should probably be in the `__main__`
 clause.  The file walk seems like it might only go one level deep; this is
 probably OK if we document it, otherwise consider using something like
 `os.walk()`?

 Also, typo ("Ticked" vs "Ticket"):
 {{{
 -warn("bugfix does not say 'Fixes bug XXX'")
 +warn("Ticked marked as bugfix, but does not say 'Fixes bug XXX'")
 }}}

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

Re: [tor-bugs] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => accepted
 * owner:  (none) => nickm


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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Hi Nick. Just a quick head's up that I'm adjusting Stem to account for
 this. The next release (1.6.0) will permit multiple extra entries but
 according to prior versions such version strings are 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] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

[Tor Bug Tracker & Wiki]

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+--
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_information => assigned


Comment:

 Replying to [comment:2 isis]:
 > I think this person also DMed me on IRC. I'd kind of like to know what
 they were doing, if they are still around and getting that response, as
 the server only does this if you respond to the CAPTCHA page with a POST
 request which contains too much data in the URL.  The amount of data for a
 normal CAPTCHA solution is well below the limit, which I think is
 something like 4KB.

 See #23609 for what they, arma, and I did. There was no response with a
 POST request etc. involved. The CAPTCHA page did not even show up. It
 works now again fwiw. Seems like a WORKSFORME now.

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

Re: [tor-bugs] #23303 [Core Tor/Tor]: hs: Explain why we reset the directory connection timestamp client side

[Tor Bug Tracker & Wiki]

#23303: hs: Explain why we reset the directory connection timestamp client side
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by nickm):

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


Comment:

 Merged

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

Re: [tor-bugs] #23611 [Core Tor/Tor]: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete config parameter in manual page

[Tor Bug Tracker & Wiki]

#23611: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete 
config
parameter in manual page
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #23611 [Core Tor/Tor]: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete config parameter in manual page

[Tor Bug Tracker & Wiki]

#23611: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete 
config
parameter in manual page
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Patch in https://oniongit.eu/catalyst/tor/merge_requests/6

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop224, tor-hs, tor-bug-warning,|  Actual Points:
  030-backport, 031-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  reopened => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 cherry-picked to 0.3.1, changes file fixed, merged 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] #12062 [Core Tor/Tor]: Audit DisableNetwork, we_are_hibernating usage

[Tor Bug Tracker & Wiki]

#12062: Audit DisableNetwork, we_are_hibernating usage
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client technical-debt quiet- |  Actual Points:
  mode sponsor8-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 See my branch `ticket12062`. Delaying to 0.3.3 since this is tricky to
 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

Re: [tor-bugs] #12062 [Core Tor/Tor]: Audit DisableNetwork, we_are_hibernating usage

[Tor Bug Tracker & Wiki]

#12062: Audit DisableNetwork, we_are_hibernating usage
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client technical-debt quiet- |  Actual Points:
  mode sponsor8-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 (None of the bugs found here seem terrible, which is good)

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

Re: [tor-bugs] #23611 [Core Tor/Tor]: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete config parameter in manual page

[Tor Bug Tracker & Wiki]

#23611: misspelled reference "UseEntryGuardsAsDirectoryGuards" to obsolete 
config
parameter in manual page
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * owner:  (none) => catalyst
 * 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] #23303 [Core Tor/Tor]: hs: Explain why we reset the directory connection timestamp client side

[Tor Bug Tracker & Wiki]

#23303: hs: Explain why we reset the directory connection timestamp client side
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Thanks Mike! I think I get it and it makes sense.

 Branch: `ticket23303_032_01`.

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

Re: [tor-bugs] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

[Tor Bug Tracker & Wiki]

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+---
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by isis):

 * status:  new => needs_information


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

Re: [tor-bugs] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

[Tor Bug Tracker & Wiki]

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+--
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by isis):

 I think this person also DMed me on IRC. I'd kind of like to know what
 they were doing, if they are still around and getting that response, as
 the server only does this if you respond to the CAPTCHA page with a POST
 request which contains too much data in the URL.  The amount of data for a
 normal CAPTCHA solution is well below the limit, which I think is
 something like 4KB.

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, tor-bug-warning,|  Actual Points:
  030-backport, 031-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  closed => reopened
 * keywords:  prop224, tor-hs, tor-bug-warning => prop224, tor-hs, tor-bug-
 warning, 030-backport, 031-backport
 * resolution:  fixed =>


Comment:

 I made a small mistake, this applies to `tor-0.3.0.1-alpha` which means
 this could qualify for an 031 and 030 backport if we don't want to trigger
 BUG() (rare) on those versions.

 So the changes file should just be modified with that. SORRY

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  needs_review => merge_ready


Comment:

 `bug23581_032_03` on  ​https://github.com/pastly/public-tor.git

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Seem this comment is wrong or misplaced:

 {{{
 +/** Scheduler type, we build an ordered list with those values from the
 + * parsed strings in Schedulers. The reason to do such a thing is so we
 can
 + * quickly and without parsing strings select the scheduler at anytime.
 */
 +typedef enum {
 }}}

 I'm a bit worried here with the use of `SCHEDULER_NONE = 0`, not that it
 is logically wrong but because it is the "default type" that any scheduler
 object will get with a static initialization or `tor_malloc_zero()` that
 is 0. It just seems semantically weird to have this option... This is why
 in the first place, I started the first type at 1 so if you forget to set
 the type, some validation should catch it (well validation we don't have
 but you get the concept :P).

 Anyway, no strong opinion if nickm is fine with this approach. Else, we
 can just make `old_scheduler_type` a int, set it to -1 and we are for sure
 certain that it can't be a scheduler type never ever.

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.2.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  prop224, tor-hs, tor-bug-warning  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 looks fine; merging

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Tiny nitpick, extra indent with the last two lines of the text:

 {{{
 +log_err(LD_SCHED, "Tor was unable to select a scheduler type. Please
 "
 +   "make sure Schedulers is correctly configured with
 "
 +   "what Tor does support.");
 }}}

 Apart from that, lgtm. Once this is fixed ^, you can just `merge_ready`
 it. 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] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  assigned => needs_review


Comment:

 bug23552_032_02 on https://github.com/pastly/public-tor.git

 Includes:

 - #23581 commit
 - A manual rebase onto the latest master to resolve code movement
 - `SCHEDULER_NONE` in the enum

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224, tor-hs, tor-bug-warning  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 See branch: `bug23610_032_01`

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  needs_revision => assigned
 * owner:  dgoulet => pastly


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23613 [Core Tor/Tor]: some control protocol GETINFO downloads/networkstatus keys are lies

[Tor Bug Tracker & Wiki]

#23613: some control protocol GETINFO downloads/networkstatus keys are lies
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bootstrap tor-control tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Some of the `GETINFO downloads/networkstatus/*` keys are misleadingly
 named, and some can't possibly produce what they claim to do given the
 internal state of tor.

 During bootstrap, only one flavor of consensus gets downloaded, but there
 are separate download schedules for mirror vs authority.  After bootstrap,
 there are separate download schedules for each flavor of consensus.
 Currently, the control protocol returns authority and mirror bootstrap
 schedules when asked for ns and microdesc bootstrap schedules,
 respectively.

 We should accept `downloads/networkstatus/mirror/bootstrap` and
 `downloads/networkstatus/authority/bootstrap` keywords and return the
 appropriate schedules.

 `downloads/networkstatus/ns/bootstrap` and
 `downloads/networkstatus/microdesc/bootstrap` should only return valid
 results for the flavor we're using to bootstrap.  There is the question of
 whether to return the mirror or authority schedule.

 If the controller doesn't specify bootstrap vs running, should we use the
 "running" schedule during bootstrap if we're asked for a flavor that we're
 not using to bootstrap?

 We should return an error code like `552` (unrecognized entity -- or is a
 different code better here?) if the requested information isn't available.

 Thanks to teor for feedback.

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

Re: [tor-bugs] #23396 [Applications/Tor Browser]: Update the msvcr100.dll we ship in Tor Browser

[Tor Bug Tracker & Wiki]

#23396: Update the msvcr100.dll we ship in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > Because Microsoft cannot automatically update locally deployed Visual
 C++ libraries, we caution against local deployment of these libraries. If
 you decide to use local deployment of redistributable libraries, we
 recommend that you implement your own method of automatically updating the
 locally deployed libraries.
 https://docs.microsoft.com/en-us/cpp/ide/deployment-in-visual-cpp#local-
 deployment

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201709R  |  Actual Points:
Parent ID:  #23482   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  crowdfunding, TorBrowserTeam201709 => crowdfunding,
 TorBrowserTeam201709R
 * status:  needs_revision => needs_review


Comment:

 Thanks for the review and good catches. I had used jshint but didn't
 realize that catching undefined variables was off by default.
 https://github.com/arthuredelstein/torbutton/commit/23483+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] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  assigned => 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] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * owner:  dgoulet => pastly
 * status:  needs_review => 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] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  needs_revision => needs_review


Comment:

 bug23581_032_02 on https://github.com/pastly/public-tor.git

 Changed to log_err and rebased on current master.

 Yes it will likely conflict with #23552. I think this should be merged
 first since it is simpler.

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

Re: [tor-bugs] #22692 [Applications/Tor Browser]: Backport Linux content sandboxing from Firefox 54

[Tor Bug Tracker & Wiki]

#22692: Backport Linux content sandboxing from Firefox 54
-+-
 Reporter:  jld  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  GeorgKoppen201709,   |  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  GeorgKoppen201709, TorBrowserTeam201709R => GeorgKoppen201709,
 TorBrowserTeam201709R, tbb-backport
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks. I put all the relevant commits onto `tor-browser-52.3.0esr-7.5-2`:

 commit bf2b5cefbaddca978d5c5eca3b54f0f0af5c8d32
 commit e3693eef06cadfc24d50abe34ae1bedf0385c3f8
 commit 45459c3c090384c1632ac5c2aa4323ed6df656ce
 commit 9a694d0d0cda658157ec2f86e68db0e72b556e04
 commit d63e9b803e99682fc561e60c81cbe7b793b7b70f
 commit 8bf9587a88239cdac723a5b1c37ef46a90a49c21
 commit 08e00435a6657b00a06f7650276944d9b36ee36d
 commit 5b224c4272f4752dea577c92f41b2f651778e975
 commit 722a1a652291a27657ed1a0b7eefd134519daa8f
 commit 018cc6d1fd6751a21bb46aa1b9afc7ca96a42c8c

 jld, thanks again for doing the work for us. If you could watch out for
 further sandbox related security fixes that would be neat.

 This will be available in our upcoming alpha, Tor Browser 7.5a5.

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

Re: [tor-bugs] #23612 [Webpages/Website]: Outdated (dead) repository links in 'Installing Tor on Debian/Ubuntu' documentation

[Tor Bug Tracker & Wiki]

#23612: Outdated (dead) repository links in 'Installing Tor on Debian/Ubuntu'
documentation
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation repository debian  |  Actual Points:
  ubuntu |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * component:  - Select a component => Webpages/Website


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23612 [- Select a component]: Outdated (dead) repository links in 'Installing Tor on Debian/Ubuntu' documentation

[Tor Bug Tracker & Wiki]

#23612: Outdated (dead) repository links in 'Installing Tor on Debian/Ubuntu'
documentation
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  - Select a   |Version:
  component  |   Keywords:  documentation
 Severity:  Normal   |  repository debian ubuntu
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The experimental repository links in the 'Installing Tor on Debian/Ubuntu'
 documentation (https://www.torproject.org/docs/debian) are outdated (and
 dead). They point to tor-experimental-0.3.1.x (deb) or tor-
 experimental-0.3.0.x (deb-src), but
 https://deb.torproject.org/torproject.org/dists/ only contains tor-
 experimental-0.3.2.x.

 As expected, the original links result in a 404 error, changing them
 manually to tor-experimental-0.3.2.x fixes the problem.

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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-disk-leak, tbb-proxy-bypass, TorBrowserTeam201709R => tbb-
 disk-leak, tbb-proxy-bypass, TorBrowserTeam201709
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:58 mcs]:
 > Replying to [comment:57 gk]:
 > > Looks still good to me. mcs/brade: Could you have a second look? I'd
 like to get that one included into the upcoming alphas.
 >
 > r=brade,r=mcs
 > The patch from comment:56 looks good to us.

 Thanks. Pushed this as commit eb7cb8fe69de4ca08b8aa2ece0faeb7ea6217004 and
 setting the status back to `needs_revision`.

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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:57 gk]:
 > Looks still good to me. mcs/brade: Could you have a second look? I'd
 like to get that one included into the upcoming alphas.

 r=brade,r=mcs
 The patch from comment:56 looks good to us.

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

Re: [tor-bugs] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 One suggestion for the test would be to add something like:
  const NORMAL_LINE_HEIGHT_FACTOR = 1.2;
 (and add a comment to refer back to layout/generic/ReflowInput.cpp.

 Also, it seems like it is possible that the tests would fail when the
 anti-fingerprinting pref is turned off, e.g., if the line-height happens
 to really be 1.2x the font-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] #22805 [Core Tor/Tor]: Remove or_circuit_t.is_first_hop, because it's not accurate any more

[Tor Bug Tracker & Wiki]

#22805: Remove or_circuit_t.is_first_hop, because it's not accurate any more
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, security-review, |  Actual Points:  .3
  review-group-23|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

[Tor Bug Tracker & Wiki]

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Minor issues:
* The "unable to select a scheduler" message should be log_err(), since
 it is fatal.
* This is going to conflict with #23552, right?

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

Re: [tor-bugs] #23606 [Core Tor/Tor]: incorrect clock skew sign convention in or_state_load()

[Tor Bug Tracker & Wiki]

#23606: incorrect clock skew sign convention in or_state_load()
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged as part of #23607

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

Re: [tor-bugs] #23607 [Core Tor/Tor]: Avoid assertion failure for state file clock skew

[Tor Bug Tracker & Wiki]

#23607: Avoid assertion failure for state file clock skew
-+-
 Reporter:  catalyst |  Owner:  catalyst
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bootstrap clock-skew regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 lgtm; merging!

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

Re: [tor-bugs] #22692 [Applications/Tor Browser]: Backport Linux content sandboxing from Firefox 54

[Tor Bug Tracker & Wiki]

#22692: Backport Linux content sandboxing from Firefox 54
-+-
 Reporter:  jld  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  GeorgKoppen201709,   |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:19 gk]:
 > Thanks, I updated `bug_22692_v3` with the two patches (they applied
 cleanly) and will do a rebuild and further test while waiting on review.

 r=brade, r=mcs
 We verified that the correct set of patches was backported. We did not try
 building and running on Linux, but that can be done once we have alpha
 candidate builds.

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

Re: [tor-bugs] #23420 [Core Tor/Tor]: prop224: Pad RENDEZVOUS1 cell to match legacy cell length

[Tor Bug Tracker & Wiki]

#23420: prop224: Pad RENDEZVOUS1 cell to match legacy cell length
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, prop224-extra, tor-hs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  0.5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Additional minor notes:

   * The log message "Launching a %s circuit" will say "launching a
 anonymous circuit" when "an anonymous circuit" would be correct.
   * Looks like "make check-spaces" will fail.

 for asn:
   * "inout" is a convention for "'in and out': the value pointer is both
 read and written." Not sure if that answers your "why not out" naming
 question?

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Two issues:
   - There are significant merge conflicts on master, wrt the code
 movement.
   - I'm not sure it's okay to use "-1" to mean "no type" unless we
 explicitly make "old_type" an int.

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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  easy, tor-spec, spec  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merging the torspec branch; calling this good. :)

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

Re: [tor-bugs] #23608 [Core Tor/Tor]: Some channelpadidng tests still use unmocked time

[Tor Bug Tracker & Wiki]

#23608: Some channelpadidng tests still use unmocked time
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: weasel (added)
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Cherry-picked to maint-0.3.1 and merged forward. Thanks, Mike!

 Weasel, this should fix the sparc64 test failure you reported.

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

Re: [tor-bugs] #23487 [Core Tor/Tor]: Incorrect output on bad directory ownership

[Tor Bug Tracker & Wiki]

#23487: Incorrect output on bad directory ownership
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport 030-backport|  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Calling "no backport".

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

Re: [tor-bugs] #23490 [Core Tor/Tor]: Fix TROVE-2017-008: Stack disclosure in hidden services logs when SafeLogging disabled

[Tor Bug Tracker & Wiki]

#23490: Fix TROVE-2017-008: Stack disclosure in hidden services logs when
SafeLogging disabled
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor:
  |  0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.2.7.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  trove-2017-008 CVE-2017-0380  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.2.8.x-final


Comment:

 Oh hey, I forgot to close this when we put out all those releases on
 Monday. Closing now.

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

Re: [tor-bugs] #23608 [Core Tor/Tor]: Some channelpadidng tests still use unmocked time

[Tor Bug Tracker & Wiki]

#23608: Some channelpadidng tests still use unmocked time
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.1.x-final


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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Kathy and I reviewed the proposed changes. They seem fine although we
 admit that we do not understand this stuff very well. We do have a couple
 of questions about the "Bug 16010: Fixing sandbox compile issues" patch:

 1. For
 security/sandbox/chromium/sandbox/win/src/sidestep/mini_disassembler_types.h:
 is there a missing `int` in the declaration of `flag_aux_`? This probably
 does not matter because types default to `int` anyway.

 2. For security/sandbox/chromium/sandbox/win/src/sidestep_resolver.cc: do
 we know what the implications are for the FIXME (making
 `SmartSidestepResolverThunk::SmartStub()` a NOOP)?

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 Works for me on OSX 029 and on 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] #23607 [Core Tor/Tor]: Avoid assertion failure for state file clock skew (was: control_event_bootstrap_problem() should ignore "early" problems instead of asserting)

[Tor Bug Tracker & Wiki]

#23607: Avoid assertion failure for state file clock skew
-+-
 Reporter:  catalyst |  Owner:  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * keywords:   => bootstrap clock-skew regression


Old description:

> The `clock_skew_warning()` refactoring can allow calls to
> `control_event_bootstrap_problem()` prior to bootstrap phase 0, causing
> an assertion failure.  (Clock skew in a state file is one possibility.)
> Instead of asserting, ignore such calls, because they seem to always have
> another logging path.

New description:

 The `clock_skew_warning()` refactoring can cause an assertion failure when
 `or_state_load()` calls to `control_event_bootstrap_problem()` (via
 `clock_skew_warning()` prior to bootstrap phase 0.

 We should initialize the bootstrap state first.

--

Comment:

 Adjust description to match the narrower scope of the 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] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

[Tor Bug Tracker & Wiki]

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  crowdfunding, TorBrowserTeam201709R => crowdfunding,
 TorBrowserTeam201709
 * status:  needs_review => needs_revision


Comment:

 Looks mostly good. Some nits:

 1) `bestSize` and `bestPadding` are not declared in donation_banner.js.
 (seems I missed that last year ;) )
 2)

 {{{
 +// Increase padding at right to "squeeze" text, until it gets
 +// squeezed so much that it gets longer vertically.
 }}}

 is not correct as is in the case of RTL bundles the padding to the left
 increased. Could you reflect that in the comment?

 In the commit message: "Bug 23483." -> "Bug 23483:"

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224, tor-hs, tor-bug-warning  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => accepted
 * owner:  (none) => dgoulet


Comment:

 Indeed, `hs_intro_send_intro_established_cell()` might mark the circuit
 for close if `relay_send_command_from_edge()` errors.

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

Re: [tor-bugs] #23420 [Core Tor/Tor]: prop224: Pad RENDEZVOUS1 cell to match legacy cell length

[Tor Bug Tracker & Wiki]

#23420: prop224: Pad RENDEZVOUS1 cell to match legacy cell length
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, prop224-extra, tor-hs  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Padding sounds good to me.

 I'd be a bit enthusiastic if we also had unittests to ensure that cell
 parsing is right even tho there is padding at the end.

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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  0.5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Here is a short review:

 - Not a big fan of poking into the guts of service with
 `service->config.is_single_onion` to figure out if SoS or not. I suggest
 now that we are more serious about this feature to use a function like
 `int service_is_single_onion(hs_service_t *)`.

 - `direct_conn_inout` is a weird variable name. Why `inout` and not `out`?
 Also let's improve variable naming so that this `BUG` makes a bit more
 sense `if (BUG(direct_conn && direct_conn_inout && !*direct_conn_inout))
 {`.

 - `7c3ba98cd` is a bit sketch. I wonder how come that was not needed
 before. If it was not needed, is it just defense-in-depth? Can we add a
 non-fatal assert to make sure it never triggers? Also, is
 `extend_info_is_a_configured_bridge()` the right thing to do? What happens
 if the bridge has a PT on a different address than the bridge?

 - It's kinda scary that there is no unittests for any of the SoS HSv3
 logic.

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

Re: [tor-bugs] #10089 [Applications/Tor Browser]: middlemouse.contentLoadURL is set to true by default

[Tor Bug Tracker & Wiki]

#10089: middlemouse.contentLoadURL is set to true by default
-+-
 Reporter:  WDXfjqDN4QKGYrlY |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, tbb-backport,|  Actual Points:
  tbb-pref, TorBrowserTeam201709R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-backport, tbb-pref, TorBrowserTeam201709R => ff59-esr-
 will-have, tbb-backport, tbb-pref, TorBrowserTeam201709R


Comment:

 Let's keep it until we are sure we ship that patch in the ESR52 timeframe.

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

Re: [tor-bugs] #10089 [Applications/Tor Browser]: middlemouse.contentLoadURL is set to true by default

[Tor Bug Tracker & Wiki]

#10089: middlemouse.contentLoadURL is set to true by default
-+-
 Reporter:  WDXfjqDN4QKGYrlY |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-backport, tbb-pref,  |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  ff59-esr-will-have, tbb-backport, tbb-pref,
 TorBrowserTeam201709R => tbb-backport, tbb-pref, TorBrowserTeam201709R


Comment:

 This has been fixed for FF57 so removing `ff59-esr-will-have` keyword.

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

Re: [tor-bugs] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in Tor Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in Tor Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:  gk => tbb-team
 * keywords:  TorBrowserTeam201709R =>


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