[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:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hello from PETS2017. I recently chatted with Nick Mathewson who suggested
 that it would be very easy to patch tor such that exec'ing programs could
 optionally be disallowed. Currently there are three torrc config options
 that can cause tor to exec:

 1. PortForwardingHelper
 2. ClientTransportPlugin
 3. ServerTransportPlugin

 Of course these can be used via the control port which is precisely why it
 was important to the Subgraph OS project to have a decent Tor control port
 filter; we were mainly concerned with preventing sandbox escapes. I wrote
 Roflcoptor for this purpose:

 https://github.com/subgraph/roflcoptor

 A few other projects have also written their own Tor control port filter
 daemons. I will not list them here. Even with this feature addition to
 tor, these Tor control port filter daemons will still be useful for
 limiting the authority delegated by access to the tor control port.

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

Re: [tor-bugs] #22950 [Applications/Tor Browser Sandbox]: Filter out X11 root window property queries.

[Tor Bug Tracker & Wiki]

#22950: Filter out X11 root window property queries.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 The problem with Xephyr is that you need to also use a MAC or chroot to
 prevent the process from accessing the root X11 cookie, which is not as
 easy as running Xephyr. It's certainly doable, but how many people are
 going to do it?

 I think a better idea is to use `XGrabKeyboard()` in Tor Browser, which
 will prevent other applications from snooping on passwords being typed
 into the browser. See
 https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html. Many security-
 critical programs do this, like OpenSSH and GnuPG. We should think of
 doing it here, too.

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

Re: [tor-bugs] #21961 [Applications/Tor Browser]: should torbrowser enable network.IDN_show_punycode by default?

[Tor Bug Tracker & Wiki]

#21961: should torbrowser enable network.IDN_show_punycode by default?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 The fact that Chrome/Chromium has this mitigated, while Firefox has
 stubbornly refused to change their behavior, calling it someone else's
 problem, is one of the many reasons that people (rightfully) criticize
 Firefox and its devs for having poor security. Imagine how easy it would
 be for an administrator of a dissident website, or the code repository
 website for a critical or popular program (such as Tor?) to be
 compromised.

 Perhaps only enable the punycode feature when not on the lowest security
 level? The description in the browser security slider could say "Domains
 with unicode may not display properly", with the mouseover text saying
 "Characters that can be used to create a domain that looks identical to an
 existing domain will be displayed differently".

 I'm going to have to require all the important members of a website I own
 to log in exclusively using client certificates, since they will only work
 on the correct domain. I would much rather if I did not have to do
 something which has an impact on my users just because poorly-secured
 browsers insist on this being someone else's problem.

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

Re: [tor-bugs] #10394 [Applications/Tor Browser]: Torbrowser's updater updates HTTPS-everywhere

[Tor Bug Tracker & Wiki]

#10394: Torbrowser's updater updates HTTPS-everywhere
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * cc: tom (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] #22975 [Applications/TorBirdy]: Make it harder for users to open links

[Tor Bug Tracker & Wiki]

#22975: Make it harder for users to open links
---+-
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 Replying to [ticket:22975 cypherpunks]:
 > `network.protocol-handler.external-default` [1], it not just prevents
 users to open a link by accident but also minimizes the risk of phishing
 (hopefully most Thunderbird users don't just copy paste them, for people
 who insists on opening links, there's still a way left by right-clicking
 on the link and to just use the context menu).

 My mistake, `Search for` and `Open Link in Brwoser` from the context menu
 is also disabled.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22975 [Applications/TorBirdy]: Make it harder for users to open links

[Tor Bug Tracker & Wiki]

#22975: Make it harder for users to open links
---+-
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Minor  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Maybe it's a good idea to disable clickable links by setting
 `network.protocol-handler.external-default` [1], it not just prevents
 users to open a link by accident but also minimizes the risk of phishing
 (hopefully most Thunderbird users don't just copy paste them, for people
 who insists on opening links, there's still a way left by right-clicking
 on the link and to just use the context menu). Additionally, it might be
 useful to disable punycode (`network.IDN_show_punycode` [2]), if disabled
 the ascii link is visible in the status bar (probably most users type the
 url or copy/paste it by using their password manager, but seeing something
 like https://www.xn--80ak6aa92e.com/ instead of https://www.аррӏе.com/ (in
 the status bar, what's hardly notable) doesn't harm them either)


 [1] http://kb.mozillazine.org/Network.protocol-handler.external-default

 [2] http://kb.mozillazine.org/Network.IDN_show_punycode

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 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.

 2) In 59, when the only 'full' add-ons are 'system' add-ons we'll need to
 figure this out ourselves anywhere. This will probably involve Tor signing
 Tor Launcher and TorButton with its own system add-on keys. Dev Tools is
 an open question.

 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.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://blog.nightly.mozilla.org/2017/07/17/preview-storage-api-in-
 firefox-nightly/

 This will be a concern for 59; but it would be great to get it on the
 Fingerprinting radar (if it isn't already) ASAP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 dcf):

 Replying to [comment:8 sigma4111]:
 > Why you do not perform this by yourself ?

 I don't read Arabic, I don't know what fonts look good or look bad. My
 computer has different fonts than yours, so even if I try the result will
 be different.

 I tried it in Tor Browser and the font was [[comment:2|Noto Naskh
 Arabic]], but you already said that one does not look good.

 > Any how, I did this using regular Firefox with default setting (not set
 on "Arial" by default, & allow sites to select it's owen fonts. Take
 result: "Arial" (or "Arial Bold" or "Arial italic") are the fonts for all
 contents that I tested. Only one exception is head of site which is both
 "George bold" + "Time new Roman bold".

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Applications/Tor bundles/installation]: 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:  Applications/Tor |Version:  Tor:
  bundles/installation   |  0.3.0.9
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by lanealucy):

 * version:   => Tor: 0.3.0.9


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

