Re: [tor-bugs] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-usability, tbb-security-slider => tbb-usability, tbb-
 security-slider, TorBrowserTeam201709


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

Re: [tor-bugs] #21814 [Core Tor/Tor]: Reduce binary size for client-only tor

[Tor Bug Tracker & Wiki]

#21814: Reduce binary size for client-only tor
-+
 Reporter:  arthuredelstein  |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by arthuredelstein:

Old description:

> Uncompressed, the Tor executable and associated libs as bundled in Tor
> Browser is 7.7 MB. If we want other browser to adopt Tor, it would be
> good to make it a lot smaller if possible. What is responsible for the
> bulk? Can we cut out unused code from libcrypto and other libraries? Or
> can we reuse some shared libraries from the browser? Would it help to we
> chop out unused code that implements relays, hidden services, etc.?

New description:

 Uncompressed, the Tor executable and associated libs as bundled in Tor
 Browser is 7.7 MB. If we want other browsers to adopt Tor, it would be
 good to make it a lot smaller if possible. What is responsible for the
 bulk? Can we cut out unused code from libcrypto and other libraries? Or
 can we reuse some shared libraries from the browser? Would it help to chop
 out unused code that implements relays, hidden services, etc.?

--

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

Re: [tor-bugs] #22165 [Applications/Tor Browser]: Rip out the option to collect local IP addresses

[Tor Bug Tracker & Wiki]

#22165: Rip out the option to collect local IP addresses
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R, tbb-fingerprinting  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-7.0-must, TorBrowserTeam201705R => ff52-esr,
 tbb-7.0-must, TorBrowserTeam201705R, tbb-fingerprinting
 * cc: arthuredelstein (added)


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

