Re: [tor-bugs] #26043 [Obfuscation/Snowflake]: building snowflake into a bundle of pluggable transports

[Tor Bug Tracker & Wiki]

#26043: building snowflake into a bundle of pluggable transports
---+
 Reporter:  hans   |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 Replying to [comment:4 arlolra]:
 > Probably `25b304a`

 Thanks, merged as [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=25b304a9a856f8c791882ad523df26ffc8fa629c
 25b304a9a8].

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

Re: [tor-bugs] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+---
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:4 cypherpunks]:
 > Excuse me but your software named Tor is failed on this situation. Isn't
 this a bug?
 Do you have any proof that Tor is actually the thing that failed in this
 situation and not a basic OpSec fail like always (such as using your real
 name in an email, not using Qubes OS 4 or higher with Whonix, ...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] #26233 [Applications/Tor Browser]: Rebase Tor Browser patches for FF61

[Tor Bug Tracker & Wiki]

#26233: Rebase Tor Browser patches for FF61
--+
 Reporter:  sysrqb|  Owner:
  |  arthuredelstein
 Type:  enhancement   | Status:
  |  needs_revision
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806, tbb-mobile  |  Actual Points:
Parent ID:  #25741| Points:
 Reviewer:|Sponsor:
--+
Changes (by sysrqb):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #26233 [Applications/Tor Browser]: Rebase Tor Browser patches for FF61

[Tor Bug Tracker & Wiki]

#26233: Rebase Tor Browser patches for FF61
--+
 Reporter:  sysrqb|  Owner:
  |  arthuredelstein
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806, tbb-mobile  |  Actual Points:
Parent ID:  #25741| Points:
 Reviewer:|Sponsor:
--+
Changes (by sysrqb):

 * status:  needs_revision => assigned
 * owner:  sysrqb => arthuredelstein


Comment:

 Replying to [comment:6 gk]:
 > Two things we should think about while preparing the new branch:
 >
 > 1) How would the naming scheme for our mobile branches look like?
 Currently we have "tor-browser-
 $ESR_VERSION-$TORBROWSER_MAJOR_VERSION-$BRANCH_NUMBER" which points to the
 second question:
 >

 I don't see a problem using this same format. Unfortunately, as mentioned
 before, TB Android will begin overlapping with TB Desktop next year. So,
 either Desktop begins following mozilla-release at that time (next
 ~April), or we choose a unique name.

 > 2) What version number for Tor Browser for Android do we start with?
 Especially given that we are tracking Mozilla release and not esr anymore?
 Should we start over with 1.0?

 Originally I thought we would use the same naming scheme, because "these
 are both tor browser", but after thinking about this more we should
 probably start at 1.0. There are 7 or 8 releases between every ESR, so the
 version would become very confusing. I think if we follow Mozilla's alpha,
 beta, stable then we can start at 1.0 and we'll reach 8.0 by next April.

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

Re: [tor-bugs] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+---
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by sysrqb):

 * status:  reopened => needs_information


Comment:

 Replying to [comment:4 cypherpunks]:
 > > If you find out a bug, please let us know.
 >
 > Excuse me but your software named Tor is failed on this situation. Isn't
 this a bug?

 Can you please be more specific? Do you know what the bug is? We can not
 write a blog post (let alone fix a bug), if we don't have any details. It
 smells like a firefox bug, but based on the Google Translate translations
 there's nothing we can do. We'll close this bug again unless this becomes
 actionable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26339 [Core Tor]: Use same traffic path if destination is the same but the protocol is different.

[Tor Bug Tracker & Wiki]

#26339: Use same traffic path if destination is the same but the protocol is
different.
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
-+
 Many people use Tor to proxify their non-Tor software such as Bitcoin,
 BitMessage. And some of them are using SOCKS4.

 torrc:
 DNSPort X
 SocksPort Y

 1. User's software query DNS via DNSPort: www.example.com
 2. Tor will create a path to www.example.com:0 to resolve its IP
 3. Tor return www.example.com is 1.2.3.4
 4. User's software connect to www.example.com via SocksPort, using Socks4.

 Expected:
 In step 4, Tor will use step 2's path to connect www.example.com because
 Tor know www.example.com may be 1.2.3.4.

 Actual:
 In step 4, Tor create a new path to connect to www.example.com, thus
 www.example.com's server admin will see 2 incoming connection;
 1) DNS request from (step2's exit ip)
 2) WWW request from (step4's exit ip)

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

Re: [tor-bugs] #26337 [Core Tor/Tor]: make rust error types use the failure crate

[Tor Bug Tracker & Wiki]

#26337: make rust error types use the failure crate
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, technical-debt, tor-   |  Actual Points:
  modularity |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Description changed by isis:

Old description:

> As our Rust code increases, we'll eventually want a nicer way to convert
> between error types than we currently have.  We'll probably want to use
> boats's `failure`
> [https://twitter.com/0x424c41434b/status/1005185002399830023 crate].
> They mentioned a while ago that they were going to make a 1.0.0 release
> soon, and afaict there's not really anything about the current release
> that is expected to change, so we can probably start working on this now-
> ish.

New description:

 As our Rust code increases, we'll eventually want a nicer way to convert
 between error types than we currently have.  We'll probably want to use
 boats's `failure` [https://crates.io/crates/failure crate].  They
 mentioned a while ago that they were going to make a 1.0.0 release soon,
 and afaict there's not really anything about the current release that is
 expected to change, so we can probably start working on this now-ish.

--

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

Re: [tor-bugs] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

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


Comment:

 > If you find out a bug, please let us know.

 Excuse me but your software named Tor is failed on this situation. Isn't
 this a bug?

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

[tor-bugs] #26338 [Applications/Tor Browser]: Rebase Orfox patches onto mozilla-beta for TBA

[Tor Bug Tracker & Wiki]

#26338: Rebase Orfox patches onto mozilla-beta for TBA
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:  #25741
   Points:|   Reviewer:
  Sponsor:|
--+
 After #26233 is closed, we can review the mobile patches separately and
 merge them, as well.

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

Re: [tor-bugs] #26337 [Core Tor/Tor]: make rust error types use the failure crate

[Tor Bug Tracker & Wiki]

#26337: make rust error types use the failure crate
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, technical-debt, tor-   |  Actual Points:
  modularity |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by chelseakomlo):

 Is this going to be incorporated into the Rust standard library? If so,
 should we wait for it? (as to not pull in unnecessary external crates).

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Create unit tests for that check static strings match between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Create unit tests for that check static strings match between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 Closing this in favor of #24249, as we will soon have a simple POC for
 Rust constants, which we can later expand into other shared types (within
 reason, as we still want to keep the shared interface small between
 Rust/C).

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Create unit tests for that check static strings match between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Create unit tests for that check static strings match between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

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


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

[tor-bugs] #26337 [Core Tor/Tor]: make rust error types use the failure crate

[Tor Bug Tracker & Wiki]

#26337: make rust error types use the failure crate
-+-
 Reporter:  isis |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  rust, technical-debt, tor-
 Severity:  Normal   |  modularity
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
  Sponsor8-can   |
-+-
 As our Rust code increases, we'll eventually want a nicer way to convert
 between error types than we currently have.  We'll probably want to use
 boats's `failure`
 [https://twitter.com/0x424c41434b/status/1005185002399830023 crate].  They
 mentioned a while ago that they were going to make a 1.0.0 release soon,
 and afaict there's not really anything about the current release that is
 expected to change, so we can probably start working on this now-ish.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by neel):

 I have a pull request here: https://github.com/torproject/tor/pull/139

 I did not include the lines for automatically returning 1.0 on a bridge if
 we have a preferred descriptor in `frac_nodes_with_descriptors()` but you
 (dgoulet) questioned it hence the reason why it's not here. If you want it
 I can add another commit and/or create a new 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] #16824 [Core Tor/Tor]: Emit a warning message about side channel leaks when using relays as clients