[tor-bugs] #22972 [Applications/Tor bundles/installation]: 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:  Applications/Tor bundles/installation  |Version:
 Severity:  Blocker|   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 if i set a config file with command line argument, its looks like tor read
 only the first letter.

 torrc:
 SOCKSPort 1234

 Output:
 Jul 19 02:28:41.488 [notice] Tor 0.3.0.9 (git-22b3bf094e327093) running on
 Windo
 ws 8 [server] with Libevent 2.0.22-stable, OpenSSL 1.0.2k and Zlib 1.2.8.
 Jul 19 02:28:41.491 [notice] Tor can't help you if you use it wrong! Learn
 how t
 o be safe at https://www.torproject.org/download/download#warning
 Jul 19 02:28:41.511 [notice] Read configuration file
 "c:\users\administrator.ll-
 dc02\documents\visual studio 2013\Projects\Lissy Cruuv\unbreakable non-
 server co
 munication\bin\Debug\tor\data\torrc".
 Jul 19 02:28:41.520 [warn] The abbreviation 'S' is deprecated. Please use
 'Socks
 SocketsGroupWritable' instead
 Jul 19 02:28:41.520 [warn] Path for GeoIPFile () is relative and
 will r
 esolve to C:\Users\Administrator.LL-DC02\. Is this what you
 wanted?
 Jul 19 02:28:41.520 [warn] Path for GeoIPv6File () is relative
 and will
  resolve to C:\Users\Administrator.LL-DC02\. Is this what you
 wanted?
 Jul 19 02:28:41.523 [notice] Opening Socks listener on 127.0.0.1:9050
 Jul 19 02:28:42.000 [notice] Bootstrapped 0%: Starting
 Jul 19 02:28:43.000 [notice] Starting with guard context "default"
 Jul 19 02:28:43.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Jul 19 02:28:45.000 [notice] Bootstrapped 85%: Finishing handshake with
 first ho
 p
 Jul 19 02:28:45.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
 Jul 19 02:28:45.000 [notice] Tor has successfully opened a circuit. Looks
 like c
 lient functionality is working.
 Jul 19 02:28:45.000 [notice] Bootstrapped 100%: Done

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

Re: [tor-bugs] #17278 [Core Tor/Tor]: Fix malleable relay crypto

[Tor Bug Tracker & Wiki]

#17278: Fix malleable relay crypto
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay needs-proposal research-   |  Actual Points:
  program crypto |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
 |  Sponsor3-can
-+-
Changes (by catalyst):

 * cc: catalyst (added)
 * sponsor:   => Sponsor3-can


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

Re: [tor-bugs] #17278 [Core Tor/Tor]: Fix malleable relay crypto

[Tor Bug Tracker & Wiki]

#17278: Fix malleable relay crypto
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay needs-proposal research-   |  Actual Points:
  program crypto |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-

Old description:

> This has been an annoyance in our protocol for entirely too long.  Once
> we have a solid proposal (#5640) for this, we should implement it
> posthaste.

New description:

 This has been an annoyance in our protocol for entirely too long.  Once we
 have a solid proposal (#5460) for this, we should implement it posthaste.

--

Comment (by catalyst):

 Fix ticket reference in the description.

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

Re: [tor-bugs] #22963 [Core Tor/Tor]: Make relay integrity digests harder to guess by padding cells with random bytes

[Tor Bug Tracker & Wiki]

#22963: Make relay integrity digests harder to guess by padding cells with 
random
bytes
--+
 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:  security  |  Actual Points:
Parent ID:  #22948| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We could random pad the unused bytes in RELAY_DATA cells, because we're
 unlikely to extend them.

 But any other types are really hard to random-pad, because we want that
 space to add future fields in, and zero is a useful default.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 isis):

 Replying to [comment:2 yawning]:
 > This is probably more an upstream issue since the practical result is
 "Extension Signing is worthless vs adversaries that can produce SHA1
 collisions".

 Ugh. And yeah, this seems to be an upstream issue, we should see if
 they've already got a fix they're working on.

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

Re: [tor-bugs] #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):

 The XPI signing method is broken (#22971), so I need to think of something
 better.

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

Re: [tor-bugs] #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:
--+--
Changes (by yawning):

 * keywords:   => tbb-security
 * priority:  Medium => High
 * severity:  Normal => Major


Comment:

 This is probably more an upstream issue since the practical result is
 "Extension Signing is worthless vs adversaries that can produce SHA1
 collisions".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://wiki.mozilla.org/Add-ons/Extension_Signing

 Signing 2 hashes of a manifest file containing 2 hashes each of every file
 in an archive, especially when "2 hashes" is MD5 and SHA1 is
 cryptographically unsound.

 See Joux, A., "Multicollisions in Iterated Hash Functions. Application to
 Cascaded Constructions".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 yawning):

 Replying to [comment:5 tom]:
 > > So their "Privacy Notice" is full of shit and links to incomplete opt
 out documentation.  Like I said, I don't doubt that this happens.
 >
 > Describing it as 'full of shit' seems inaccurate to me. It links to
 incorrect documentation and thus is misleading people about actually
 opting out, but it clearly describes that it collects technical
 information that can be used to identify people.

 The opt out instructions don't work.

 > I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address
 the incorrect information.

 Thank you.

 > I am confused why the add-on blocklist is (attempted) to be disabled via
 the old pref. Extension blocklisting and updating (and that it is enabled
 in Tor Browser) is discussed in detail in #21200 and is actually targeted
 as the first onion service Mozilla deploys. That is behind schedule but
 nonetheless - the fact that it's used in Tor Browser was (I thought) well
 established.

 It might even make it to production before a Tor Browser release that
 disables the "Get Addons" pane (#22073).

 > That Mozilla could block Tor Extensions (like Tor Launcher) also sounds
 bad, but also in practice doesn't matter - when this is done the browser
 stops working but does not bypass the (no-longer-present) proxy. If Tor
 wanted to turn off blocklist updating nonetheless, I'd say that's
 reasonable since we discourage users from installing custom extensions and
 in general don't support that use case.

 I just pushed a commit to the sandboxed version that forces it off,
 because the container setup explicitly only exposes standard extensions
 within the container.

 > [0] I know HTTPS Everywhere uses a separate additional signing key that
 Mozilla doesn't control that should prevent Mozilla from pushing updates.
 I actually haven't checked NoScript but I hope it does the same?

 The XPI says "yeah right" (Keys/signatures omitted for brevity).

 {{{
 Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1496120746499 (0x15c57bee203)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
 Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress
 =services-ops+addonsign...@mozilla.com
 Validity
 Not Before: May 30 05:05:46 2017 GMT
 Not After : May 29 05:05:46 2022 GMT
 Subject: OU=Production, C=US, L=Mountain View, O=Addons, ST=CA,
 CN={73a6fe31-595d-460b-a920-fcc0f8843232}

 Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1048578 (0x12)
 Signature Algorithm: sha384WithRSAEncryption
 Issuer: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
 Signing Service, CN=root-ca-production-amo
 Validity
 Not Before: Mar 17 23:52:42 2015 GMT
 Not After : Mar 14 23:52:42 2025 GMT
 Subject: C=US, O=Mozilla Corporation, OU=Mozilla AMO Production
 Signing Service, CN=production-signing-ca.addons.mozilla.org/emailAddress
 =services-ops+addonsign...@mozilla.com
 }}}

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

Re: [tor-bugs] #22969 [Applications/Tor Browser Sandbox]: Figure out all the other ways that Firefox phones home, and kill them with fire if possible.

[Tor Bug Tracker & Wiki]

#22969: Figure out all the other ways that Firefox phones home, and kill them 
with
fire if possible.
-+-
 Reporter:  yawning  |  Owner:  yawning
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser Sandbox |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sandbox-fingerprinting sandbox-  |  Actual Points:
  security   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * status:  new => accepted


Comment:

 Addon blocklist: https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=3c16354887c39eb319f27de7b28a9fe133cd8ad3

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 tom):

 It's intentional that certificate errors are ignored. We have to deal with
 tls-intercepting and messed up middleboxes. Updates are the same way.
 Blocklists should be signed, and edited blocklists (such as with Burp)
 should not be accepted. If you can find a way to bypass that, please file
 a Mozilla security bug and collect a nice bounty.

 Replying to [comment:4 yawning]:
 > Replying to [comment:3 basvd]:
 > > Blocklist is using this one: extensions.blocklist.enabled (..and
 that's default true)
 >
 > So their "Privacy Notice" is full of shit and links to incomplete opt
 out documentation.  Like I said, I don't doubt that this happens.

 Describing it as 'full of shit' seems inaccurate to me. It links to
 incorrect documentation and thus is misleading people about actually
 opting out, but it clearly describes that it collects technical
 information that can be used to identify people.

 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1382006 to address
 the incorrect information.



 I am confused why the add-on blocklist is (attempted) to be disabled via
 the old pref. Extension blocklisting and updating (and that it is enabled
 in Tor Browser) is discussed in detail in #21200 and is actually targeted
 as the first onion service Mozilla deploys. That is behind schedule but
 nonetheless - the fact that it's used in Tor Browser was (I thought) well
 established.

 The certificate thing is a misunderstanding. Breaking TLS sounds bad, but
 shouldn't matter in practice.

 That Mozilla could block Tor Extensions (like Tor Launcher) also sounds
 bad, but also in practice doesn't matter - when this is done the browser
 stops working but does not bypass the (no-longer-present) proxy. If Tor
 wanted to turn off blocklist updating nonetheless, I'd say that's
 reasonable since we discourage users from installing custom extensions and
 in general don't support that use case.

 If you can find a way for Mozilla to force install extensions, flip prefs,
 or update extensions outside of the extension developer's control[0] -
 that would be a very concerning bug.

 Mozilla *can* revoke CAs unilaterally without Tor's control via OneCRL.

 [0] I know HTTPS Everywhere uses a separate additional signing key that
 Mozilla doesn't control that should prevent Mozilla from pushing updates.
 I actually haven't checked NoScript but I hope it does the same?

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

Re: [tor-bugs] #22968 [Applications/Tor Browser]: Tor embedded with TBB 7.5a2 ignores torrc

[Tor Bug Tracker & Wiki]

#22968: Tor embedded with TBB 7.5a2 ignores torrc
--+---
 Reporter:  heywoodj123@… |  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 brade):

 * status:  new => needs_information


Comment:

 This works for me.  I was able to add a SocksPort line to my torrc file,
 open Tor Browser, and then use the additional port.

 Make sure that Tor Browser and tor.real are not running when you edit the
 file:
   /Users/heywood/Library/Application Support/TorBrowser-Data/Tor/torrc

 If it is still not working, please attach your torrc file to this 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] #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 yawning):

 Replying to [comment:3 basvd]:
 > Blocklist is using this one: extensions.blocklist.enabled (..and that's
 default true)

 So their "Privacy Notice" is full of shit and links to incomplete opt out
 documentation.  Like I said, I don't doubt that this happens.

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

Re: [tor-bugs] #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 basvd):

 Replying to [comment:2 yawning]:
 > > 3. In the Filter text box, type extensions.getAddons.cache.enabled.
 > > 4. Double click the extensions.getAddons.cache.enabled item to turn it
 from true to false
 >
 > That pref is disabled by default in Tor Browser.

 Blocklist is using this one: extensions.blocklist.enabled (..and that's
 default true)

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

Re: [tor-bugs] #22970 [Webpages/Website]: torprojects.org onion site is not loading

[Tor Bug Tracker & Wiki]

#22970: torprojects.org onion site is not loading
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Dbryrtfbcbhgf):

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


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