Re: [tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+--
 Reporter:  gk|  Owner:  neillm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by neillm):

 After inspecting this issue for some time (very easily reproducible by the
 original reporter's steps), as well as examining the previous solution
 (#9701) and finding the shortcomings, I propose that this issue can be
 addressed as follows:

 {{{
 diff --git a/widget/nsTransferable.cpp b/widget/nsTransferable.cpp
 index e99d454..976180c 100644
 --- a/widget/nsTransferable.cpp
 +++ b/widget/nsTransferable.cpp
 @@ -39,6 +39,7 @@ Notes to self:
  #include "nsIFile.h"
  #include "nsILoadContext.h"
  #include "mozilla/UniquePtr.h"
 +#include "mozilla/Preferences.h"

  NS_IMPL_ISUPPORTS(nsTransferable, nsITransferable)

 @@ -248,6 +249,11 @@ nsTransferable::Init(nsILoadContext* aContext)

if (aContext) {
  mPrivateData = aContext->UsePrivateBrowsing();
 +  } else {
 +// without aContext here to provide PrivateBrowsing information,
 +// we defer to the active configured setting
 +mPrivateData =
 +  mozilla::Preferences::GetBool("browser.privatebrowsing.autostart");
}
  #ifdef DEBUG
mInitialized = true;
 }}}

 There are a number of times a transferable is initialized without a
 context that it can use to determine if we're in private browsing mode or
 not (which dictates the value of mPrivateData as seen above).  Rather than
 assuming that we are not by default (the security leak reported), I think
 the TorBrowser should go with the configured 'privatebrowsing' default
 (which is on by default, though it can be disabled in the preferences,
 which resorts to the current/unpatched behavior).

 This patch has been applied to tor-browser-52.2.0esr-7.0-1-build1 and
 tested on Ubuntu 16.04.2 LTS.

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

Re: [tor-bugs] #22948 [Core Tor/Tor]: Padding, Keepalive and Drop cells should have random payloads

[Tor Bug Tracker & Wiki]

#22948: Padding, Keepalive and Drop cells should have random payloads
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * keywords:  tor-spec, security => tor-spec
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Replying to [comment:7 teor]:
 > I don't know how to classify this security issue.
 >
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy
 >
 > Is it low severity: "A defense-in-depth mechanism provides less defense-
 in-depth than it should"?
 > Or is it high severity: A potential denial of service attack that
 affects clients and hidden services?
 > (I split the security policy clarification off into #22962.)
 >
 > Should we fix it in 0.3.1?
 > Should we fill all cells with random bytes? (Split off into #22963.)

 If anything, I would say very-low-severity for the "defense-in-depth
 provides less defense-in-depth than it should", for the reason that arma
 mentions where it could theoretically be easier to forge the end-to-end
 MAC on data seen on a circuit.

 Wait. Let me think how we use this.

 So the defense-in-depth in this case has a lot of assumptions like: if we
 believe that AES-128 is not breakable in close-to-real-time (we do), and
 we believe that neither endpoint is victim to any kleptographic attack (we
 can't defend against that), and we don't believe that an adversary is
 capable of a SHA-256 second-preimage in any reasonable amount of time (we
 don't), then the fact that some subset of cells on a circuit have known
 plaintexts probably doesn't really give you that much of an advantage in
 terms of forging a MAC that is cumulative over all data seen so far (i.e.
 `H(a || b || c || …)` ''not'' "chained" like `H(… || H(c || H(b ||
 H(a`). You'd need a second-preimage on SHA-256, so finding `x'` where
 `H(x) == H(x')`.  And in either case it's the same thing, so !#1

 {{{
 x  = [UNKNOWN_BYTES] || [0x00, …]
 x' = [BYTES_YOU_CAN_TWIDDLE_TO_GET_THE_PREIMAGE] || [0x00, …]
 }}}

 versus !#2

 {{{
 x  = [UNKNOWN_BYTES] || [RANDOM_BYTES]
 x' = [BYTES_YOU_CAN_TWIDDLE] ||
 [THE_SAME_RANDOM_BYTES_OR_SOMETHING_WITH_A_SECOND_PREIMAGE]
 }}}

 So effectively this attack is just as hard (it's still a second-preimage)
 even if you know some of the bytes. That is, there's no realistic
 adversary who's going to look at !#1 and !#2 and be like "Aha, well, I can
 do !#1 because that only requires one preimage, but ''two'' preimages,
 that's impossible!"

 Also consider that, for many protocols, the plaintext of some cells to the
 exit node are potentially something guessable like `GET /
 HTTP/1.1\r\nHost: twitter.com\r\n\r\n` (ignoring TLS in that case, but you
 get the idea), and we've never really assumed there's any significant
 advantage there. Also technically, all zeroes ''is'' random, in the same
 way that [https://xkcd.com/221/ int get_random_number() { return 4; }] is
 a valid PRNG, it's just not really how any sane person would interpret the
 spec. 😉🤓

 All joking aside, there are two ways I could imagine the "I can do one
 preimage but not two" adversary could be a problem: first, if they can do
 one preimage, but it takes enough time (let's say a couple minutes for the
 case of tor's circuits) that they couldn't reasonably do two (and assuming
 they don't have resources to parallelise). This adversary doesn't make
 sense to me, because if unbeknownst to the entire world they can do one
 preimage, I don't see how they're going to have trouble explaining to
 their boss why they need a second set of the same hardware. The second
 issue would be a if a client somehow created a circuit which was entirely
 padding, that is "find a preimage for all zeroes" which, if you know the
 number of payload bytes sent/received would be trivial and isn't even
 preimage or cryptographic attack at all: simply hash the same number of
 zeroes. This, I'd argue is not an issue because you can't have a circuit
 with all zeroes (that would mean that all kinds of stuff in the handshake
 would need to be all zeroes, like keys and fingerprints and such). Also
 what is an adversary going to do with a circuit made entirely of padding
 for which they've forged a MAC for, if everything in the payload is
 ignored? "Oh no! I made you ignore some unauthenticated stuff!"

 I think I've convinced myself this is not a security issue.

 Probably we should do a torspec fix that says something like "SHOULD be
 chosen randomly, but MAY be all zeroes, and MUST be ignored"?

 For the patch, it probably doesn

[tor-bugs] #22988 [Internal Services/Service - trac]: Make all trac child tickets have the same headers and inherit fields

[Tor Bug Tracker & Wiki]

#22988: Make all trac child tickets have the same headers and inherit fields
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi,

 Can you make the table headers for every parent ticket type:
 "type, status, owner, summary"

 And can you make the child Inherited fields for every parent ticket type:
 "cc, version, keywords, component, milestone"

 When I try to do this on:

 https://trac.torproject.org/projects/tor/admin/childticketsplugin/types

 I get the error:

 "Warning: Error writing to trac.ini, make sure it is writable by the web
 server. Your changes have not been saved."

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

Re: [tor-bugs] #22987 [Core Tor/Tor]: TAP Hybrid Encryption case 1 is used when the payload is equal to the maximum length

[Tor Bug Tracker & Wiki]

#22987: TAP Hybrid Encryption case 1 is used when the payload is equal to the
maximum length
--+
 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:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => 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

[tor-bugs] #22987 [Core Tor/Tor]: TAP Hybrid Encryption case 1 is used when the payload is equal to the maximum length

[Tor Bug Tracker & Wiki]

#22987: TAP Hybrid Encryption case 1 is used when the payload is equal to the
maximum length
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:  #18856
   Points:|   Reviewer:
  Sponsor:|
--+
 The spec says:
 {{{
 -  1. If M is less than PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with
 PK.
 +  1. If M is less than or equal to PK_ENC_LEN-PK_PAD_LEN, pad and
 encrypt M with PK.
 }}}
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n117

 (We'll need to fix the line wrapping here as well.)

 But the code does:
 {{{
   if (!force && fromlen+overhead <= pkeylen) {
 }}}
 https://gitweb.torproject.org/tor.git/tree/src/common/crypto.c#n1262

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

Re: [tor-bugs] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-usability, tbb-security-slider  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)


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

Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis review-group-21 |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by isis):

 Note that the squashed branches are now `bug22636_0.2.4_squashed`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug22636_0.2.4_squashed
 here] and `bug22636_0.3.1_squashed`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug22636_0.3.1_squashed
 here]. CI for [https://travis-ci.org/isislovecruft/tor/builds/254627602
 each] [https://travis-ci.org/isislovecruft/tor/builds/254627297 one] pass
 (because the 0.3.1 branch is now based on a version of `maint-0.3.1` that
 includes the patch for #22830).

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

Re: [tor-bugs] #21569 [Applications/Tor Browser]: Investigate and neuter fingerprinting potential of Permissions API

[Tor Bug Tracker & Wiki]

#21569: Investigate and neuter fingerprinting potential of Permissions API
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R, tbb-linkability |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705R =>
 ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705R, tbb-linkability


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

Re: [tor-bugs] #22986 [- Select a component]: update Alison's GPG key in db.torproject.org

[Tor Bug Tracker & Wiki]

#22986: update Alison's GPG key in db.torproject.org
--+
 Reporter:  alison|  Owner:  alison
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by alison):

 figuring out how to make a pgp-signed message display properly with wiki
 formatting!

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

Re: [tor-bugs] #22986 [- Select a component]: update Alison's GPG key in db.torproject.org

[Tor Bug Tracker & Wiki]

#22986: update Alison's GPG key in db.torproject.org
--+
 Reporter:  alison|  Owner:  alison
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by alison):

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


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

Re: [tor-bugs] #22986 [- Select a component]: update Alison's GPG key in db.torproject.org

[Tor Bug Tracker & Wiki]

#22986: update Alison's GPG key in db.torproject.org
--+--
 Reporter:  alison|  Owner:  alison
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by alison):

 * owner:   => alison
 * status:  new => assigned


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

[tor-bugs] #22986 [- Select a component]: update Alison's GPG key in db.torproject.org

[Tor Bug Tracker & Wiki]

#22986: update Alison's GPG key in db.torproject.org
--+-
 Reporter:  alison|  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 See comment one.

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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #21888 | Points:  0.1
 Reviewer:  asn|Sponsor:  SponsorR-must
---+---
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 From IRC: `<+asn> LGTM`

 Actually, the fixup commit has been removed. Final branches:

 Spec: `ticket22979_01`
 Code: `ticket22979_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] #22985 [Applications/Tor Browser]: Can we simplify and clarify click-to-play of audio/video?

[Tor Bug Tracker & Wiki]

#22985: Can we simplify and clarify click-to-play of audio/video?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security, ux- |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by arthuredelstein:

Old description:

> Right now click-to-play of videos is quite cumbersome and has poor
> usability. For example on youtube, this is what I observe on Medium
> Security.
>
> * On first page load, no video or audio is visible -- the video box is
> gray. A "musical notes" icon appears in the middle of the video box, and
> an "orbiting dots" indicator seems to indicate some problem loading.
> After a few seconds the video box goes black and it says "an error
> occured." Then after another few seconds the "musical notes" icon
> reappears.
>
> * If I click on the "musical notes" icon, then a confirmation box
> appears, that says "Temporarily allow ... [URLs and codec gibberish]". If
> I click OK, then the whole page reloads. Again I get a gray video box
> with orbiting dots. This time there is a film canister icon in the middle
> of the dots.
>
> * If I click on the film canister it says, "Temporarily allow [URL and
> more codec gibberish]". again I click OK, the page reloads and the video
> finally plays.
>
> So here, click-to-play required two clicks and two reloads (plus
> confirmation clicks). Ideally it should require only one reload. The
> option to click to play the video should be much more clear (it should
> probably have the text "Click to Play"). If there is a confirmation
> prompt, then it should clearly explain to that video/audio is about to be
> loaded, and what the security concerns are.

New description:

 Right now click-to-play of videos is quite cumbersome and has poor
 usability. For example on youtube, this is what I observe on Medium
 Security.

 * On first page load, no video or audio is visible -- the video box is
 gray. A "musical notes" icon appears in the middle of the video box, and
 an "orbiting dots" indicator seems to indicate some problem loading. After
 a few seconds the video box goes black and it says "an error occured."
 Then after another few seconds the "musical notes" icon reappears.

 * If I click on the "musical notes" icon, then a confirmation box appears,
 that says "Temporarily allow ... [URLs and codec gibberish]". If I click
 OK, then the whole page reloads. Again I get a gray video box with
 orbiting dots. This time there is a film canister icon in the middle of
 the dots.

 * If I click on the film canister it says, "Temporarily allow [URL and
 more codec gibberish]". again I click OK, the page reloads and the video
 finally plays.

 So here, click-to-play required two clicks and two reloads (plus
 confirmation clicks). Ideally it should require only one reload. The
 option to click to play the video should be much more clear (it should
 probably have the text "Click to Play"). The click-to-play button
 shouldn't disappear when the youtube page tries to re-load the video. If a
 confirmation prompt is to be shown, then it should clearly explain to the
 user that video/audio is about to be loaded, and what the security
 concerns are.

--

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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #21888 | Points:  0.1
 Reviewer:  asn|Sponsor:  SponsorR-must
---+---

Comment (by dgoulet):

 Replying to [comment:6 asn]:
 > Replying to [comment:5 dgoulet]:
 > > Branch: `ticket22979_032_01`
 > >
 > > It's not that big so let me know if an Oniongit would be needed.
 >
 > LGTM, but two quick questions:
 >
 > a) I assume that `ip->onion_key` will be initialized by the service code
 that is not yet included in the branch. So it's OK that it's not really
 filled with anything on the service-side, right?

 Yes exactly. This is really just the "descriptor subsystem" support for
 decoding and encoding.

 > b) Do we really want to `goto err` if we don't recognize the key type
 when decoding descriptor? Doesn't that influence our forward-compatibility
 that the key type field was supposed to be helping?

 Hmmm yes I think you are right. Then we have the same issue with `enc-
 key`... :S

 Basically, if we don't have "ntor" following it, we should just ignore it
 and move on. See fixup commit `76533e10a`.

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

Re: [tor-bugs] #22981 [Applications/Tor Browser]: Don't block audio/video on https sites under Medium Security

[Tor Bug Tracker & Wiki]

#22981: Don't block audio/video on https sites under Medium Security
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  ux-team|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:1 gk]:
 > Replying to [ticket:22981 arthuredelstein]:

 > I think before seriously thinking about not blocking audio/video anymore
 for HTTPS pages we should investigate how complex the click-to-play thing
 is and whether we could simplify it to a point where that alone would be a
 sufficient usability improvement.

 I agree that would be a good idea and would at least partially address the
 underlying problem. I opened #22985 to investigate this issue.

 My hope, though, is to make Medium Security more attractive so that more
 users will use it and have better protection. Because I think the threat
 both from JS and video/audio is much, much higher on non-https sites than
 on https sites, it seems appropriate to consider treating those two
 categories of sites differently at Medium Security (or possibly even Low
 Security!).

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

Re: [tor-bugs] #22985 [Applications/Tor Browser]: Can we simplify and clarify click-to-play of audio/video?

[Tor Bug Tracker & Wiki]

#22985: Can we simplify and clarify click-to-play of audio/video?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security, ux- |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-usability, tbb-security => tbb-usability, tbb-security,
 ux-team


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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #21888 | Points:  0.1
 Reviewer:  asn|Sponsor:  SponsorR-must
---+---

Comment (by asn):

 Replying to [comment:5 dgoulet]:
 > Branch: `ticket22979_032_01`
 >
 > It's not that big so let me know if an Oniongit would be needed.

 LGTM, but two quick questions:

 a) I assume that `ip->onion_key` will be initialized by the service code
 that is not yet included in the branch. So it's OK that it's not really
 filled with anything on the service-side, right?

 b) Do we really want to `goto err` if we don't recognize the key type when
 decoding descriptor? Doesn't that influence our forward-compatibility that
 the key type field was supposed to be helping?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22985 [Applications/Tor Browser]: Can we simplify and clarify click-to-play of audio/video?

[Tor Bug Tracker & Wiki]

#22985: Can we simplify and clarify click-to-play of audio/video?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-usability, tbb-
 Severity:  Normal   |  security
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Right now click-to-play of videos is quite cumbersome and has poor
 usability. For example on youtube, this is what I observe on Medium
 Security.

 * On first page load, no video or audio is visible -- the video box is
 gray. A "musical notes" icon appears in the middle of the video box, and
 an "orbiting dots" indicator seems to indicate some problem loading. After
 a few seconds the video box goes black and it says "an error occured."
 Then after another few seconds the "musical notes" icon reappears.

 * If I click on the "musical notes" icon, then a confirmation box appears,
 that says "Temporarily allow ... [URLs and codec gibberish]". If I click
 OK, then the whole page reloads. Again I get a gray video box with
 orbiting dots. This time there is a film canister icon in the middle of
 the dots.

 * If I click on the film canister it says, "Temporarily allow [URL and
 more codec gibberish]". again I click OK, the page reloads and the video
 finally plays.

 So here, click-to-play required two clicks and two reloads (plus
 confirmation clicks). Ideally it should require only one reload. The
 option to click to play the video should be much more clear (it should
 probably have the text "Click to Play"). If there is a confirmation
 prompt, then it should clearly explain to that video/audio is about to be
 loaded, and what the security concerns are.

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

Re: [tor-bugs] #22967 [Applications/Tor Browser Sandbox]: Kill "Tor Browser Crash Dumps" with fire once implemented.

[Tor Bug Tracker & Wiki]

#22967: Kill "Tor Browser Crash Dumps" with fire once implemented.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  sandbox-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=b94ed0aa5d3c37edd4ad777c85c7fe686d061679

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

Re: [tor-bugs] #20792 [Applications/Tor Browser Sandbox]: Add more options for changing the install process behavior

[Tor Bug Tracker & Wiki]

#20792: Add more options for changing the install process behavior
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 I closed #20792 as a duplicate.

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

Re: [tor-bugs] #22262 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox should offer the possibility to download the Tor Browser from mirrors

[Tor Bug Tracker & Wiki]

#22262: Tor Browser Sandbox should offer the possibility to download the Tor
Browser from mirrors
--+---
 Reporter:  blockflare|  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #20792| Points:
 Reviewer:|Sponsor:
--+---
Changes (by yawning):

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


Comment:

 Dup of #20792.

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

Re: [tor-bugs] #22984 [Applications/Tor Browser Sandbox]: Enable network.IDN_show_punycode by default in the sandboxed browser.

[Tor Bug Tracker & Wiki]

#22984: Enable network.IDN_show_punycode by default in the sandboxed browser.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=c8a86652fcaa2bb5d3d0550b99e078844fbf26fe

 Implemented as a `defaultPref()` unlike most of the other overrides, so if
 users want to revert to previous behavior, it's possible.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22984 [Applications/Tor Browser Sandbox]: Enable network.IDN_show_punycode by default in the sandboxed browser.

[Tor Bug Tracker & Wiki]

#22984: Enable network.IDN_show_punycode by default in the sandboxed browser.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Tor Browser ticket: #21961

 Deviating from Mozilla and the Tor Browser developers and doing the safer
 thing at the expense of UI/UX seems prudent to me.

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

Re: [tor-bugs] #22925 [Applications/Tor Browser Sandbox]: Make the extension whitelist public key cryptography based.

[Tor Bug Tracker & Wiki]

#22925: Make the extension whitelist public key cryptography based.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 #22974 is the bug for "sign NoScript with different signing keys".

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

Re: [tor-bugs] #22925 [Applications/Tor Browser Sandbox]: Make the extension whitelist public key cryptography based.

[Tor Bug Tracker & Wiki]

#22925: Make the extension whitelist public key cryptography based.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 This *might* be vaguely ok if it used hardened SHA1.  In that case,
 there's a PKCS7 library at https://github.com/fullsailor/pkcs7 that
 purports to support what is required.

 But this ultimately depends on NoScript, torbutton and torlauncher being
 signed with non-Mozilla keys.

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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Replying to [comment:1 dgoulet]:
 > Do we really have a way to remove a syscall from the sandbox filters at
 runtime?

 That would be trivial to add because the bpf is runtime generated with
 libseccomp.

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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  usability, ux-team, TorBrowserTeam201707,  |
  GeorgKoppen201707  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Replying to [comment:43 cypherpunks]:
 > The secure padlock only means that the stuff in transit is secure, it
 has absolutely no relevance to whether we're talking to Satan or RiseUp.
 EV certs are what one should look at if they want to make sure they're
 talking to the right organization.

 As a happy coincidence, the only CA signed certs for `.onion` domains are
 EV certs.

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

Re: [tor-bugs] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 The question about a new Descriptor type in metrics-lib was moved to its
 own ticket #22983.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The webstats-log-files are the only files available on CollecTor (in
 future) that are not yet covered by metrics-lib.

 Should there be a 'LogDescriptor' interface and implementation in metrics-
 lib? Are there any reasons why not?

 The name `LogDescriptor` is just a working name; better naming suggestions
 welcome.
 The interface should extend `Descriptor` and have additional methods for
 retrieving the measuring host and the served host, a method for retrieving
 the date of the log.
 What else?

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

Re: [tor-bugs] #22981 [Applications/Tor Browser]: Don't block audio/video on https sites under Medium Security

[Tor Bug Tracker & Wiki]

#22981: Don't block audio/video on https sites under Medium Security
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  ux-team|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [ticket:22981 arthuredelstein]:
 > Right now "Medium Security" on the security slider blocks all audio and
 video using NoScript. But JavaScript is allowed for https sites. I would
 suggest also unblocking video and audio for https sites but keeping them
 blocked for http sites. This would increase usability for sites such as
 YouTube.

 While it would increase usability for websites I am not sold we should do
 that yet. The analogy to our treatment of JavaScript is an interesting one
 but we should not forget that we allow only non-JITed JavaScript on HTTPS
 pages. The reason for not allowing JIT at all (i.e. irrespective of the
 transport) is the high amount of vulnerabilities in this part of the code.
 Exactly the same reason is behind blocking audio/video by default. But
 audio/video is more important than JIT, right (although not allowing the
 latter breaks sites as well!)? True. That's the reason behind making it
 easy to allow playing videos if wanted.

 I think before seriously thinking about not blocking audio/video anymore
 for HTTPS pages we should investigate how complex the click-to-play thing
 is and whether we could simplify it to a point where that alone would be a
 sufficient usability improvement.

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

Re: [tor-bugs] #22972 [Core Tor/Tor]: tor expert bundle only read the first letter from config

[Tor Bug Tracker & Wiki]

#22972: tor expert bundle only read the first letter from config
--+
 Reporter:  lanealucy |  Owner:  erinn
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by lanealucy):

 it dont work since 0.2.7.6 or earlier

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

Re: [tor-bugs] #22192 [Webpages/Website]: Update tor-mirrors.csv / mirror site

[Tor Bug Tracker & Wiki]

#22192: Update tor-mirrors.csv / mirror site
--+---
 Reporter:  Samdney   |  Owner:  Sebastian
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Samdney):

 Hi,

 did a new update of mirrors.csv.

 You can find it here now:
 https://github.com/Samdney/webwml/tree/ticket22192_updatetormirrorcsv

 Please merge it.
 You still have to run update-mirrors.pl, since this perl stuff doesn't
 like me and produced not useful results (I'm still investigating) :)

 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] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #21888 | Points:  0.1
 Reviewer:  asn|Sponsor:  SponsorR-must
---+---
Changes (by dgoulet):

 * status:  accepted => needs_review
 * reviewer:   => asn
 * points:  0.2 => 0.1


Comment:

 Branch: `ticket22979_032_01`

 It's not that big so let me know if an Oniongit would be needed.

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

[tor-bugs] #22982 [Applications/Tor Browser]: Introduce a single "adjust security" toolbar button for security slider and noscript options

[Tor Bug Tracker & Wiki]

#22982: Introduce a single "adjust security" toolbar button for security slider 
and
noscript options
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-usability, tbb-
 Severity:  Normal   |  security-slider, ux-team
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Right now, the security slider is buried under a submenu. We could promote
 it to its own toolbar buttun/popup menu, similar to how ninavizz suggested
 in #21183. And we could move needed NoScript functionality (namely
 "temporarily whitelist video/audio/scripts for this tab") from the
 NoScript dropdown to the security popup. Other dangerous NoScript
 functionality could be omitted altogether (including "Allow Scripts
 Global" and "Options".

 Finally the security slider button could have a decoration that indicates
 the current setting "H/M/L" as well as a second indicator showing whether
 we have temporarily whitelisted for this tab.

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

Re: [tor-bugs] #22831 [Applications/Tor Browser]: Merge Snowflake for mac

[Tor Bug Tracker & Wiki]

#22831: Merge Snowflake for mac
-+--
 Reporter:  dcf  |  Owner:  tbb-team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake TorBrowserTeam201707R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by boklm):

 Replying to [comment:8 dcf]:
 >
 > Yes, it is probably a copy-paste error. The `GN_ARGS` in both
 descriptors are probably not minimal. The compile–test cycles are so long
 that I would try changing more than one thing at a time.

 Ah indeed, testing small changes like this takes a lot of time with
 gitian. The new build system in `tor-browser-build.git` should make that
 kind of changes easier to test as we can rebuild only what changed.

 >
 > If you find that the line is unnecessary, please remove it.

 I did not include this line when converting those changes to `tor-browser-
 build.git`, and it seems to work fine without it.

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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  usability, ux-team, TorBrowserTeam201707,  |
  GeorgKoppen201707  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:14 yawning]:
 > As massively flawed and totally horrible as the CA system is, having a
 CA signed TLS cert serves to bind the address to an external identity.
 `.onion` address do not have this property.  What assurance is there that
 the address a user is entering their credentials to is the correct one?

 The secure padlock only means that the stuff in transit is secure, it has
 absolutely no relevance to whether we're talking to Satan or RiseUp. EV
 certs are what one should look at if they want to make sure they're
 talking to the right organization.

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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #21888 | Points:  0.2
 Reviewer: |Sponsor:  SponsorR-must
---+---
Changes (by dgoulet):

 * status:  needs_review => accepted
 * parent:  #20657 => #21888


Comment:

 Ok, time for the code to come! Considering this as a groundwork and should
 be based on git 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

[tor-bugs] #22981 [Applications/Tor Browser]: Don't block audio/video on https sites under Medium Security

[Tor Bug Tracker & Wiki]

#22981: Don't block audio/video on https sites under Medium Security
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-usability, tbb-
 Severity:  Normal   |  security-slider, ux-team
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Right now "Medium Security" on the security slider blocks all audio and
 video using NoScript. But JavaScript is allowed for https sites. I would
 suggest also unblocking video and audio for https sites but keeping them
 blocked for http sites. This would increase usability for sites such as
 YouTube.

 High Security would continue to block audio and video for both https and
 http sites.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22980 [Applications/Tor Browser]: Indicate Security Slider Level applies globally

[Tor Bug Tracker & Wiki]

#22980: Indicate Security Slider Level applies globally
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-usability, tbb-
 Severity:  Normal   |  security-slider, ux-team
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When a user adjust the security settings, it applies to all tabs
 (currently open and in the future). So we should probably add something in
 the security slider text to indicate 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] #22959 [Applications/Tor Browser]: Merge Snowflake for mac, in rbm tor-browser

[Tor Bug Tracker & Wiki]

#22959: Merge Snowflake for mac, in rbm tor-browser
-+
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201707, snowflake  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by boklm):

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


Comment:

 This is done with commits de79b7e079b44d9b50504413027b632f28fed255,
 9b59107420ab527696b08ac89d787abd2c67d985,
 551dd7a7b870177c5f6d391e73017f9dca5163b9 and
 1d38fb57874499b487e2ac26fa86b4a8bf427a8e.

 I have built mac bundles twice (cleaning clang, go, go-webrtc, webrtc and
 snowflake between the builds) to check that it results in identical
 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] #22827 [Core Tor/Tor]: Formalise CollecTor spec for sanitised bridge descriptors and put in torspec

[Tor Bug Tracker & Wiki]

#22827: Formalise CollecTor spec for sanitised bridge descriptors and put in
torspec
-+-
 Reporter:  isis |  Owner:  karsten
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-docs, tor-bridges  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 Yes, there is some risk of specification sickness :-)

 I added my comments as `cref` elements, which should make easy to spot
 them. I tried to change all references to dir-spec into "Tor directory
 protocol, version 3", removed very few typos, and replaced tabs by spaces.

 The attached xml can be processed into html using xslt; this makes things
 a little prettier and is more adjustable than 'pure' rfc.  The xml almost
 the same, but 'pure' rtf refused to insert the comments into the text and
 didn't allow `eref` tags inside a comment.
 The tools for xslt processing are listed in a comment.  But, no need to
 fiddle with that immediately as I also attached the generated html.

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

Re: [tor-bugs] #22895 [Core Tor/Tor]: Unused variables in donna's SSE2 header

[Tor Bug Tracker & Wiki]

#22895: Unused variables in donna's SSE2 header
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  027-backport, 028-backport,  |  Actual Points:
  029-backport, 030-backport, 031-backport,  |
  compile, warning, 32bit, ed25519, review-  |
  group-21   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #22972 [Core Tor/Tor]: tor expert bundle only read the first letter from config

[Tor Bug Tracker & Wiki]

#22972: tor expert bundle only read the first letter from config
--+
 Reporter:  lanealucy |  Owner:  erinn
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by lanealucy):

 * status:  needs_information => new


Comment:

 CMD:
 C:\Users\Administrator.LL-DC02>"C:\Users\Administrator.LL-
 DC02\Documents\visual
 studio 2013\Projects\Lissy Cruuv\unbreakable non-server
 comunication\bin\Debug\t
 or\tor.exe"  -f "c:\users\administrator.ll-dc02\documents\visual studio
 2013\Pro
 jects\Lissy Cruuv\unbreakable non-server
 comunication\bin\Debug\tor\data\torrc"

 rorrc:
 SOCKSPort 1234

 http://prntscr.com/fxojd4

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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 We could allow a transition in one direction (allow->disallow) but not the
 other.

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

Re: [tor-bugs] #22735 [Core Tor/Tor]: prop224: HS desc overlap period func uses absolute times instead of slots

[Tor Bug Tracker & Wiki]

#22735: prop224: HS desc overlap period func uses absolute times instead of 
slots
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-hs spec-conformance  |  Actual Points:
Parent ID:  #20657   | Points:  1
 Reviewer:  dgoulet  |Sponsor:  SponsorR-
 |  can
-+-

Comment (by dgoulet):

 Scratch the above, once the branch is fixed, I'll merge it in #20657.

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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:2 dawuud]:
 > No that is really not the intent of the ticket at all; in Subgraph OS
 tor is running outside the sandbox. This ticket/feature specified is not
 concerned with syscall filtering but merely "telling tor to not ever exec
 via a config option".

 Ah! So a torrc option that would be "do not exec never ever" so if any
 option that does that is enabled through control port, it's denied I
 guess.

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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dawuud):

 No that is really not the intent of the ticket at all; the Subgraph OS
 sandbox doesn't run tor in the sandbox.

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

Re: [tor-bugs] #22884 [Applications/Tor Browser]: about:tor page is not showing up in non-e10s mode after fix for #18913 landed

[Tor Bug Tracker & Wiki]

#22884: about:tor page is not showing up in non-e10s mode after fix for #18913
landed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201707R, tbb-  |  Actual Points:
  torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Merged to `master` with commit
 355f03e18d7de4b9ca67d9e88ac6abce4c68d96b.

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

Re: [tor-bugs] #22884 [Applications/Tor Browser]: about:tor page is not showing up in non-e10s mode after fix for #18913 landed

[Tor Bug Tracker & Wiki]

#22884: about:tor page is not showing up in non-e10s mode after fix for #18913
landed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201707R, tbb-  |  Actual Points:
  torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  TorBrowserTeam201707, tbb-torbutton => TorBrowserTeam201707R,
 tbb-torbutton
 * status:  assigned => needs_review


Comment:

 Replying to [comment:4 gk]:
 > I am a bit reluctant doing so. It makes me a bit nervous to say
 "whatever about: page gets registered/used allow it". Even if it is a bit
 annoying I'd like to move forward on a case-by-case basis.

 That's fine; I just thought I would ask. Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-browser-
 bundle.git/commit/?h=bug22884-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] #22735 [Core Tor/Tor]: prop224: HS desc overlap period func uses absolute times instead of slots

[Tor Bug Tracker & Wiki]

#22735: prop224: HS desc overlap period func uses absolute times instead of 
slots
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-hs spec-conformance  |  Actual Points:
Parent ID:  #20657   | Points:  1
 Reviewer:  dgoulet  |Sponsor:  SponsorR-
 |  can
-+-
Changes (by dgoulet):

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


Comment:

 Review done in oniongit.

 I think we could wait until #20657 is merged then rebase it on master and
 submit it for upstream? I fear adding 6 more commits on top of #20657
 could just make its merge longer?

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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #20657 | Points:  0.2
 Reviewer: |Sponsor:  SponsorR-must
---+---

Comment (by asn):

 Replying to [comment:2 dgoulet]:
 > Spec: `ticket22979_01`

 LGTM.

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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #20657 | Points:  0.2
 Reviewer: |Sponsor:  SponsorR-must
---+---
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Spec: `ticket22979_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] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  reopened => needs_information


Comment:

 Replying to [comment:3 arlolra]:
 > Tor Messenger is reverting this patch (#3875) in
 https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=cd2bb57632ac4278da6d70fe3339bb64b38d29eb since it
 seems to be breaking STARTTLS in XMPP.

 arlolra: Did you see any crashes with that patch or how did it break
 STARTTLS? I actually wonder whether the patch is the culprit for crashes
 like #22330 and #22977...

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

Re: [tor-bugs] #22810 [Core Tor/Tor]: prop224: Make the client/service extend properly to the IP/RP

[Tor Bug Tracker & Wiki]

#22810: prop224: Make the client/service extend properly to the IP/RP
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_revision
 Priority:  Very High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by asn):

 * keywords:  tor-hs, prop224, review-group-21 => tor-hs, prop224
 * status:  needs_review => needs_revision


Comment:

 Removing this from `review-group-21` for now, since there are more
 important prop224 branches to review and we don't want to waste precious
 review points.
 Let's handle this ticket after the core prop224 has been 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] #22977 [Applications/Tor Browser]: TorBrowser 7.0.2 crash on Mac OS X 10.12.6

[Tor Bug Tracker & Wiki]

#22977: TorBrowser 7.0.2 crash on Mac OS X 10.12.6
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Looks at least related to #22330.

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

Re: [tor-bugs] #22977 [Applications/Tor Browser]: TorBrowser 7.0.2 crash on Mac OS X 10.12.6

[Tor Bug Tracker & Wiki]

#22977: TorBrowser 7.0.2 crash on Mac OS X 10.12.6
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  Low => High
 * keywords:  crash => tbb-crash
 * severity:  Normal => Major


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

Re: [tor-bugs] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, prop224, tor-spec  |  Actual Points:
Parent ID:  #20657 | Points:  0.2
 Reviewer: |Sponsor:  SponsorR-must
---+---
Changes (by dgoulet):

 * status:  new => accepted
 * parent:   => #20657


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22979 [Core Tor/Tor]: prop224: Add an introduction point onion key in the descriptor

[Tor Bug Tracker & Wiki]

#22979: prop224: Add an introduction point onion key in the descriptor
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-hs, prop224, tor-spec
Actual Points: |  Parent ID:
   Points:  0.2|   Reviewer:
  Sponsor:  SponsorR-must  |
---+---
 So it turns out that this menagerie of keys in prop224 was missing yet one
 more key in it :D.

 To extend to an introduction point, we need its onion key meaning we have
 to add it to the descriptor. Keep in mind that the client does NOT lookup
 the node in its consensus in order not to reveal which consensus it's
 using and avoid reachability issues with different consensus between
 service and client.

 This goes in two fold. First add an onion key field in the spec and then
 implement it in an extra commit in #20657 code (which is being reviewed).
 I would like us to avoid making a branch depending on 8k lines of code
 from another unmerged ticket.

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

Re: [tor-bugs] #22977 [Applications/Tor Browser]: TorBrowser 7.0.2 crash on Mac OS X 10.12.6

[Tor Bug Tracker & Wiki]

#22977: TorBrowser 7.0.2 crash on Mac OS X 10.12.6
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:   => crash
 * owner:   => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Do we really have a way to remove a syscall from the sandbox filters at
 runtime?

 That is, tor realizes at runtime that `ClientTransportPlugin` is in used
 for instance so we would need a way to tell the sandbox "Oh, this is set,
 ok don't filter execv()".

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

Re: [tor-bugs] #22972 [Core Tor/Tor]: tor expert bundle only read the first letter from config

[Tor Bug Tracker & Wiki]

#22972: tor expert bundle only read the first letter from config
--+
 Reporter:  lanealucy |  Owner:  erinn
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * priority:  High => Medium
 * keywords:   => tor-client
 * status:  new => needs_information
 * severity:  Blocker => Normal
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 "if i set a config file with command line argument," ... what do you mean
 by that exactly? You can pass options on the command like such:

 `tor SocksPort 1234` and I confirm it works for tor 0.3.0.9.

 Can you maybe give us the full torrc and/or command line you are using?
 And I see it's on Windows. 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] #22952 [Applications/Tor Browser]: Tor Browser Arabic Fonts Issue !

[Tor Bug Tracker & Wiki]

#22952: Tor Browser Arabic Fonts Issue !
--+---
 Reporter:  sigma4111 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-fonts  |  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sigma4111):

 Replying to [comment:9 dcf]:
 > Replying to [comment:8 sigma4111]:
 > Do you have access to a Linux computer where the fonts look good? If so,
 what fonts are they? Those are more likely to be fonts that we can use.
 >
 > Arial, Georgia, and Times New Roman are Microsoft fonts that we wouldn't
 be able to include.

 You mean that you cann not add default fonts of this site to Tor for being
 unlicened, & you can only allow fonts installed by default on Linux ? If
 yes, this is bad news, because I tried Linux Arabic fonts on various
 distros. (Debian, CentOS, Linux Mint, openSUSE) & they are not good !

 In this case, it would be better if you give me a website offering free
 Arabic fonts that their licences allow you to include them in Tor. I will
 examine them on LibreOffice to see which of them nearest to "Arial" &
 "Time new romman" then will inform you ... Currently you supplied me in
 your 1st replay by link I got from it only 3 Arabic fonts, & best one was
 "Noto Naskh Arabic" ! Do you have other sites ?

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

Re: [tor-bugs] #22972 [Core Tor/Tor]: tor expert bundle only read the first letter from config

[Tor Bug Tracker & Wiki]

#22972: tor expert bundle only read the first letter from config
--+--
 Reporter:  lanealucy |  Owner:  erinn
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * component:  Applications/Tor bundles/installation => Core Tor/Tor


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

Re: [tor-bugs] #22978 [Applications/Tor Browser]: BUG "Could not connect to control port" + Temporary solution

[Tor Bug Tracker & Wiki]

#22978: BUG "Could not connect to control port" + Temporary solution
--+---
 Reporter:  wunderbar |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * version:  Tor: 0.3.0.9 =>
 * milestone:  Tor: unspecified =>


Comment:

 Thanks for this report. I tried to reproduce your problem but to no avail.
 Could you do the following to help tracking this down?

 1) Test whether that happens with a clean, new Tor Browser as well
 (downloaded from our website)
 2) Could you follow the steps in comment:3:ticket:20890 (the place for the
 latest expert bundle is https://dist.torproject.org/torbrowser/7.0.2/tor-
 win32-0.3.0.9.zip with https://dist.torproject.org/torbrowser/7.0.2/tor-
 win32-0.3.0.9.zip.asc) and give us the debug log you get when starting Tor
 Browser with the expert bundle `tor.exe`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22978 [Applications/Tor Browser]: BUG "Could not connect to control port" + Temporary solution

[Tor Bug Tracker & Wiki]

#22978: BUG "Could not connect to control port" + Temporary solution
--+--
 Reporter:  wunderbar |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.0.9
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor browser bundle, currently the latest one available from autoupdates
 for windows. Gives error "Could not connect to control port", this happens
 if You edit torrc file at least once, doesn't matter what I change in
 there, it still gives this error after modifying it. For example I added
 "ExitNodes $MyExitNodesFingeprintHere" and it triggered this error after
 trying to launch the tor browser, also trying changing torrc file back to
 how it was doesn't help, I am not sure why this happens, but the solution
 is to go to "\Tor Browser\Browser\TorBrowser\Data\Tor" and deleting all
 the "cached-*" files. And I have to delete them before every launch. I
 know other people who have experienced this same issue, so this is not
 unique to me. Windows10 home 64bit. If You need any additional info please
 let me know, I might have chosen something wrong, for example milestone in
 this bug report, I am just not familiar with this. I think You will be
 able to figure it out. Thank You.

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

Re: [tor-bugs] #22973 [Applications/Tor Browser]: Storage API allows fingerprinting

[Tor Bug Tracker & Wiki]

#22973: Storage API allows fingerprinting
--+---
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #21785.

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

Re: [tor-bugs] #21785 [Applications/Tor Browser]: Keep an eye on the Storage API

[Tor Bug Tracker & Wiki]

#21785: Keep an eye on the Storage API
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: tom (added)


Comment:

 See: https://blog.nightly.mozilla.org/2017/07/17/preview-storage-api-in-
 firefox-nightly/. #22973 is a duplicate.

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

Re: [tor-bugs] #22974 [Applications/Tor Browser]: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

[Tor Bug Tracker & Wiki]

#22974: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [ticket:22974 tom]:
 > 3) In 59, when Web Extensions are around this won't be as big of a
 concern. Mozilla can't get code execution but could neuter the effect of
 an add-on or turn it into spyware (assuming we keep extension updating in
 place). Whether web extensions will support an updateKey mechanism is an
 open question (they don't now, EFF wants it. Tor might wish to lend
 support to the argument. If Tor could get another partner repack to join
 in that would help even more I bet.)

 To be honest I am not sure whether we as Tor should push for that. On one
 hand that allows to add an extra layer of security which is a good thing
 for all Firefox users but on the other hand do we want to get rid of
 extension update pinging and extension updating via AMO in our default Tor
 Browser configuration as a result of the HPKP fiasco (see #20146).

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

Re: [tor-bugs] #22974 [Applications/Tor Browser]: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

[Tor Bug Tracker & Wiki]

#22974: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [ticket:22974 tom]:
 > Per #22966 it sounds like NoScript is not signed with a developer key
 (the 'updateKey' feature described here: https://developer.mozilla.org/en-
 US/Add-ons/Install_Manifests#updateKey )
 >
 > updateKey allows the extension developer to require updates be signed
 with a key only they control. Without it, Mozilla can rewrite extensions
 and effectively get arbitrary code execution via an add-on.
 >
 > There's a few things at play here.
 >
 > 1) We could disable add-on updating all together to mitigate this in 52.

 That's the plan. We'll start with HTTPS-Everywhere (hopefully soon, #10394
 is the ticket for that) and do the same with NoScript afterwards.

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

Re: [tor-bugs] #22971 [Applications/Tor Browser]: The XPI signing mechanism needs to use different hash functions.

[Tor Bug Tracker & Wiki]

#22971: The XPI signing mechanism needs to use different hash functions.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:5 yawning]:
 > If I were to try to mitigate this without breaking things for lots of
 users, I would replace the SHA1 implementation used for XPI verification
 with the hardened variant that came out of the shattered.io research.
 >
 > https://github.com/cr-marcstevens/sha1collisiondetection

 Sounds like a useful thing to look at, 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] #22971 [Applications/Tor Browser]: The XPI signing mechanism needs to use different hash functions.

[Tor Bug Tracker & Wiki]

#22971: The XPI signing mechanism needs to use different hash functions.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 If I were to try to mitigate this without breaking things for lots of
 users, I would replace the SHA1 implementation used for XPI verification
 with the hardened variant that came out of the shattered.io research.

 https://github.com/cr-marcstevens/sha1collisiondetection

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

Re: [tor-bugs] #16931 [Applications/Tor Browser]: Sanitize the add-on blocklist update URL

[Tor Bug Tracker & Wiki]

#16931: Sanitize the add-on blocklist update URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 We could think about disabling that feature. One thing that makes me a bit
 reluctant to choose that path over the sanitizing approach is that we
 allow extensions to be installed in Tor Browser. Thus, users having custom
 extensions installed would benefit from a fast way to get those blocked in
 case Mozilla detects critical issues with them.

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

Re: [tor-bugs] #22966 [Applications/Tor Browser]: Nasty MitM possibility with the Firefox blocklist service

[Tor Bug Tracker & Wiki]

#22966: Nasty MitM possibility with the Firefox blocklist service
--+---
 Reporter:  basvd |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 So, reading through all the comments it seems 2) is the remaining issue in
 this bug? If so, then we have #16931 for this problem. Marking this as a
 duplicate.

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

Re: [tor-bugs] #16931 [Applications/Tor Browser]: Sanitize the add-on blocklist update URL

[Tor Bug Tracker & Wiki]

#16931: Sanitize the add-on blocklist update URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: basvd, yawning (added)


Comment:

 #22966 is a duplicate.

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

Re: [tor-bugs] #22971 [Applications/Tor Browser]: The XPI signing mechanism needs to use different hash functions.

[Tor Bug Tracker & Wiki]

#22971: The XPI signing mechanism needs to use different hash functions.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Upstream bug has been around for years apparently:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1169532

 Fun facts:

  * The MD5 digest is ignored (sigh).
  * The PKCS7 RSA signature *also* uses SHA1 (I should have checked this).
  * Their plan apparently is to move to *also* include SHA256 digests and
 transition to ECDSA.

 I'm uncertain if we should treat this more severely.  I'm not exactly
 thrilled about "keeping the same old busted manifest format, adding yet
 another M-D construct hash, and doing absolutely shit fuckall to mitigate
 length extension attacks" as the upstream response.

 At a minimum, I think we can do better by patching the XPI verification
 code at least for our addons (like we do for the MAR signatures), but what
 do I know.

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

Re: [tor-bugs] #22974 [Applications/Tor Browser]: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution

[Tor Bug Tracker & Wiki]

#22974: NoScript (and Tor Browser) vulnerable to Mozilla Add-On Code Execution
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 [ticket:10498 To trust, or not to trust]

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

Re: [tor-bugs] #22966 [Applications/Tor Browser]: Nasty MitM possibility with the Firefox blocklist service

[Tor Bug Tracker & Wiki]

#22966: Nasty MitM possibility with the Firefox blocklist service
--+--
 Reporter:  basvd |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > In this way it is quite easy to setup a MitM attack and remove revoked
 certificates from the blocklist.xml

 Can you to add new IDs to blocklist.xml to disable exist extensions, this
 way to make DoS against users? Will Tor Browser obey blocklist for
 TorButton and TorLauncher case too?

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