[Tor Bug Tracker & Wiki]

#16824: Emit a warning message about side channel leaks when using relays as
clients
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  mike-can, tor-client tor-relay   |  Actual Points:
  sidechannel logging easy   |
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by n-critser):

 mikeperry,
 What do you think the best way to come to a consensus on this would be?
 Seems like we have 2 options available for deciding if a user is both a
 relay and a client:
 1. configuration
 2. execution of code
 If using only the SOCKSPORT catches too many false positives then, I could
 check some of the other existing values to ensure that the user is
 definitely configured to be both.
 Otherwise, I would need to find some other solid indicator functions for
 both and base the warning on those.
 Which do you prefer?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by pospeselr):

 Ok, added (and verified) fallback code in the event that the torbutton
 string query fails for whatever reason to security.js, and I removed the
 non-english locales from the torbutton change.

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "0001-PATCH-Bug-23247-Communicating-security-expectations
 -(tor-browser).patch" added.


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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "0001-PATCH-Bug-23247-Communicating-security-
 expectations-(torbutton).patch" added.


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

[tor-bugs] #26336 [Applications/Tor Browser]: Update tor-browser-settings addon for Fennec 61

[Tor Bug Tracker & Wiki]

#26336: Update tor-browser-settings addon for Fennec 61
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Installing tor-browser-settings results in:
 {{{
 I/Gecko   (21758): 1528468630190addons.xpi  WARNInvalid
 XPI: Error: Install manifest specifies unknown optionsType: 2
 (resource://gre/modules/addons/XPIInstall.jsm:744:13) JS Stack trace:
 loadmanifestfrom...@xpiinstall.jsm:744:13
 }}}

 Indeed, in install.rdf is:
 {{{
   tor-browser-setti...@torproject.org
   2
   true
   false
   1.0.0
   Tor Browser Settings
   Customize Orfox-related
 settings.
   Thomas Rientjes
 data:text/xml,placeholder/
   2
 }}}

 Only options 3 and 5 are now valid:
 {{{
 if (addon.optionsType &&
 addon.optionsType != AddonManager.OPTIONS_INLINE_BROWSER &&
 addon.optionsType != AddonManager.OPTIONS_TYPE_TAB) {
   throw new Error("Install manifest specifies unknown optionsType: " +
 addon.optionsType);
 }
 }}}

 From 52ESR
 {{{
   // Constants for how Addon options should be shown.
   // Options will be opened in a new window
   OPTIONS_TYPE_DIALOG: 1,
   // Options will be displayed within the AM detail view
   OPTIONS_TYPE_INLINE: 2,
   // Options will be displayed in a new tab, if possible
   OPTIONS_TYPE_TAB: 3,
   // Same as OPTIONS_TYPE_INLINE, but no Preferences button will be shown.
   // Used to indicate that only non-interactive information will be shown.
   OPTIONS_TYPE_INLINE_INFO: 4,
   // Similar to OPTIONS_TYPE_INLINE, but rather than generating inline
   // options from a specially-formatted XUL file, the contents of the
   // file are simply displayed in an inline  element.
   OPTIONS_TYPE_INLINE_BROWSER: 5,
 }}}

 From FF61
 {{{
   // Constants for how Addon options should be shown.
   // Options will be displayed in a new tab, if possible
   OPTIONS_TYPE_TAB: 3,
   // Similar to OPTIONS_TYPE_INLINE, but rather than generating inline
   // options from a specially-formatted XUL file, the contents of the
   // file are simply displayed in an inline  element.
   OPTIONS_TYPE_INLINE_BROWSER: 5,
 }}}

 Maybe we can use `optionType: 5` without too much additional trouble.

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

Re: [tor-bugs] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  from-retrospective  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 I think we were thinking of a webpage.

 It also might be a good idea to be able to restrict this if we need to, so
 it can handle trolls saying "/me status: in ur base killin ur doodz" over
 and over.

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

Re: [tor-bugs] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ (was: mapage: increase minimal bandwidth requirements to be consist

[Tor Bug Tracker & Wiki]

#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
---+
 Reporter:  nusenu |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 If we wanted, we could also bump up the actual enforced minimums in the
 code too.

 Right now they're:

 or.h:#define RELAY_REQUIRED_MIN_BANDWIDTH (75*1024)
 or.h:#define BRIDGE_REQUIRED_MIN_BANDWIDTH (50*1024)

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

Re: [tor-bugs] #22074 [Applications/Tor Browser]: Review Firefox Developer Docs and Undocumented bugs since FF52esr

[Tor Bug Tracker & Wiki]

#22074: Review Firefox Developer Docs and Undocumented bugs since FF52esr
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Here are the items that Kathy and I found so far that we do not think are
 covered by other open tickets:

 https://bugzilla.mozilla.org/show_bug.cgi?id=1344669.
 Support for the `dom.enable_user_timing` pref, which we set to `false`,
 has been removed. We may need to restore support for this pref.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1251161
 https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Masking
 Support for CSS masks was added and may represent a fingerprinting risk
 (e.g., if behavior is different for different platforms or GPUs).

 https://bugzilla.mozilla.org/show_bug.cgi?id=1287983
 https://bugzilla.mozilla.org/show_bug.cgi?id=1264125
 https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions
 Support for CSS Transition events was added (transitionstart,
 transitionrun, and transitioncancel). This may pose risks similar to CSS
 animations; see #18273.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1250077
 https://developer.mozilla.org/en-
 US/docs/Web/API/WEBGL_compressed_texture_astc
 https://bugzilla.mozilla.org/show_bug.cgi?id=1325113
 https://developer.mozilla.org/en-
 US/docs/Web/API/WEBGL_compressed_texture_s3tc_srgb
 Support for these WebGL extensions was added. We should verify that both
 are disabled by our setting `webgl.disable-extensions` to `false`.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1239100
 https://developer.mozilla.org/en-US/docs/Web/API/SVGGeometryElement
 The SVGGeometryElement interface has been partially implemented. We should
 verify that it does not add a fingerprinting risk due to methods such as
 SVGGeometryElement.getPointAtLength() which locates a point part way along
 an arbitrary path.

 https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path
 https://bugzilla.mozilla.org/show_bug.cgi?id=1247229
 Support for CSS clip-path on shapes was added. We should verify that this
 does not have any associated fingerprinting risks. There was a pref to
 disable this feature, but support for the pref was removed during the
 ESR60 development cycle.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1340655
 As we know, support for HTTP 1.x pipelining was removed. We should remove
 the related prefs from browser/app/profile/000-tor-browser.js

 https://bugzilla.mozilla.org/show_bug.cgi?id=1399036
 The date and time  types are now enabled. We should verify that
 this does not leak the user's locale, e.g., if the input field dimensions
 are different in different locales. There is a `dom.forms.datetime` pref
 that may be used to remove support for these  types.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1314959
 https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API
 window.requestIdleCallback() is now available. We should determine whether
 it may be used to learn too much about the performance of the user's
 computer/device, or if there are other timing leaks we want to avoid. This
 can be disabled by setting `dom.requestIdleCallback.enabled` to `false`.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1321865
 https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
 Support the Intersection Observer API was added. It "provides a way to
 asynchronously observe changes in the intersection of a target element
 with an ancestor element or with a top-level document's viewport." and may
 add linkability or fingerprinting risks.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1151421
 The window.pageYOffset/pageXOffset/scrollX/scrollY properties now return
 data withe subpixel accuracy. We think this means "half pixels on a macOS
 Retina or other high resolution display." Does this pose any
 fingerprinting risks? We may already round these when
 `privacy.resistFingerprinting` is `true`.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1364297
 A name property was added to Worker() and SharedWorker(). We don't think
 this adds any new linkability risks though since workers can already
 communicate via messages.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
 https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content
 Support for  was added in Firefox 56 but it was
 disabled in Firefox 57 "because of various web compatibility issues." We
 should verify that this is still 

Re: [tor-bugs] #16516 [Applications/Tor Browser]: TBB doesn't use page title when bookmarking by dragging globe/lock icon

[Tor Bug Tracker & Wiki]

#16516: TBB doesn't use page title when bookmarking by dragging globe/lock icon
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by safdsfds):

 Still have this issue in TorBrowser 7.5.4 with TorButton 1.9.8.6

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

Re: [tor-bugs] #26326 [Applications/Tor Browser]: wine error when building Firefox ESR60 Windows x86_64

[Tor Bug Tracker & Wiki]

#26326: wine error when building Firefox ESR60 Windows x86_64
+--
 Reporter:  sukhbir |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 Replying to [comment:10 sukhbir]:
 > The `xvfb` change above is pretty simple (in `firefox/build`);
 >
 > {{{
 >  rm -f configure
 >  rm -f js/src/configure
 >
 > +Xvfb :1 -screen 0 800x600x16 &
 > +export DISPLAY=:1.0
 > }}}
 >
 > (I am not sure if the resolution is needed...)

 Maybe you could use `xvfb-run`, with something like:
 {{{
 [% IF c("var/windows") %]xvfb-run[% END %] ./mach build
 }}}

 >
 > I also made a few changes for `wine`:
 >
 > {{{
 > +export WINEARCH=win64
 > +export HOME=/var/tmp/home
 > +mkdir -p $HOME
 > +WINEROOT=$HOME/.wine/drive_c
 > }}}
 >
 > and
 >
 > {{{
 >windows-x86_64:
 >  var:
 > +  pre_pkginst: dpkg --add-architecture i386
 >martools_filename: mar-tools-win64.zip
 > +  arch_deps:
 > +- wine
 > +- libwine:i386
 > +- xvfb
 > }}}

 Do we need `libwine:i386` for the 64bit build?

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

Re: [tor-bugs] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  from-retrospective  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by hiro):

 Where should the bot log these messages? Should it be something like the
 meetbot logging to a web page? Or do you have a service in mind?

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