Re: [tor-bugs] #22943 [Core Tor/Stem]: Add Travis CI configuration so that Github forks receive CI coverage

[Tor Bug Tracker & Wiki]

#22943: Add Travis CI configuration so that Github forks receive CI coverage
-+-
 Reporter:  patrickod|  Owner:  atagar
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci unit-  |  Actual Points:
  testing testing new-developers travis best-|
  practice   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * status:  needs_information => new


Comment:

 Replying to [comment:1 atagar]:
 > Hi Patrick, Stem already has CI via Jenkins...
 >
 > https://jenkins.torproject.org/job/stem-tor-ci/
 >
 > They're broken at the moment but that's another story...
 >
 > https://trac.torproject.org/projects/tor/ticket/22790
 >
 > Folks indeed make GitHub forks to send me pull requests but I'm unsure
 why CI would be important to them. They pull from master, make their
 change, run tests, and send me a pull request. It's not a long-lived fork.
 If it is they'd certainly be welcome to add this to themselves.
 >
 > Is there something I'm missing?

 In terms of the benefits to newcomers, I think of it more as a friendly
 way of saying "here's what I expect to pass if you fork my code and change
 it" and giving new developers a super easy way to prove to you (before you
 spend time on code review) that they met that expectation.

 W.r.t. benefits to core maintainers/developers, I find it's really nice to
 not have to wait until something is in the master (or whichever
 maintenance branch) of the official main repo to know if something broke,
 or if it had a bad reaction with something else that was merged, etc.
 (This is maybe more beneficial to things like little-t tor which have a
 lot of people hacking in different directions all at once, but Stem
 contributors are also growing and it's getting a lot of love from
 different people.) Also for me, I feel like it makes the development
 workflow much faster, because instead of "make commit, run tests locally,
 wait, repeat" it's more like "make commit, push, repeat, (possibly get
 notified of breakage and make a fixup commit)".  It also serves to assure
 me that it's not "just working on my machine" but that another machine out
 there is able to get the same test results. Also, it's somehow incredibly
 satisfying to watch e.g. https://travis-
 ci.org/isislovecruft/bridgedb/builds/ and see all the little icons turn
 from yellow to (usually, hopefully) green.

 I can probably go on and on more about how great it is to have CI
 everywhere all the time, if you want more reasons. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22970 [Webpages/Website]: torprojects.org onion site is not loading

[Tor Bug Tracker & Wiki]

#22970: torprojects.org onion site is not loading
--+-
 Reporter:  Dbryrtfbcbhgf |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 torprojects.org onion site is not loading expyuzz4wqqyqhjn.onion
 TBB 7.0.2

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

Re: [tor-bugs] #22968 [Applications/Tor Browser]: Tor embedded with TBB 7.5a2 ignores torrc

[Tor Bug Tracker & Wiki]

#22968: Tor embedded with TBB 7.5a2 ignores torrc
--+--
 Reporter:  heywoodj123@… |  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):

 * owner:   => tbb-team
 * cc: mcs, brade (added)
 * 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] #22969 [Applications/Tor Browser Sandbox]: Figure out all the other ways that Firefox phones home, and kill them with fire if possible.

[Tor Bug Tracker & Wiki]

#22969: Figure out all the other ways that Firefox phones home, and kill them 
with
fire if possible.
-+-
 Reporter:  yawning  |  Owner:  yawning
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser Sandbox |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sandbox-fingerprinting sandbox-  |  Actual Points:
  security   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * keywords:   => sandbox-fingerprinting sandbox-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] #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:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

 * keywords:   => sandbox-fingerprinting


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 yawning):

 Sigh.  Per Mozilla's documentation this should not be happening, though at
 this point I have no reason to doubt that it is.

 https://www.mozilla.org/en-US/privacy/firefox/
 > Add-ons Blocklist: Firefox contacts Mozilla once per day to check for
 add-on information to check for malicious add-ons. This includes, for
 example: browser version, OS and version, locale, total number of
 requests, time of last request, time of day, IP address, and the list of
 add-ons you have installed. You can turn off metadata updates at any time,
 but it may leave you open to security vulnerabilities.

 https://blog.mozilla.org/addons/how-to-opt-out-of-add-on-metadata-updates/
 > 3. In the Filter text box, type extensions.getAddons.cache.enabled.
 > 4. Double click the extensions.getAddons.cache.enabled item to turn it
 from true to false

 That pref is disabled by default in 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] #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:  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 appears like something I can preempt by setting the
 `breakpad.reportURL` pref.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22969 [Applications/Tor Browser Sandbox]: Figure out all the other ways that Firefox phones home, and kill them with fire if possible.

[Tor Bug Tracker & Wiki]

#22969: Figure out all the other ways that Firefox phones home, and kill them 
with
fire if possible.
--+-
 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:|
--+-
 At this point, I think I basically have to assume that anything in firefox
 making requests to *.mozilla.[org,com] is either written horrendously
 (#22966), or actively malicious (#22900).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22968 [- Select a component]: Tor embedded with TBB 7.5a2 ignores torrc

[Tor Bug Tracker & Wiki]

#22968: Tor embedded with TBB 7.5a2 ignores torrc
--+-
 Reporter:  heywoodj123@… |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This version of Tor, which comes embedded in TorBrowser 7.5a2, seems to
 read only torrc-defaults when TBB is launched. Thus any changes (such as
 adding a second SocksPort line to torrc) get ignored unless they are made
 to torrc-defaults.

 In particular, {{{ps aux | grep -i tor.real}}} yields the following (note
 the argument passed to the --defaults-torrc flag):

 {{{
 heywood1799   0.0  0.5  2482880  39152   ??  S11:36AM
 0:01.92 ./tor.real --defaults-torrc
 /Applications/Firefox_Tor_7.5a2.app/Contents/Resources/TorBrowser/Tor
 /torrc-defaults -f /Users/heywood/Library/Application Support/TorBrowser-
 Data/Tor/torrc [...] +__ControlPort 9151 +__SocksPort 127.0.0.1:9150
 IPv6Traffic PreferIPv6 KeepAliveIsolateSOCKSAuth __OwningControllerProcess
 1798
 }}}

 Moreover, if I quit TBB, move the torrc file out of ~/Library/Application
 Support/TorBrowser-Data/ and restart TBB, torrc gets created there anew,
 but it is empty (zero bytes).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This is a GSOC project.  Firefox from the sandbox should NEVER send these.

 https://trac.torproject.org/projects/tor/wiki/doc/gsoc

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

Re: [tor-bugs] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * cc: yawning (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] #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:
--+--
Changes (by yawning):

 * cc: yawning (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

[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 |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Once a day the Firefox/Tor browser will do a call to the Firefox blocklist
 service. The URL of this endpoint is (extensions.blocklist.url):

 {{{
 
https://blocklists.settings.services.mozilla.com/v1/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/
 }}}
 Example:

 {{{
 https://blocklist.addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-
 9b0e-13a3a9e97384%7D/52.2.0/Firefox/20170202030101/WINNT_x86-gcc3/en-
 US/release/Windows_NT%2010.0/default/default/34/34/1/
 }}}
 '''1) The browser suppresses bad certificate errors on this URL
 '''The Firefox blocklist service suppresses bad certificates errors while
 downloading the blocklist.xml. In this way it is quite easy to setup a
 MitM attack and remove revoked certificates from the blocklist.xml

 Proof of concept;

  * Run a webserver listening to
 https://blocklists.settings.services.mozilla.com
  * Create a fake blocklist XML (/v1/blocklist/etc...)
  * Add 12.34.56.78 blocklists.settings.services.mozilla.com to your host
 file
  * Reset app.update.lastUpdateTime.blocklist-background-update-timer and
 change extensions.blocklist.interval
  * Wait until Tor calls these blocklist service.
  * Check the blocklist.xml inside the Tor installation folder

 '''2) Mozilla is able to see Tor user specific information:
 '''There is a lot of OS/platform/browser specific information in the URL.
 So Mozilla has a lot of statistics about the Tor browser usage. Not
 necessary IMHO.

 APP_ID
 APP_VERSION
 PRODUCT
 VERSION
 BUILD_ID
 BUILD_TARGET
 OS_VERSION
 LOCALE
 CHANNEL
 PLATFORM_VERSION
 DISTRIBUTION
 DISTRIBUTION_VERSION
 PING_COUNT
 TOTAL_PING_COUNT
 DAYS_SINCE_LAST_PING

 The TOTAL_PING_COUNT (stored in extensions.blocklist.pingCountTotal) is
 also interesting. Because this number increments every time you start the
 Tor browser. (note: once a day). As you can see the number in the URL
 above is 34, what means that the Tor browser was started at least 34
 times/days.

 '''Technical info:'''

 source code: [https://dxr.mozilla.org/mozilla-
 central/source/toolkit/mozapps/extensions/nsBlocklistService.js#627
 XMLHttpRequest with BadCertHandler]

 source code: [https://dxr.mozilla.org/mozilla-
 central/source/toolkit/modules/CertUtils.jsm#173 BadCertHandler]:

 {{{
 /**
  * This class implements nsIBadCertListener.  Its job is to prevent "bad
 cert"
  * security dialogs from being shown to the user.  It is better to simply
 fail
  * if the certificate is bad. See bug 304286.  <--   :-|
  */
 }}}
 Another URL with sensitive data is extensions.update.background.url:

 {{{
 https://versioncheck-
 
bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%¤tAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%
 }}}
 '''Related Bugzilla tickets:'''

  * [https://bugzilla.mozilla.org/show_bug.cgi?id=366191 Something tries to
 MITM Firefox's automatic connection to addons.mozilla.org, resulting in an
 annoying expired-certificate dialog]
  * [https://bugzilla.mozilla.org/show_bug.cgi?id=304286 Certificate
 failures during automatic check for updates should not give user choice to
 connect anyway]

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 [https://xkcd.com/331/ Looks Photoshopped].

 Sorry, couldn't help it. Thanks though, picture made me laugh this
 morning. ;P

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 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:   |Sponsor:  SponsorR-
 |  can
-+-
Changes (by asn):

 * status:  assigned => needs_review


Comment:

 Please check branch `bug22735` in my repo for a fix to the original issue
 of this ticket, plus comment:8.

 I made a gitlab MR here:
 https://oniongit.eu/asn/tor/merge_requests/1


 There is also a torspec branch that you can find at `bug22735` in my
 torspec repo:
 https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=bug22735

 David, you probably want to merge this into your #20657 branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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):

 Why you do not perform this by yourself ?

 Any how, I did this using regular Firefox with default setting (not set on
 "Arial" by default, & allow sites to select it's owen fonts. Take result:
 "Arial" (or "Arial Bold" or "Arial italic") are the fonts for all contents
 that I tested. Only one exception is head of site which is both "George
 bold" + "Time new Roman bold".

 In this case how can I help further ? If "Arial" not free to be used in
 Tor browser, what we can do ?

 By the way, what about "Time new Roman" ? Is it also not free ?

 Please notice that regarding head of site, English part of title appear
 correct in Tor while Arabic part of title not appearing correctly -
 regarding font type.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_information
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iwakeh):

 * status:  accepted => needs_information


Comment:

 I'm pretty far with the code and mostly concerned with sync, test-code,
 and debugging now.  This made made me aware of the webstats-log-files
 being the only files available on CollecTor (in future) that is not yet
 covered by metrics-lib.  For the sync-part I introduced a temporary
 'LogDescriptor' in CollecTor.

 Should I add a 'LogDescriptor' and its implementation to metrics-lib?  Are
 there any reasons why not?

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hellais):

 Here is photographic evidence that this is in fact my new PGP key:
 https://twitter.com/hellais/status/887320708266819589.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

[Tor Bug Tracker & Wiki]

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 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):

 Common approach for storing:
 It turns out that the functionality in OnionperfDownloader was too
 restrictive.
 Here's an overview:
 - bridge-desc (all types): after sanitation the descriptor is written; if
 one descriptor cannot be sanitized, it is skipped
 - relay-desc (all types): descriptors written one by one skipping
 problematic ones
 - exitlists: always stored as a single file.

 Solution: if a single TorperfResult is not parseable, it should simply be
 skipped as in the sync-implementation.

 Another topic, which relates to comment:7:
 Currently, all synced descriptors receive their annotation from the
 Annotation enum (cf. package o.t.c.conf.Annotation).  This happens,
 because only the raw bytes are taken from a given descriptor and written
 to the file system.
 But, actually the annotation(s) should be taken from the 'getAnnotations'
 method and be prepended to the raw descriptor bytes, shouldn't they?
 The fix for this would also simplify some sync-code.  New ticket also for
 milestone 1.3.0?

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

Re: [tor-bugs] #15967 [Obfuscation/BridgeDB]: Separate BridgeDB's CAPTCHA into another service

[Tor Bug Tracker & Wiki]

#15967: Separate BridgeDB's CAPTCHA into another service
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-https captcha tor-launcher  |  Actual Points:  2
  ooni-probe |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorM
-+-

Comment (by mcs):

 Replying to [comment:4 isis]:
 > Couple things I realised I should do:
 >
 >  * There should be a 'version' field in every JSON thing so that we can
 add things later if we need to.

 That seems like a good idea even if we never end up changing it (with JSON
 you have a lot of flexibility to add fields as needed without necessarily
 bumping the version).

 >  * There should probably be a 'type' field in every JSON thing so that
 we know which part of the protocol it is.

 Seems like a good idea and having it may also aid in debugging the
 protocol.

 >  * The JSON in the `data` URL parameter should be en-/de- coded as URL-
 safe base64. (And it should probably just be in the body of the POST
 request?)

 I like the idea of putting the response in the POST request, but maybe it
 is small so it doesn't matter much? That raises another issue: Kathy and I
 don't know exactly what the response will look like. Will all of the
 CAPTCHAs be similar to the ones that are currently used by bridgedb?
 E.g.:
  https://bridges.torproject.org/bridges?transport=obfs4
 In any case, Tor Launcher will need to know how to present the image and
 what kind of response to ask the user for (e.g., text).

 Also, maybe the server should return the "Enter the characters from the
 image above" prompt text so the server has more flexibility about that
 form of the CAPTCHA (or is the in the challenge field?) One challenge is
 localization of the prompt. The server could respect the Accept-Language
 header, but that is not necessarily correct for Tor Browser due to our
 English language spoofing feature. Hmmm.

 > Also, in order to conform to [http://jsonapi.org/format/ the JSON API
 standard], I need to change the following things:
 > ...

 That looks like a lot of complexity, but it might be worthwhile if we are
 going to have more JSON messages. I assume we will, e.g., Tor Launcher
 will request bridges from moat via a JSON request.

 > Also, it just occurred to me that Tor Launcher should probably just talk
 to the moat server, which will talk to farfetchd. For the CAPTCHA stuff
 moat will just be passing things between Tor Launcher and farfetchd so the
 concerns about the API here are still relevant.

 I was going to ask about that... requesting a CAPTCHA and solving it is
 not useful unless the server that cares about the CAPTCHA is involved,
 right? Is there a document available that shows how the pieces will fit
 together? If not, we should create one.

 One more comment on your proposed API: Kathy and I would prefer error
 codes (numbers) rather than error strings, or at least a code plus a
 string. We will want to localize the errors that are displayed by Tor
 Launcher. It looks like the JSON API format includes this concept because
 error responses have a code as well as title and detail strings.

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

 * status:  reopened => needs_information


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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 db.torproject.org lists keys if you search for users.  Getting sigs from
 people @torproject.org should not be too hard I hope.

 Generally, I need a reasonable trust path to that key.

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

Re: [tor-bugs] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Thanks.  I'll see what I can come up with.

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

Re: [tor-bugs] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:1 weasel]:
 > Can you get more specific on what you mean with 'healthy amount of disk
 space'?

 Ah, 100GB, if that won't be difficult? If it is, can we shoot for at least
 30GB free after the OS takes it's share?

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hellais):

 > Ideally, two or more keys already in the deb.tpo keyring would have
 signed your key.

 Is there a place where I can get the list of such 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] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Ideally, two or more keys already in the deb.tpo keyring would have signed
 your key.

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