Re: [tor-bugs] #26316 [Core Tor/Tor]: Windows newlines in extrainfo descriptor

[Tor Bug Tracker & Wiki]

#26316: Windows newlines in extrainfo descriptor
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

 * severity:  Minor => Normal


Comment:

 Hi Nick. I disagree that these are valid according to the spec. If they
 were I'd adjust things on Stem's side. For example, here's the spec for
 dirreq-stats-end lines. It does not specify allowing a CR before the NL.

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n919

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

Re: [tor-bugs] #26326 [Applications/Tor Browser]: wine error when building Firefox ESR60 Windows x86_64

[Tor Bug Tracker & Wiki]

#26326: wine error when building Firefox ESR60 Windows x86_64
+--
 Reporter:  sukhbir |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sukhbir):

 The `xvfb` change above is pretty simple (in `firefox/build`);

 {{{
  rm -f configure
  rm -f js/src/configure

 +Xvfb :1 -screen 0 800x600x16 &
 +export DISPLAY=:1.0
 }}}

 (I am not sure if the resolution is needed...)

 I also made a few changes for `wine`:

 {{{
 +export WINEARCH=win64
 +export HOME=/var/tmp/home
 +mkdir -p $HOME
 +WINEROOT=$HOME/.wine/drive_c
 }}}

 and

 {{{
windows-x86_64:
  var:
 +  pre_pkginst: dpkg --add-architecture i386
martools_filename: mar-tools-win64.zip
 +  arch_deps:
 +- wine
 +- libwine:i386
 +- xvfb
 }}}

 This works ... mostly:

 {{{
  2:01.68 err:process:__wine_kernel_init boot event wait timed out
  2:01.92 err:process:__wine_kernel_init boot event wait timed out
  4:01.75 err:process:__wine_kernel_init boot event wait timed out
  4:03.16 err:process:__wine_kernel_init boot event wait timed out
 }}}

 This doesn't seem to affect calling `fxc2` though, because those commands
 complete successfully.

 These will all go in the patch so you can ignore them for now but I am
 documenting them here in case you want to try the `32bit` build or help
 improve the above.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  tbb-fingerprinting, ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Storage API was enabled on release starting with Firefox 57.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1399038

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