Re: [tor-bugs] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Can you get more specific on what you mean with 'healthy amount of disk
 space'?

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hellais):

 Replying to [comment:1 weasel]:
 > This key has no signatures, and this request isn't signed (nor are there
 any unrevoked keys that could sign it, AIUI.)


 Who must I get it signed by?

 Can I use some other form of verification to validate I am the real owner
 of this key?

 > You'll need to get your key properly signed first.

 Maybe you can leave this ticket open, while I obtain the requirements to
 satisfying this 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] #22953 [Internal Services/Tor Sysadmin Team]: Please replace my ldap key

[Tor Bug Tracker & Wiki]

#22953: Please replace my ldap key
-+
 Reporter:  Sebastian|  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #22965 [Applications/Tor bundles/installation]: Please adopt torbrowser-launcher on deb.torproject.org

[Tor Bug Tracker & Wiki]

#22965: Please adopt torbrowser-launcher on deb.torproject.org
---+---
 Reporter:  d3vid  |  Owner:  erinn
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor bundles/installation  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * owner:  tbb-team => erinn
 * component:  Applications/Tor Browser => Applications/Tor
 bundles/installation


Comment:

 FWIW: we can move this forward once we find somebody in the community who
 wants to maintain torbrowser-launcher on deb.torproject.org.

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