Re: [tor-bugs] #26281 [Core Tor/Tor]: Add .editorconfig?: it makes it easier to follow coding standards style with many editors

[Tor Bug Tracker & Wiki]

#26281: Add .editorconfig?: it makes it easier to follow coding standards style
with many editors
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * milestone:   => Tor: 0.3.5.x-final


Comment:

 This looks like it would be a lot cleaner than my current approach (which
 is having special emacs code to detect that I'm editing Tor and to adjust
 my c-mode parameters accordingly).

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

Re: [tor-bugs] #26306 [Core Tor/Tor]: HTTPS proxy doesn't use TLS

[Tor Bug Tracker & Wiki]

#26306: HTTPS proxy doesn't use TLS
---+--
 Reporter:  sf |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.6
 Severity:  Normal | Resolution:
 Keywords:  https, proxy, feature  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * keywords:  https, proxy => https, proxy, feature
 * priority:  Very Low => Low
 * type:  defect => enhancement
 * severity:  Major => Normal
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #26303 [Core Tor/DirAuth]: IPv6-Flagging of Relay not accurate

[Tor Bug Tracker & Wiki]

#26303: IPv6-Flagging of Relay not accurate
---+--
 Reporter:  ruebezahl  |  Owner:  metrics-team
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/DirAuth   |Version:  Tor: 0.3.3.6
 Severity:  Normal | Resolution:
 Keywords:  ipv6 035-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * cc: teor (added)
 * keywords:   => ipv6 035-proposed


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

Re: [tor-bugs] #26316 [Core Tor/Tor]: Windows newlines in extrainfo descriptor

[Tor Bug Tracker & Wiki]

#26316: Windows newlines in extrainfo descriptor
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  035-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * keywords:   => 035-proposed
 * severity:  Normal => Minor
 * milestone:   => Tor: unspecified


Comment:

 Well, that's a confusing one!

 My guess is that this relay was migrated from windows to Linux, and that
 the stats lines that end with CRLF were originally stored on Windows, and
 then copied verbatim from those files when they were reloaded.  Or
 possible somebody was monkeying around with these files in a windows text-
 editor?  That doesn't seem as likely though.

 From dir-spec's POV, I think these lines are valid: ArgumentChar can be
 "any printing ascii character other than NL" currently according to the
 spec, and CR is printable.

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

Re: [tor-bugs] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  from-retrospective  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 It's fine with me if you use it 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] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  from-retrospective  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by mcs):

 * cc: mcs (added)


Comment:

 The browser team is also thinking about using `/me status:`, so in the
 long run a bot might be useful for many Tor people. Side note: a browser
 person is supposed to check with the Network Team before we start using
 this convention; we do not want to disrupt the Network Team's workflow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26335 [Core Tor/Tor]: Use fewer travis builders for typical commits?

[Tor Bug Tracker & Wiki]

#26335: Use fewer travis builders for typical commits?
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci from-retrospective
Actual Points:|  Parent ID:  #25550
   Points:|   Reviewer:
  Sponsor:|
--+---
 We have accumulated a bunch of travis build processes.  Maybe some of them
 should be "fast" ones that happen for every commit in every branch, and
 some should be "slow" ones that happen for pull requests and the mainline
 branch?

 Or there might be some even better way to make this decision.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26334 [Core Tor/Tor]: Investigate how much our CI performance would improve (if at all) with paid builders

[Tor Bug Tracker & Wiki]

#26334: Investigate how much our CI performance would improve (if at all) with 
paid
builders
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci from-retrospective
Actual Points:|  Parent ID:  #25550
   Points:|   Reviewer:
  Sponsor:|
--+---


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26333 [Core Tor/Tor]: Write trac templates for bug reports / other tickets, and link them from somewher useful

[Tor Bug Tracker & Wiki]