Re: [tor-bugs] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 This key has no signatures, and this request isn't signed (nor are there
 any unrevoked keys that could sign it, AIUI.)

 You'll need to get your key properly signed first.

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

Re: [tor-bugs] #22965 [Applications/Tor Browser]: Please adopt torbrowser-launcher on deb.torproject.org

[Tor Bug Tracker & Wiki]

#22965: Please adopt torbrowser-launcher on deb.torproject.org
--+--
 Reporter:  d3vid |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by weasel):

 * owner:  weasel => tbb-team
 * component:  Internal Services/Service - deb.tpo => Applications/Tor
Browser


Comment:

 This is not a bug with the deb.tpo infrastructure.  Moving back.

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

Re: [tor-bugs] #22965 [Internal Services/Service - deb.tpo]: Please adopt torbrowser-launcher on deb.torproject.org

[Tor Bug Tracker & Wiki]

#22965: Please adopt torbrowser-launcher on deb.torproject.org
-+
 Reporter:  d3vid|  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

 * owner:  tbb-team => weasel
 * component:  Applications/Tor Browser => Internal Services/Service -
deb.tpo


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

Re: [tor-bugs] #22946 [Applications/Tor Browser Sandbox]: Implement a MAR decompressor/delta updater.

[Tor Bug Tracker & Wiki]

#22946: Implement a MAR decompressor/delta updater.
--+-
 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):

 > Is this is needed because it is simply too risky to rely on any Mozilla
 code to perform updates?

 I'm starting to think so.

 > although I have not analyzed all of the dependencies

 In terms of runtime dependencies, it basically pulls in almost everything
 that firefox does.  The UI libraries like Gtk+ and X11 are entirely
 unneeded for what I'm doing for reasons that should be obvious.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22965 [Applications/Tor Browser]: Please adopt torbrowser-launcher on deb.torproject.org

[Tor Bug Tracker & Wiki]

#22965: Please adopt torbrowser-launcher on deb.torproject.org
--+--
 Reporter:  d3vid |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 To install and maintain Tor Browser Bundle (TBB) on Ubuntu I currently
 need to:

 1. Add deb.torproject.org as a source to get the latest Tor router (per
 https://www.torproject.org/docs/debian)
 2. Add ppa:micahflee/ppa as a source to get the latest torbrowser-launcher
 (per https://github.com/micahflee/torbrowser-launcher#installing-in-
 ubuntu)
 3. Use torbrowser-launcher to get the latest TBB
 4. Rely on sources and torbrowser-launcher for further updates

 My suggestion (if feasible) is to include torbrowser-launcher in
 deb.torproject.org and thereby skip step 2. (Step 2 is also tricky on
 Debian-based distros other than Ubuntu.) This would not only be more
 convenient, but I would have a single point of trust (deb.torproject.org)
 for everything Tor-related.

 Related upstream ticket: https://github.com/micahflee/torbrowser-
 launcher/issues/269

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

Re: [tor-bugs] #22946 [Applications/Tor Browser Sandbox]: Implement a MAR decompressor/delta updater.

[Tor Bug Tracker & Wiki]

#22946: Implement a MAR decompressor/delta updater.
--+-
 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:
--+-
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 What would be the advantage in having this in the sandbox? Is this is
 needed because it is simply too risky to rely on any Mozilla code to
 perform updates? Their updater code is fairly self-contained (although I
 have not analyzed all of the dependencies).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 dcf):

 Replying to [comment:7 boklm]:
 > When looking at commit fcdc2be0a2da32a939e172564300d5a09259b75e, I
 noticed this line in `gitian/descriptors/mac/gitian-webrtc.yml`:
 > {{{
 > GN_ARGS+=" gold_path=\"$INSTDIR/binutils/bin\""
 > }}}
 >
 > However, I don't think we have a binutils installed in this path in the
 mac build. Is it a line that was copied from the linux descriptor and
 forgotten?

 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.

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

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

Re: [tor-bugs] #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:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201707, snowflake  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by dcf):

 * cc: dcf (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] #22964 [Core Tor/Tor]: Clarify comment about all tor data being encrypted

[Tor Bug Tracker & Wiki]

#22964: Clarify comment about all tor data being encrypted
--+
 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:  comment   |  Actual Points:
Parent ID:  #22961| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #22964 [Core Tor/Tor]: Clarify comment about all tor data being encrypted

[Tor Bug Tracker & Wiki]

#22964: Clarify comment about all tor data being encrypted
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  comment   |  Actual Points:
Parent ID:  #22961| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:   => teor
 * 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] #22964 [Core Tor/Tor]: Clarify comment about all tor data being encrypted

[Tor Bug Tracker & Wiki]

#22964: Clarify comment about all tor data being encrypted
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  comment
Actual Points:|  Parent ID:  #22961
   Points:|   Reviewer:
  Sponsor:|
--+
 This isn't quite accurate:
 {{{
   /* Don't actually allow compression; it uses ram and time, but the data
* we transmit is all encrypted anyway. */
 }}}

 The following "data" isn't encrypted:
 * cell headers
 * non-relay cell types

 I suggest:

 {{{
   /* Don't actually allow compression; it uses ram and time, but the
* circuit data we transmit is encrypted anyway. */
 }}}

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

[Tor Bug Tracker & Wiki]

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 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):

 Replying to [comment:8 karsten]:
 > It took a bit longer to respond to your comment 5, but here it comes:

 Thanks for reviewing!

 >  - The following is entirely unrelated to the given patch, but can you
 try to change your Git commit messages to follow the 50/72 rule? That is,
 the first line has no more than 50 characters (unless that's just too
 hard, in which case 60 are still okay), the next line is blank, and all
 remaining lines are wrapped at 72 characters with newlines added between
 paragraphs. And can you write the first line using the imperative, as in
 "Add sync functionality for tpf files." rather than "Implements XY"?
 Again, this is unrelated to this specific commit, but just like we're
 trying to use a common code style we should aim for using a common commit
 message style. Sorry for the nitpick. :)

 No nitpicking; we even have that
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/ContributorGuide#PatchFormat
 documented].  Will adapt the commits.

 >  - Can you add a change log entry for this change?

 Sure.

 >  - Should we put out a metrics-lib 2.1.0 first towards the end of the
 month, so that we don't have to require a -dev version in the next
 released CollecTor?

 Agreed, the new CollecTor release should only use release versions of
 metrics-lib.
 Wouldn't the next be 2.0.1 for the tiny fix?  Are there more things we
 could release soon?
 Maybe continue the metrics-lib release discussion on #22912 or via mail as
 it feels out of place here?

 >  - Can we keep the old capitalization of OnionPerf in the configs? It
 seems that's what Rob used. It also means fewer changes to the code.

 Well, in general I'd prefer:
 1. consistent naming and capitalization of classes and configuration
 (i.e., OnionperfDownloader.class might need to be renamed too, if
 'OnionPerf*' is chosen.)
 2. rather less capitalization, e.g., prefer 'Exitlist' over 'ExitList'

 Maybe, there are more rules for naming.

 >  - Typo: "Instantiate", not "Instanciate".
 >  - The line `byte[] db = desc.getRawDescriptorBytes();` in
 `SyncPersistence` is probably still left over from testing. This method
 has become really expensive, so we should be careful not to call it more
 often than necessary.

 Get to these two in a new patch when the final topic is addressed.

 >  - I'd like to avoid that we handle descriptors differently depending on
 whether we download them from an OnionPerf host vs. synchronize them from
 a CollecTor host. And I believe that the approach taken in this
 synchronization patch makes more sense than the strict validation approach
 taken in the download part.

 Yes, I agree the simpler version will be better.

 > But maybe we can first take a step back and look at all the other
 modules and find a common approach for all or at least most of them. Let's
 have this discussion first and then merge this patch if it still does what
 we think should be done. Does that make sense?

 Totally, I'll survey that question as next step before any other work
 here.


 > 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] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22912-plus-
 test&id=c6ebd1ada7a4eee3d08ba9e3cf10a05f257e6c82 the branch with tests].

 The tests verify most of the `Descriptor` methods and stay implementation
 independent.

 The fix&tests could be released this week as preparation of CollecTor
 1.3.0 (cf. #21759).

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

Re: [tor-bugs] #22961 [Core Tor/Tor]: Should tor-spec say that nodes MUST NOT use TLS compression?

[Tor Bug Tracker & Wiki]

#22961: Should tor-spec say that nodes MUST NOT use TLS compression?
---+
 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 security  |  Actual Points:
Parent ID:  #18856 | Points:
 Reviewer: |Sponsor:
---+

Comment (by yawning):

 Yes, because that's what the code does:
 {{{
 #ifdef SSL_OP_NO_COMPRESSION
   SSL_CTX_set_options(result->ctx, SSL_OP_NO_COMPRESSION);
 #endif
 #if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,1,0)
 #ifndef OPENSSL_NO_COMP
   /* Don't actually allow compression; it uses ram and time, but the data
* we transmit is all encrypted anyway. */
   if (result->ctx->comp_methods)
 result->ctx->comp_methods = NULL;
 #endif
 #endif
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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):

 When looking at commit fcdc2be0a2da32a939e172564300d5a09259b75e, I noticed
 this line in `gitian/descriptors/mac/gitian-webrtc.yml`:
 {{{
 GN_ARGS+=" gold_path=\"$INSTDIR/binutils/bin\""
 }}}

 However, I don't think we have a binutils installed in this path in the
 mac build. Is it a line that was copied from the linux descriptor and
 forgotten?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201707, tbb-torbutton  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_information => assigned


Comment:

 Replying to [comment:3 mcs]:
 > gk: what do you think of the idea of whitelisting all about: pages?
 (assuming that is possible) Too risky, or a good idea?

 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.

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