#26333: Write trac templates for bug reports / other tickets, and link them from
somewher useful
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  from-retrospective
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It would be awesome if we could have templates for opening better trac
 tickets, in a way to actually help people include all the necessary info
 and not have a hard time figure out what they're supposed to say.

 This might be an "internal services" ticket, but before we can get it
 there, we need to figure out what we actually want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26332 [Core Tor/Tor]: Write up ticket triage process as algorithm or flowchart

[Tor Bug Tracker & Wiki]

#26332: Write up ticket triage process as algorithm or flowchart
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  from-retrospective
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  from-retrospective  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * keywords:   => from-retrospective


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26331 [Core Tor/Tor]: Make queries to help with Tor rotations

[Tor Bug Tracker & Wiki]

#26331: Make queries to help with Tor rotations
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Various of our rotations -- especially bug triage -- would benefit from
 saved queries.  We should add those, either as stored queries or links
 from one of our wiki pages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26330 [Internal Services]: We could use an IRC bot to interact with our "/me status:" messages

[Tor Bug Tracker & Wiki]

#26330: We could use an IRC bot to interact with our "/me status:" messages
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 In the network team, we've started using IRC messages of the form `/me
 status: opening a bunch of tickets` to keep trac of what we're doing day
 to day.  It would be cool to have something to keep track of them for us.

 It would be best if this were done on an opt-in basis: nobody should have
 their IRC logged without their consent.

 It might be nice to have some feature to remind you to do this if you
 haven't done so on a regular day, but that could easily become obnoxious.

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

Re: [tor-bugs] #22788 [Applications/Tor Browser]: PDF.js overloads CPU when opening large PDFs on higher security slider levels

[Tor Bug Tracker & Wiki]

#22788: PDF.js overloads CPU when opening large PDFs on higher security slider
levels
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Because of a recent change (where loading the PDF happens only after it is
 completely downloaded) it would be really awesome to have this solved to
 compensate a bit for the damage from the aforementioned patch (at least
 while using the Safer-Safest security settings).

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

Re: [tor-bugs] #24145 [Core Tor/Tor]: Tor Browser crash on Windows 7

[Tor Bug Tracker & Wiki]

#24145: Tor Browser crash on Windows 7
--+--
 Reporter:  P0k0l3s   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Critical  | Resolution:
 Keywords:  Tor, Crash, APPCRASH  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 I suggest closing, since it's been seven months, and maybe it was a bug
 with mingw, or maybe it was antivirus, but that version of Tor (whatever
 it was) is no longer the latest version of 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] #26326 [Applications/Tor Browser]: wine error when building Firefox ESR60 Windows x86_64

[Tor Bug Tracker & Wiki]

#26326: wine error when building Firefox ESR60 Windows x86_64
+--
 Reporter:  sukhbir |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sukhbir):

 Furthermore:

 {{{
  5:08.66 /var/tmp/build/firefox-30544586f8a9/obj-mingw/mozilla-
 config.h:33:0: note: this is the location of the previous definition
  5:08.66  #define HAVE_PTHREAD_H 1
  5:08.66
  5:08.67 In file included from /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/generic/systemdependent.c:16:0:
  5:08.67 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vpx_ports/x86.h:113:1: error: multiple
 storage classes in declaration specifiers
  5:08.67  static INLINE uint64_t xgetbv(void) {
  5:08.67  ^~
  5:08.67 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vpx_ports/x86.h:166:1: error: multiple
 storage classes in declaration specifiers
  5:08.67  static INLINE int x86_simd_caps(void) {
  5:08.67  ^~
  5:08.67 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vpx_ports/x86.h:224:1: error: multiple
 storage classes in declaration specifiers
  5:08.67  static INLINE unsigned int x86_readtsc(void) {
  5:08.67  ^~
  5:08.67 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vpx_ports/x86.h:242:1: error: multiple
 storage classes in declaration specifiers
  5:08.67  static INLINE uint64_t x86_readtsc64(void) {
  5:08.67  ^~
  5:08.67 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vpx_ports/x86.h:307:1: error: multiple
 storage classes in declaration specifiers
  5:08.67  static INLINE unsigned int x87_set_double_precision(void) {
  5:08.67  ^~
  5:08.70 /var/tmp/build/firefox-30544586f8a9/config/rules.mk:773: recipe
 for target 'systemdependent.o' failed
  5:08.70 make[4]: *** [systemdependent.o] Error 1
  5:08.70 /var/tmp/build/firefox-30544586f8a9/config/recurse.mk:73: recipe
 for target 'media/libvpx/target' failed
  5:08.70 make[3]: *** [media/libvpx/target] Error 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] #26043 [Obfuscation/Snowflake]: building snowflake into a bundle of pluggable transports

[Tor Bug Tracker & Wiki]

#26043: building snowflake into a bundle of pluggable transports
---+-
 Reporter:  hans   |  Owner:  (none)
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by arlolra):

 * status:  needs_review => merge_ready


Comment:

 Probably `25b304a`

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

Re: [tor-bugs] #26326 [Applications/Tor Browser]: wine error when building Firefox ESR60 Windows x86_64

[Tor Bug Tracker & Wiki]

#26326: wine error when building Firefox ESR60 Windows x86_64
+--
 Reporter:  sukhbir |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sukhbir):

 OK `xvfb` is done though I am not happy with it but that's for later. The
 next error:

 {{{
  4:55.01 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:24:1: error:
 multiple storage classes in declaration specifiers
  4:55.01  static INLINE void mv_bias(int refmb_ref_frame_sign_bias, int
 refframe,
  4:55.01  ^~
  4:55.01 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:34:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE void vp8_clamp_mv2(int_mv *mv, const MACROBLOCKD
 *xd) {
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:48:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE void vp8_clamp_mv(int_mv *mv, int mb_to_left_edge,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:60:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE unsigned int vp8_check_mv_bounds(int_mv *mv, int
 mb_to_left_edge,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:86:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE uint32_t left_block_mv(const MODE_INFO *cur_mb,
 int b) {
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:98:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE uint32_t above_block_mv(const MODE_INFO *cur_mb,
 int b,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:110:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE B_PREDICTION_MODE left_block_mode(const MODE_INFO
 *cur_mb,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:128:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE B_PREDICTION_MODE above_block_mode(const MODE_INFO
 *cur_mb, int b,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-30544586f8a9/config/rules.mk:773: recipe
 for target 'alloccommon.o' failed
  4:55.02  static INLINE B_PREDICTION_MODE left_block_mode(const MODE_INFO
 *cur_mb,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-
 30544586f8a9/media/libvpx/libvpx/vp8/common/findnearmv.h:128:1: error:
 multiple storage classes in declaration specifiers
  4:55.02  static INLINE B_PREDICTION_MODE above_block_mode(const MODE_INFO
 *cur_mb, int b,
  4:55.02  ^~
  4:55.02 /var/tmp/build/firefox-30544586f8a9/config/rules.mk:773: recipe
 for target 'alloccommon.o' failed
  4:55.02 make[4]: *** [alloccommon.o] Error 1
  4:55.02 /var/tmp/build/firefox-30544586f8a9/config/recurse.mk:73: recipe
 for target 'media/libvpx/target' failed
  4:55.02 make[3]: *** [media/libvpx/target] Error 2
  4:55.02 make[3]: *** Waiting for unfinished jobs
 }}}

 This is probably related to
 https://bugzilla.mozilla.org/show_bug.cgi?id=1378529

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Left some comments in the branch. Neel, next revision, you might want to
 do a PR instead so it get checked automatically by our CI :). 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] #21346 [Core Tor/Tor]: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits

[Tor Bug Tracker & Wiki]

#21346: Clients with NoIPv4Traffic should only choose IPv6-supporting Exits
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425, |  Actual Points:
  032-unreached  |
Parent ID:  #21311   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Thanks neel for you patch!

 So it took me a while to wrap my head around your fix and the current
 behavior. I do understand that we need to pick an Exit node that matches
 our IP criteria so that `connection_ap_get_begincell_flags()` doesn't get
 confused.

 The `connection_ap_can_use_exit()` is the right place to look for the
 SocksPort flags vs the Exit policy but it appears it *is* doing the right
 thing already with selecting the address family and then using
 `compare_tor_addr_to_node_policy()` to keep the chosen exit node or not.

 Seems to me your patch that adds `node_policy_is_general_exit()` is doing
 roughly the same thing but only for port 80/443 (general exit policy). Can
 you enlighten me on how it is different or fixes things.

 I'm asking here because there are two issues. The first one is that it is
 unclear _why_ your code does what it does and second it duplicates most of
 its code from other functions which in turn turns out to be mostly what
 `compare_tor_addr_to_node_policy()` does...

 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] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:71 pospeselr]:
 > Turns out localization here was way simpler than what Arthur had to do
 for his patch.  We can simply stick the strings in torbutton.properties,
 which is the same format as where I had them before, just in separate file
 that we control.

 What happens if Torbutton is uninstalled? For #14631, we added English
 strings to the browser but wrote code to retrieve the strings from
 Torbutton if available. We probably want to implement a similar fallback
 scheme for this ticket. See these commits on the tor-
 browser-60.0.1esr-8.0-1 branch:
  10ac5a7be31f6310a3a0dea6565e3ee1982c602e
  b6d8bf568ba67c55a42b6b057d6e9bba12e413d0

 > I've also attached a patch for torbutton which adds the new strings (in
 English) to all of our locales for future translation.

 gk can confirm, but I think it is better to only add the strings to the
 en-US locale. The process of updating the strings from Transifex (which gk
 always does before making a new release of Torbutton) should take care of
 filling in missing strings with the en-US ones if they are not yet
 translated.

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

Re: [tor-bugs] #26259 [Core Tor/Tor]: Don't count 0-length RELAY_DATA cell as valid

[Tor Bug Tracker & Wiki]

#26259: Don't count 0-length RELAY_DATA cell as valid
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay-layer, tor-metrics, tor-   |  Actual Points:
  circuit|
Parent ID:   | Points:  1
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #26259 [Core Tor/Tor]: Don't count 0-length RELAY_DATA cell as valid

[Tor Bug Tracker & Wiki]

#26259: Don't count 0-length RELAY_DATA cell as valid
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay-layer, tor-metrics, tor-   |  Actual Points:
  circuit|
Parent ID:   | Points:  1
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 Replying to [comment:5 isis]:
 > Replying to [comment:3 mikeperry]:
 > > Possibly. Do we feel comfortable forbidding these cells completely in
 0.3.4.x? I would prefer to have this branch merged into 0.3.4, since it is
 just a control port field accounting fix.
 > >
 > > If we're nervous about actually closing the circuit right away in
 these instances, then we should make a different ticket + different patch
 for that change.
 >
 > Different ticket and patch please! This one is clearly a bug;
 disallowing 0-length data cells entirely seems more contentious, possible
 requires a spec change, and has a higher possibility of breaking things.

 +1 on a different ticket and patch; and if we do it, we need to figure out
 how we're handling the fingerprinting issue.

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

Re: [tor-bugs] #26284 [Core Tor/Tor]: Out-of-bounds smartlist access in protover_compute_vote()

[Tor Bug Tracker & Wiki]

#26284: Out-of-bounds smartlist access in protover_compute_vote()
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #26196| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.2.9.x-final


Comment:

 Cherry-picked to 0.2.9, and merged forward!

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

Re: [tor-bugs] #25637 [Webpages/Website]: sitemap for torproject.org

[Tor Bug Tracker & Wiki]

#25637: sitemap for torproject.org
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24131| Points:
 Reviewer:|Sponsor:  Sponsor9
--+--
Changes (by isabela):

 * 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] #26270 [Core Tor/Tor]: Move dirauth module code from src/or/dirauth to src/dirauth

[Tor Bug Tracker & Wiki]

#26270: Move dirauth module code from src/or/dirauth to src/dirauth
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, modularization, |  Actual Points:
  refactor   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * keywords:   => tor-dirauth, modularization, refactor
 * cc: dgoulet (removed)
 * status:  needs_review => merge_ready


Comment:

 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] #26214 [Core Tor/Tor]: Check stream SENDME against max

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision
 * keywords:   => tor-circuit, tor-cell


Comment:

 Quick question in the review. If you think it is OK, I would be for an
 extra comment that says why it is OK since this is a bit confusing.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:26 antonela]:
 > Also, current `about:preferences` at FF60 doesn't have a [SAVE] button
 to confirm the action. Do you think we need to add an intermediate step
 for users to verify their radio option pick? May we need it for anything
 else?
 Isn't it possible to emulate the current Torbutton behavior by launching a
 popup window instead of opening a new tab with `about:preferences` (and
 therefore exposing those other options that users shouldn't change to
 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] #26327 [Core Tor/Tor]: Add Vagrant configurations for multiple different systems to contrib

[Tor Bug Tracker & Wiki]

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

Comment (by jonah):

 good

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by dgoulet):

 Replying to [comment:24 asn]:
 > Hm, I guess the HS-client example above is indeed a plausible (but
 unlikely) edge-case. It's worth noting that the example you cited above
 applies only to the HS client case, whereas I think we covered it for HS
 services since services basically function based on those callbacks. Of
 course, there might be other cases around the codebase, which we are not
 aware of right now ("if a tree falls in a forest and no one is around to
 hear it...").

 Yes my worry is mostly about other possible issues this affect. And making
 it a special case for the hs service callback to recalculate seems the
 wrong approach...

 > a) Fix all the cases by recomputing data immediately when a clock jump
 is noticed (as per my first branch). This has the negative effect of
 giving variable time duration to the callback as Nick pointed out.
 > b) Fix the HS client edge-case dgoulet pointed out, by calling
 `recalculate_consensus_data_callback()` when an HS client tries to connect
 to an HS.
 > c) Merge Nick's branch and leave the edge-cases open. In the future, we
 can fix those too as we understand more things about this problem.
 > d) Do more research, try to understand the problem more, and figure out
 an even better solution if possible...

 Not the easiest call here but I think (a) is what needs to be done even
 though I don't like much doing extra work in the update time
 callback...

 The reason is that (b) is *one* possible issue among possibly other.
 Special cases where we directly call the callback makes me think we are
 piling up on the house of cards. The problem with (c) now is that this
 issue is something that took us quite a bit of time to finally find and I
 bet if something outside of the HS subsystem is affected by this, it will
 be hard as well to find out. And (d), I doubt it is needed, we have a good
 grasp on the problem imo.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by antonela):

 Hi! Based on latest comments, I updated the UI

 https://trac.torproject.org/projects/tor/attachment/ticket/25658/TBB8-UI-
 Security-Settings.png

 I also made a prototype -> https://marvelapp.com/383eaa9/screen/44007368

 I used Photon for the settings UI ->
 https://design.firefox.com/photon/components/radio-buttons.html

 We still need to work on informing users that NoScript and HTTSEverywhere
 icons are available to be placed at the Top Nav via Menu/Customize. We
 could include a step/card explaining it at the new onboarding.

 Also, current `about:preferences` at FF60 doesn't have a [SAVE] button to
 confirm the action. Do you think we need to add an intermediate step for
 users to verify their radio option pick? May we need it for anything else?

 I think we are pretty close to moving this forward. Am I missing anything
 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] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+-
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  invalid
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by asn):

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


Comment:

 This is not how a bug tracker works.

 If you find out a bug, please let us 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] #25477 [Core Tor/Tor]: Stop warning users about bug #21018

[Tor Bug Tracker & Wiki]

#25477: Stop warning users about bug #21018
-+-
 Reporter:  asn  |  Owner:  rl1987
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 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] #26284 [Core Tor/Tor]: Out-of-bounds smartlist access in protover_compute_vote()

[Tor Bug Tracker & Wiki]

#26284: Out-of-bounds smartlist access in protover_compute_vote()
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #26196| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by asn):

 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] #8323 [Core Tor/Tor]: Missing 'GETINFO md/all'

[Tor Bug Tracker & Wiki]

#8323: Missing 'GETINFO md/all'
--+
 Reporter:  atagar|  Owner:  rl1987
 Type:  enhancement   | Status:
  |  merge_ready
 Priority:  High  |  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client tor-control microdesc  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 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] #26329 [Applications/Tor Browser]: Rust invocation for Firefox on 32bit Windows is failing

[Tor Bug Tracker & Wiki]

#26329: Rust invocation for Firefox on 32bit Windows is failing
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Okay, let's go with plan d): Alex Crichton pointed me to
 https://github.com/rust-lang/rust/pull/49633 a while ago as a potential
 stopgap solution. It turns out that one works in the sense that 32bit tor
 for Windows with Rust enabled is still compiling and running AND that I am
 now hitting #26326.

 I'll post a proper patch for this bug once I can verify that Tor Browser
 properly compiles and runs.

 If that still hits some problems we could think about plan e) to ditch
 SjLj exception handling for 32bit Windows in favor of Dwarf2 or we could
 think about resorting to the official std lib for the time being.

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

Re: [tor-bugs] #26284 [Core Tor/Tor]: Out-of-bounds smartlist access in protover_compute_vote()

[Tor Bug Tracker & Wiki]

#26284: Out-of-bounds smartlist access in protover_compute_vote()
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #26196| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by rl1987):

 * status:  needs_revision => merge_ready


Comment:

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

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

Re: [tor-bugs] #8323 [Core Tor/Tor]: Missing 'GETINFO md/all'

[Tor Bug Tracker & Wiki]

#8323: Missing 'GETINFO md/all'
--+
 Reporter:  atagar|  Owner:  rl1987
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  High  |  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client tor-control microdesc  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by rl1987):

 Squashed the branch again: https://github.com/torproject/tor/pull/137

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

Re: [tor-bugs] #26211 [Core Tor/Tor]: torspec update for GETINFO md/all

[Tor Bug Tracker & Wiki]

#26211: torspec update for GETINFO md/all
--+
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client tor-control microdesc  |  Actual Points:
Parent ID:  #8323 | Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM. We should fixup the XXX after we merge #8323.

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

Re: [tor-bugs] #26284 [Core Tor/Tor]: Out-of-bounds smartlist access in protover_compute_vote()

[Tor Bug Tracker & Wiki]

#26284: Out-of-bounds smartlist access in protover_compute_vote()
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #26196| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by asn):

 Fixups LGTM.

 Please squash the branch so that it's just one commit.

 Also please consider adding some curly braces in this if clause:
 {{{
 +  if (smartlist_len(list_of_proto_strings) == 0)
 +return tor_strdup("");
 }}}
 IMO, we should be adding curly braces even in trivial if statements to
 avoid potential Apple `goto fail` issues ;)

 After you do so, feel free to turn it into merge_ready.

 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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

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

 * Attachment "TBB8-UI-Security-Settings.png" added.


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

Re: [tor-bugs] #26028 [Applications/Tor Browser]: HLS Player doesn't use the centralized Proxy Selector.

[Tor Bug Tracker & Wiki]

#26028: HLS Player doesn't use the centralized Proxy Selector.
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #21863| Points:
 Reviewer:|Sponsor:
--+--

Comment (by igt0):

 Merged: https://hg.mozilla.org/mozilla-central/rev/b75e6bb295a9

 It will be available in Firefox 62. So we will need to backport to FF61.

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

Re: [tor-bugs] #8323 [Core Tor/Tor]: Missing 'GETINFO md/all'

[Tor Bug Tracker & Wiki]

#8323: Missing 'GETINFO md/all'
--+
 Reporter:  atagar|  Owner:  rl1987
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  High  |  Milestone:  Tor:
  |  0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client tor-control microdesc  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 Fixed the code to use existing function and wrote unit tests.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26329 [Applications/Tor Browser]: Rust invocation for Firefox on 32bit Windows is failing

[Tor Bug Tracker & Wiki]

#26329: Rust invocation for Firefox on 32bit Windows is failing
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:  #26203
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Firefox's configure is failing when checking for a functional `rustc` with
 {{{
  0:32.86 DEBUG: Executing: `/var/tmp/dist/rust/bin/rustc --crate-type
 staticlib --target=i686-pc-windows-gnu -o /tmp/conftest66YTEr.rlib
 /tmp/conftestkSgS7j.rs`
  0:32.86 DEBUG: The command returned non-zero exit status 101.
  0:32.86 DEBUG: Its error output was:
  0:32.86 DEBUG: | error: the crate `panic_unwind` does not have the panic
 strategy `unwind`
  0:32.86 DEBUG: |
  0:32.86 DEBUG: | error: aborting due to previous error
  0:32.86 DEBUG: |
  0:32.86 ERROR: Cannot compile for i686-w64-mingw32 with
 /var/tmp/dist/rust/bin/rustc
 }}}

 Firefox is getting compiled with `panic=abort` (https://dxr.mozilla.org
 /mozilla-central/source/testing/geckodriver/.cargo/config) for 32bit
 Windows and we intend to create a Rustc compiler with that panic strategy
 as well, given that cross-compiling with `panic=unwind` is not working
 (see: comment:1:ticket:25894).

 While compiling every crate in the std lib with `panic-abort` is working
 it seems we still miss some crucial bit here.

 One option to test would be if we can get rid of `panic_unwind` if we
 don't need it anyway when compiling for 32bit Windows. For what it is
 worth, the compiler as we have it right now is working for `tor` compiled
 with Rust.

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

Re: [tor-bugs] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |
---+--

Comment (by cypherpunks):

 I don't know the website in question; can anyone share its onion domain?
 If it is V2 (not V3), then we should deprecate V2 fast.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26328 [Webpages/Blog]: [EMERG] Tor Hidden Service owner is identified and caught by police, how?

[Tor Bug Tracker & Wiki]

#26328: [EMERG] Tor Hidden Service owner is identified and caught by police, 
how?
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
---+--
 https://www.sankei.com/west/news/180605/wst1806050108-n1.html
 https://www.nikkei.com/article/DGXMZO31414120V00C18A6AC8000/
 https://mainichi.jp/articles/20180606/ddn/041/040/046000c

 I think you need to write a blog soon.

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

Re: [tor-bugs] #26326 [Applications/Tor Browser]: wine error when building Firefox ESR60 Windows x86_64

[Tor Bug Tracker & Wiki]

#26326: wine error when building Firefox ESR60 Windows x86_64
+--
 Reporter:  sukhbir |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  #26203  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_information => new


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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  vagrant dev-tools compilation => vagrant dev-tools compilation
 easy


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26327 [Core Tor/Tor]: Add Vagrant configurations for multiple different systems to contrib

[Tor Bug Tracker & Wiki]

#26327: Add Vagrant configurations for multiple different systems to contrib
--+---
 Reporter:  rl1987|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor |   Keywords:  vagrant dev-tools compilation
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Vagrant can enable us to have pre-configured VM blueprints with Tor
 development environment that developers could easily instantiate on their
 local machines.

 We should have Vagrantfiles for:

 * Linux (at least Debian, maybe some more).
 * FreeBSD
 * OpenBSD
 * NetBSD
 * Windows 10 (stretch goal)
 * Android-x86 (stretch goal)

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

Re: [tor-bugs] #26284 [Core Tor/Tor]: Out-of-bounds smartlist access in protover_compute_vote()

[Tor Bug Tracker & Wiki]

#26284: Out-of-bounds smartlist access in protover_compute_vote()
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #26196| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by rl1987):

 This bug emerged when I was working on #26196. The simplest way to
 reproduce is to add `#define DEBUG_SMARTLIST` to orconfig.h, recompile and
 run `make test`. There are several unit tests that crash in
 `protover_compute_vote()`.

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