Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:  kaie
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,  |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,|
  tor-03-unspecified-201612  |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-

Comment (by kaie):

 What do you think about the following alternative approach, which would
 make it unnecessary to improve the internals of transport plugins?

 - allow tor to spawn multiple instances per transport type
 - introduce some sort of aliasing, which allows the use separate transport
 configuration lines,
   where each use a separate alias name as the key

 For example:

 #aliastransport-to-execute
 ServerTransportAlias second-obfs4 obfs4
 ServerTransportAlias third-obfs4  obfs4

 ServerTransportListenAddr obfs41.2.3.4:443
 ServerTransportListenAddr second-obfs4 2.3.4.5:443
 ServerTransportListenAddr third-obfs4  [2001::2:3:4]:443

 ServerTransportOptions obfs4"abc"
 ServerTransportOptions second-obfs4 "def"
 ServerTransportOptions third-obfs4  "ghi"

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

Re: [tor-bugs] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automatically update in the background

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not  automatically update in 
the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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 Dbryrtfbcbhgf):

 Replying to [comment:4 yawning]:
 > Replying to [comment:2 Dbryrtfbcbhgf]:
 > >  But the add-ons are set to update automatically from
 addons.mozilla.org servers when a new version of the add on is released to
 the public.
 >
 > I know, and I think that's wrong, and I specified what I think what the
 behavior should be changed to, at least for HTTPS-E and NoScript.  I'm not
 sure about what behavior for random other things users decide to install
 should be, in general I think they have other more fundemental problems
 than the updater when they do that...
 >
 > Coincidentally, the Linux sandbox disables the addon updater by default.
 Will future versions of tor browser have automatic updates disabled for
 every add-on  including HTTPS-E and NoScript?

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

Re: [tor-bugs] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 >  Noto emoji (black and white) seems to not have its source code online
 unfortunately.

 `NotoEmoji-Regular.ttf` is bundled with 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] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automatically update in the background

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not  automatically update in 
the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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):

 Replying to [comment:2 Dbryrtfbcbhgf]:
 >  But the add-ons are set to update automatically from addons.mozilla.org
 servers when a new version of the add on is released to the public.

 I know, and I think that's wrong, and I specified what I think what the
 behavior should be changed to, at least for HTTPS-E and NoScript.  I'm not
 sure about what behavior for random other things users decide to install
 should be, in general I think they have other more fundemental problems
 than the updater when they do that...

 Coincidentally, the Linux sandbox disables the addon updater by 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] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042
 RFP: fonts-noto-emoji -- "No Tofu" emoji font

 Noto color emoji seems like it is being packages in Debian.

 Might be a good TBB whitelisted font when it is released.

 Noto emoji (black and white) seems to not have its source code online
 unfortunately.

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

Re: [tor-bugs] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automatically update in the background (was: Tor browser should be set so add-ons will not automaton upd

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not  automatically update in 
the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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:
--+--

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

Re: [tor-bugs] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automaton update in the background

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not automaton update in the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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 Dbryrtfbcbhgf):

 Replying to [comment:1 yawning]:
 > Related/dup of #10394
 >
 > I personally think that all the addons shipped with Tor Browser should
 only be updated by Tor Browser.

  But the add-ons are set to update automatically from addons.mozilla.org
 servers when the new version of the add on is released to the public.

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

Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:  kaie
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,  |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,|
  tor-03-unspecified-201612  |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-

Comment (by yawning):

 Replying to [comment:22 dcf]:
 > This is a good idea, but I think it's more complicated than just giving
 a list to ServerTransportListenAddr. You would need to also make
 ServerTransportOptions be similarly split, which would probably require
 new syntax in torrc. It would also require a change to pt-spec, because
 there would need to be a rule or something that states which options
 pertain to which listening address when there are multiple ones.

 obfs4proxy would require fairly substantial changes to handle this
 correctly, as would core tor and probably the bridge distribution stuff.
 So while it's a good idea, getting it to bind to addresses is just the
 start, and even that needs to be preceded by a spec change so that code
 that supports this use case will work, and that code that doesn't will
 error out per the existing spec.

 > I've been frustrated by this in the past, too. For example, in
 comment:10:ticket:20348, I wanted to run three obfs4 bridges with slightly
 different configuration on the same IP address, and there's just no way to
 do it other than to run three instances of tor. It was probably a mistake
 for torrc to use the transport name as a key that links
 ServerTransportListenAddr and ServerTransportOptions, because that makes a
 built-in assumption that there's only one thing identified by that
 transport.

 Lots of aspects of the design aren't great.

 > Incidentally, it might be the the case that using only the IPv6 syntax
 already does what you want. On some systems `[::]` will listen on both
 IPv6 and IPv4, so you don't need to separately list 0.0.0.0.

 That's a general Linux-ism.  Only one address will be distributed via
 BridgeDB though (fairly sure it's the IPv4 one).

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

Re: [tor-bugs] #21261 [Obfuscation/Pluggable transport]: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.

[Tor Bug Tracker & Wiki]

#21261: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.
-+-
 Reporter:  yawning  |  Owner:  asn
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * status:  needs_review => merge_ready


Comment:

 Yeah that's basically how I would have done it.  I think we shouldn't
 worry about de-duplication for now (just erroring out should be fine).
 I'd have to check if the tor code actually can even set such things.

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

Re: [tor-bugs] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 Maybe we should make specific font recommendations at this ticket in order
 to try to get support for emojis and dingbats:
 https://trac.torproject.org/projects/tor/ticket/20842

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

Re: [tor-bugs] #21257 [Obfuscation/meek]: meek-azure broken

[Tor Bug Tracker & Wiki]

#21257: meek-azure broken
--+-
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * owner:   => dcf
 * component:  - Select a component => Obfuscation/meek


Comment:

 It may be because the public meek-azure server is extremely overloaded.
 There are more users trying to use it than it can support.

 You may have better luck setting up your own App Engine instance and using
 that instead. It will go instead to an unthrottled bridge.
 https://lists.torproject.org/pipermail/tor-talk/2016-June/041699.html

 meek-azure might be going away soon anyway, because we don't have a way to
 pay for it.
 https://lists.torproject.org/pipermail/tor-
 project/2017-January/000881.html

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

Re: [tor-bugs] #21258 [Obfuscation/meek]: meek PT stops functioning after long uptime

[Tor Bug Tracker & Wiki]

#21258: meek PT stops functioning after long uptime
--+-
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * owner:   => dcf
 * component:  - Select a component => Obfuscation/meek


Comment:

 Does it also fail after a long uptime when using other pluggable
 transports or with vanilla 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] #21136 [Obfuscation/Obfsproxy]: obfs4proxy doesn't listen on both 0.0.0.0 and [::]

[Tor Bug Tracker & Wiki]

#21136: obfs4proxy doesn't listen on both 0.0.0.0 and [::]
---+-
 Reporter:  kaie   |  Owner:  kaie
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by dcf):

 Replying to [comment:6 yawning]:
 >  * How `TOR_PT_SERVER_TRANSPORT_OPTIONS` should be handled is unclear.
 The way goptlib is implemented now, it only supports a single set of
 arguments per transport, which is likely incorrect.

 What do you mean by this? I don't see how
 `TOR_PT_SERVER_TRANSPORT_OPTIONS` could be split into more than one set of
 arguments for each transport. Each key=value pair is tagged with the name
 of the transport it belongs to, with no other distinguishing information.
 The example from the spec is
 {{{
 
TOR_PT_SERVER_TRANSPORT_OPTIONS=scramblesuit:key=banana;automata:rule=110;automata:depth=3
 }}}

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

Re: [tor-bugs] #21261 [Obfuscation/Pluggable transport]: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.

[Tor Bug Tracker & Wiki]

#21261: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.
-+-
 Reporter:  yawning  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Is this what you have in mind? attachment:0001-Bug-21261-forbid-duplicate-
 method-names-in-TOR_PT_SE.patch

 I added a test case for when there is an exact duplicate of a
 transport—address pair. What should we do in this case? The patch treats
 it as an ENV-ERROR. The alternative is to collapse exact duplicates
 together. It depends on what the spec intends by "more than one pair."
 {{{
 TOR_PT_SERVER_BINDADDR=alpha-0.0.0.0:1234,alpha-0.0.0.0:1234
 }}}

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

Re: [tor-bugs] #20842 [User Experience]: Proposal: Improve Tor Browser font whitelist / bundled fonts

[Tor Bug Tracker & Wiki]

#20842: Proposal: Improve Tor Browser font whitelist / bundled fonts
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 I'm interested in seeing some better unicode support for dingbats in Linux
 TBB.

 Simple things like the pencil doesn't work on TBB on Linux:
 ​https://www.fileformat.info/info/unicode/char/270E/browsertest.htm

 This is Unicode version 1.1.0 released in June, 1993.
 https://www.fileformat.info/info/unicode/char/270e/index.htm It probably
 should be supported in TBB.

 In TBB on Windows, the pencil works via Micro$oft's copyrighted MS PGothic
 (which Linux can't use) but it doesn't look very pretty at all.

 Also, black flag dingbats don't seem to work on TBB on either Windows or
 Linux: ​https://www.fileformat.info/info/unicode/char/2691/browsertest.htm
 This came out in Unicode 4, which was released 14 years ago.

 The Up Down Arrow does work on Linux:
 ​https://www.fileformat.info/info/unicode/char/2195/browsertest.htm

 Also, a regular multiplication sign works
 ​https://www.fileformat.info/info/unicode/char/00D7/browsertest.htm but a
 "MULTIPLICATION X" does not.
 ​https://www.fileformat.info/info/unicode/char/2715/browsertest.htm
 Multiplication X is also Unicode 1.1 which is 24 years old.

 When surfing the web, it isn't unusual to come across some of these and it
 looks silly when they don't render.

 I got these example errors while trying to figure out what was going on
 with fed.wiki.org and ended up writing a github issue about it, only to
 close it after I found out that it was a Tor Browser bug:
 https://github.com/fedwiki/wiki/issues/97

 Some people also were talking in this issue about emojis not working:
 https://trac.torproject.org/projects/tor/ticket/18172

 Is https://www.google.com/get/noto/#emoji-zsye a possible solution to
 this? I'm not seeing a debian package for 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] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:  kaie
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,  |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,|
  tor-03-unspecified-201612  |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-

Comment (by dcf):

 Replying to [comment:10 kaie]:
 > I'm trying to contribute a fix for this issue.
 >
 > Would it be acceptable to use a different configuration syntax, that
 uses only a single line for each transport type, and allows multiple
 address:port combinations to be listed on the line, separated by space, as
 in the following example?
 >
 >   ServerTransportListenAddr obfs3 0.0.0.0:443 [::]:443

 This is a good idea, but I think it's more complicated than just giving a
 list to ServerTransportListenAddr. You would need to also make
 ServerTransportOptions be similarly split, which would probably require
 new syntax in torrc. It would also require a change to pt-spec, because
 there would need to be a rule or something that states which options
 pertain to which listening address when there are multiple ones.

 I've been frustrated by this in the past, too. For example, in
 comment:10:ticket:20348, I wanted to run three obfs4 bridges with slightly
 different configuration on the same IP address, and there's just no way to
 do it other than to run three instances of tor. It was probably a mistake
 for torrc to use the transport name as a key that links
 ServerTransportListenAddr and ServerTransportOptions, because that makes a
 built-in assumption that there's only one thing identified by that
 transport.

 Incidentally, it might be the the case that using only the IPv6 syntax
 already does what you want. On some systems `[::]` will listen on both
 IPv6 and IPv4, so you don't need to separately list 0.0.0.0.

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

Re: [tor-bugs] #21224 [Applications/Tor Browser]: Youtube fullscreen errorr in TBB fullscreen mode on MacOS 10.12

[Tor Bug Tracker & Wiki]

#21224: Youtube fullscreen errorr in TBB fullscreen mode on MacOS 10.12
-+-
 Reporter:  exatto   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201701, tbb-usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I have found a solution for this, but it's going to require careful
 testing on all platforms. I expect it will take me at least another day.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21261 [Obfuscation/Pluggable transport]: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.

[Tor Bug Tracker & Wiki]

#21261: goptlib should enforce the `TOR_PT_SERVER_BINDADDR` restriction.
-+-
 Reporter:  yawning  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   |   Keywords:  goptlib
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Followup from #21136.

 `TOR_PT_SERVER_BINDADDR` by spec is limited to one address+port per
 transport.  goptlib should enforce this, and raise an `ENV-ERROR` if
 anyone tries to specify more than one.

 I could add code in obfs4proxy to check for this, but it's a spec
 restriction, so goptlib doing the enforcement seems more appropriate.

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

Re: [tor-bugs] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automaton update in the background

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not automaton update in the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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):

 Related/dup of #10394

 I personally think that all the addons shipped with Tor Browser should
 only be updated by 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

[tor-bugs] #21260 [Applications/Tor Browser]: Tor browser should be set so add-ons will not automaton update in the background

[Tor Bug Tracker & Wiki]

#21260: Tor browser should be set so add-ons will not automaton update in the
background
--+--
 Reporter:  Dbryrtfbcbhgf |  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:|
--+--
 If a company that develops a add-on gets compromised, they could released
 a Malicious update for there extension and all users running tor browser
 would get the new malicious update that could compermise there
 Anonymity, the users would not even know that the Malicious add-on would
 be installed  "ex. HTTPS Everywhere"

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

Re: [tor-bugs] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 I should state, not every dingbat is broken in the Linux TBB. The Up Down
 Arrow works:
 https://www.fileformat.info/info/unicode/char/2195/browsertest.htm

 Also, a regular multiplication sign works
 https://www.fileformat.info/info/unicode/char/00D7/browsertest.htm but a
 "MULTIPLICATION X" does not
 https://www.fileformat.info/info/unicode/char/2715/browsertest.htm

 I'm not sure which whitelisted font allows some of these to work.

 It might be good to find a good font candidate to whitelist in the Linux
 and Windows TBB to allow it to render more unicode characters than the
 current fonts allow. I haven't done any tests on the Mac TBB.

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

Re: [tor-bugs] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 My issue has to do with dingbats, not emojis. Should I create a new ticket
 about this or does it make sense to tackle it here?

 As an example:

 Simple things like the pencil doesn't work on TBB on Linux:
 https://www.fileformat.info/info/unicode/char/270E/browsertest.htm

 In TBB on Windows, the pencil works via Micro$oft's copyrighted MS PGothic
 (which Linux can't use) but it doesn't look very good.

 Oh, and a simple X works in TBB Windows but not TBB Linux:
 https://www.fileformat.info/info/unicode/char/2715/browsertest.htm

 Also, black flag dingbats don't seem to work on TBB on either Windows or
 Linux: https://www.fileformat.info/info/unicode/char/2691/browsertest.htm

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

Re: [tor-bugs] #21259 [Core Tor/Tor]: Remove extra newline from proxy_prepare_for_restart definition

[Tor Bug Tracker & Wiki]

#21259: Remove extra newline from proxy_prepare_for_restart definition
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.1-alpha
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


Comment:

 Please see my github branch bug21259.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21259 [Core Tor/Tor]: Remove extra newline from proxy_prepare_for_restart definition

[Tor Bug Tracker & Wiki]

#21259: Remove extra newline from proxy_prepare_for_restart definition
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.1-alpha
 Severity:  Trivial   |   Keywords:
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 For bonus points, we could modify make check-spaces to detect these kinds
 of errors. (I stared at the function header part of checkSpace.pl for a
 few minutes, then gave up.)

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

[tor-bugs] #21258 [- Select a component]: meek PT stops functioning after long uptime

[Tor Bug Tracker & Wiki]

#21258: meek PT stops functioning after long uptime
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Running TorBrowser on macOS with meek PT fails after long uptime.

 Scenarios:

 1) Run machine for a day or more, then try to open torbrowser and connect,
 and it fails.

 2) Boot machine, use torbrowser successfully for a period, quit and then
 leave machine running for an extended period (a day at least) and then try
 to reopen torbrowser and connect -> fails to connect.

 Interestingly, and for unknown reasons, adding the log options to meek-
 client and meek-client-torbrowser in torrc avoids this bug. Any thoughts?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21257 [- Select a component]: meek-azure broken

[Tor Bug Tracker & Wiki]

#21257: meek-azure broken
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 meek is the only option in my threat model. Noticed that azure server
 almost always fails to connect (tested in multiple countries). Amazon
 works fine. Maybe someone in torproject could test and if an error
 confirmed, check the status of the meek-azure server?

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

Re: [tor-bugs] #18172 [Applications/Tor Browser]: Emoji support is broken in Tor Browser 5.5

[Tor Bug Tracker & Wiki]

#18172: Emoji support is broken in Tor Browser 5.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-   |  Actual Points:
  usability-website, tbb-5.5-regression, |
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by vegansalad):

 @arthuredelstein did you finish your advanced emoji research? i just found
 out about this Tor Browser on Linux emoji related issue and wrote some
 notes up over here: https://github.com/fedwiki/wiki/issues/97

 from what I can discern, the decisions that Tor Browser makes related to
 what it whitelists might be pulled upstream into Mozilla (currently only
 manually) since they are adding font.system.whitelist in Firefox 52.
 here's some talk about it:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1121643

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

Re: [tor-bugs] #21256 [Applications/Tor Browser]: update tor browser spec for esr52

[Tor Bug Tracker & Wiki]

#21256: update tor browser spec for esr52
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20680| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * parent:   => #20680


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21256 [Applications/Tor Browser]: update tor browser spec for esr52

[Tor Bug Tracker & Wiki]

#21256: update tor browser spec for esr52
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 We're doing more first party isolation in esr52, thanks to the hard work
 of our Mozilla friends. Let's update our design and implementation
 document to reflect the changes.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications hardware, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications
hardware, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 == Summary of information about Allot Communications ==

 kzblocked found some evidence that at least part of the Kazakh firewall is
 provided by [https://en.wikipedia.org/wiki/Allot_Communications Allot
 Communications], which seems to be some firewall/DPI vendor.

 As I understand it, the main evidence that Allot hardware is in use is
 comment:177, import applications (I think that's what they are) dated
 2014-11-07 that show `АО "Казахтелеком"` ([https://en.wikipedia.org/wiki
 /Joint-stock_company JSC] Kazakhtelekom) asking to import equipment from
 `"Allot Communications LTD"` in Israel.
  *
 [http://www.rep.nca.kz/index.php?mode=r3=4%D2%D1.KZ.1900193.21.01.02407
 4ТС.KZ.1900193.21.01.02407] (https://archive.is/UXbwA): 1 ×
 [https://www.allot.com/products/platforms/service-gateway/#1461143657367
 -91864faf-6cb8 SG-Sigma E6]
  *
 [http://www.rep.nca.kz/index.php?mode=r3=4%D2%D1.KZ.1900193.21.01.02408
 4ТС.KZ.1900193.21.01.02408] (https://archive.is/1vSE6): 3 ×
 [https://www.allot.com/products/platforms/service-gateway/#1461143538377
 -8005dcec-ef24 SG-Tera 14]
  *
 [http://www.rep.nca.kz/index.php?mode=r3=4%D2%D1.KZ.1900193.21.01.02409
 4ТС.KZ.1900193.21.01.02409] (https://archive.is/UdfAf): 2 ×
 [https://www.allot.com/products/platforms/service-gateway/#1461143538377
 -8005dcec-ef24 SG-Tera 14]:
  *
 [http://www.rep.nca.kz/index.php?mode=r3=4%D2%D1.KZ.1900193.21.01.02410
 4ТС.KZ.1900193.21.01.02410] (https://archive.is/2p3Sa): 2 ×
 [https://www.allot.com/products/platforms/service-gateway/#1461143538377
 -8005dcec-ef24 SG-Tera 14]

 The other piece is from comment:175, in which a past 0.209.ru
 blockpage, which [[comment:161|we previously found]] to have the same HTTP
 signature as a Kazakhstan block page, explicitly said "Allot" on it.

 They call their DPI tech [https://www.allot.com/technology/dart-dpi/
 "DART"]. It's unclear how much is their own and how much is integration of
 other companies' such as Sophos and Kaspersky. Their page of
 [https://www.allot.com/products/platforms/supported-
 protocols/#1460974307058-a61550f0-8196 supported protocols]
 (https://archive.is/AuA8b) explicitly mentions Tor, ScrambleSuit, obfs4,
 and meek, among others:
 > === June 13, 2016 ===
 > Private VPN services provided by the Tor project are used by millions
 the world over, including IT professionals, law enforcement, journalists,
 bloggers, business execs, researchers and everyday users who want to
 protect their privacy. A number of applications, like bridges and
 pluggable transports have sprouted up around Tor to improve the privacy
 and the experience. Some Tor browsers provide bridges by default. And if
 not, these tools can be downloaded at any time. A bridge is a tool that
 makes Tor traffic look like any other traffic, such that censors and other
 monitors do not identify it as Tor per se. In Allot’s latest DART Protocol
 Pack, we refined our signature for the Tor obfs4 safe transport, to assure
 accruate identification of this kind of traffic on your network:
 >  * Tor Obfs4
 > === April 4th, 2016 ===
 > Online anonymity is often viewed as counter-productive and there is a
 vigorous and ongoing debate regarding the unprecedented anonymity enabled
 by the Internet. The creators of the Tor project are understandably pro-
 anonymity, arguing in favor of the many positive and productive uses of
 TOR by all kinds of people, including IT professionals, law enforcement,
 journalists, bloggers, business execs, researchers and everyday users who
 want to protect their privacy. In Allot’s latest DART Protocol Pack we
 revisited and refined these TOR transport protocols to assure accurate
 detection of their use:
 >  * TOR ScrambleSuit (pluggable proxy transport protocol)
 >  * TOR Obfs4 (TCP obfuscation layer)
 >  * TOR
 > === February 2nd, 2016 ===
 > TOR is popular anonymizer application that uses the “onion router.”
 Onion Router is a website that takes requests for web-pages and routes
 them through other onion router nodes, until your requested page reaches
 you. Onion routers encrypt the traffic which means no one can see what
 you’re asking for, and the layers of the onion don’t know who they’re
 working for.  In Allot’s latest DART Protocol Pack we added signatures
 that 

Re: [tor-bugs] #17241 [Core Tor/Tor]: prop224: Implement relay side support

[Tor Bug Tracker & Wiki]

#17241: prop224: Implement relay side support
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  parent
 Reviewer:  asn, dgoulet |Sponsor:  SponsorR-must
-+

Comment (by nickm):

 Now that #20029 is closed, is this done 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] #20029 [Core Tor/Tor]: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells

[Tor Bug Tracker & Wiki]

#20029: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224, TorCoreTeam201612,  |  Actual Points:
  review-group-15|
Parent ID:  #17241   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by nickm):

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


Comment:

 Done, merged. Woo!

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

Re: [tor-bugs] #20029 [Core Tor/Tor]: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells

[Tor Bug Tracker & Wiki]

#20029: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612,  |  Actual Points:
  review-group-15|
Parent ID:  #17241   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-

Comment (by nickm):

 ticket20029_030_06-resquash is just what I was hoping for: the same end-
 result, only squashed:
 {{{
 [816]$ git diff dgoulet/ticket20029_030_05
 dgoulet/ticket20029_030_06-resquash
 [817]$
 }}}

 Resolving minor merge conflicts now...

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

Re: [tor-bugs] #20029 [Core Tor/Tor]: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells

[Tor Bug Tracker & Wiki]

#20029: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612,  |  Actual Points:
  review-group-15|
Parent ID:  #17241   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-

Comment (by dgoulet):

 Rebased on latest master and fixup commit squashed: `ticket20029_030_06`

 Only resquash: `ticket20029_030_06-resquash`

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

Re: [tor-bugs] #21255 [Metrics/Metrics website]: fraction value computation for clients.csv and its descriptions don't seem to match

[Tor Bug Tracker & Wiki]

#21255: fraction value computation for clients.csv and its descriptions don't 
seem
to match
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 After looking very quickly, I'd say that's a documentation bug or maybe
 over-simplification.  See the following sentence in the relevant tech
 report (https://research.torproject.org/techreports/counting-daily-bridge-
 users-2012-10-24.pdf):

 ''"Figure 3 shows reported directory requests, estimated fraction of
 directory requests that got reported by bridges, and estimated total
 directory requests in the network."''

 I'd want to look more closely.  But for the moment it's probably safe to
 assume that the documentation is wrong, not the implementation.

 Nice catch, by the way. :)

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

Re: [tor-bugs] #20029 [Core Tor/Tor]: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells

[Tor Bug Tracker & Wiki]

#20029: prop224: Implementation of INTRODUCE1 and INTRODUCE_ACK cells
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201612,  |  Actual Points:
  review-group-15|
Parent ID:  #17241   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-

Comment (by dgoulet):

 Every comment from nickm have been addressed with fixup commit in still in
 `ticket20029_030_05`

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

Re: [tor-bugs] #20989 [Applications/Tor Browser]: browser sandbox profile too restrictive on OSX 10.12.2

[Tor Bug Tracker & Wiki]

#20989: browser sandbox profile too restrictive on OSX 10.12.2
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201701R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 I took the patch (commit f55cbeea243675db8acf1015ca7e1ceed39f0933 on
 `master`). mactoruser: feedback and testing is still appreciated if you
 have some time to do so. 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] #20830 [Core Tor/Tor]: Remove legacy guard algorithm code

[Tor Bug Tracker & Wiki]

#20830: Remove legacy guard algorithm code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:  #20822| Points:  .5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 My branch `remove_legacy_guards` does this.

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

Re: [tor-bugs] #21062 [Core Tor/Tor]: get_options_mutable: Assertion global_options failed; aborting -- b/c LearnCircuitBuildTimeout 0

[Tor Bug Tracker & Wiki]

#21062: get_options_mutable: Assertion global_options failed; aborting -- b/c
LearnCircuitBuildTimeout 0
--+
 Reporter:  alecmuffett   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.7-rc
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 lgtm; 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] #20684 [Core Tor/Tor]: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM

[Tor Bug Tracker & Wiki]

#20684: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM
-+
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  easy intro typo  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 I think the convention here is (or should be) to use a suffix that denotes
 the units of the constant.  So I've added an extra commit
 (e0e729d4b52ef4a14e63e194ff0a47a0aa0d0f99) and merged this.

 (We don't need to add a "BYTES" suffix to everything that is already in
 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

Re: [tor-bugs] #20178 [Core Tor/Tor]: The fallback update script should log stem connection errors at warning level

[Tor Bug Tracker & Wiki]

#20178: The fallback update script should log stem connection errors at warning
level
-+-
 Reporter:  teor |  Owner:  haxxpop
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, tor-03-unspecified-201612  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by haxxpop):

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


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

Re: [tor-bugs] #20177 [Core Tor/Tor]: When checking existing fallbacks, report those fallbacks at warning log level

[Tor Bug Tracker & Wiki]

#20177: When checking existing fallbacks, report those fallbacks at warning log
level
-+-
 Reporter:  teor |  Owner:  haxxpop
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fallback, tor-03-unspecified-201612  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by haxxpop):

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


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

Re: [tor-bugs] #20174 [Core Tor/Tor]: Automate checking existing fallbacks

[Tor Bug Tracker & Wiki]

#20174: Automate checking existing fallbacks
-+-
 Reporter:  teor |  Owner:  haxxpop
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fallback, tor-03-unspecified-201612  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by haxxpop):

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


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

Re: [tor-bugs] #20175 [Core Tor/Tor]: Allow the fallback script to ignore temporary IPv6 addresses

[Tor Bug Tracker & Wiki]

#20175: Allow the fallback script to ignore temporary IPv6 addresses
-+-
 Reporter:  teor |  Owner:  haxxpop
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fallback, ipv6,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by haxxpop):

 * owner:   => haxxpop
 * 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] #21255 [Metrics/Metrics website]: fraction value computation for clients.csv and its descriptions don't seem to match

[Tor Bug Tracker & Wiki]

#21255: fraction value computation for clients.csv and its descriptions don't 
seem
to match
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Maybe, I'm missing something obvious, but the calculation for `frac` in
 `clients.csv` doesn't seem to calculate what is stated in the web-site
 description (nor in the sql comment),
 [https://metrics.torproject.org/stats.html#clients web-site]:
   "frac: Fraction of relays or bridges in percent that the estimate is
 based on."


 [https://gitweb.torproject.org/metrics-web.git/tree/modules/clients/init-
 userstats.sql?id=14840ed2db075bbc1d0991b974becc3826a50969#n553 SQL
 excerpt]:
 {{{
 ...
   -- Estimated fraction of nodes reporting directory requests, which is
   -- used to extrapolate observed requests to estimated total requests in
   -- the network.  The closer this fraction is to 1.0, the more precise
   -- the estimation.
   CAST(a.frac * 100 AS INTEGER) AS frac,

   -- Finally, the estimate number of users.
   CAST(a.rrx / (a.frac * 10) AS INTEGER) AS users

   -- Implement the estimation method in a subquery, so that the ugly
   -- formula only has to be written once.
   FROM (
 SELECT date, node, country, transport, version, rrx, nrx,
(hrh * nh + hh * nrh) / (hh * nn) AS frac
 <<<<
 FROM aggregated WHERE hh * nn > 0.0) a

   -- Only include estimates with at least 10\% of nodes reporting
 directory
   -- request statistics.
   WHERE a.frac BETWEEN 0.1 AND 1.0
 ...
 }}}

 The arrow points at the **fraction of reported directory requests** (or
 responses for bridges) of the total (estimated) sum of directory requests
 (responses for bridges), but not the **fraction of nodes reporting
 directory requests** of the total number of nodes.

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

Re: [tor-bugs] #17434 [Core Tor/DocTor]: DocTor should understand the shared randomness protocol

[Tor Bug Tracker & Wiki]

#17434: DocTor should understand the shared randomness protocol
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

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


Comment:

 Hi David. Downloading n^2 vote documents would be very expensive. If such
 a check is critical it could be implemented but it would be separate from
 the main consensus health script.

 Pushing these new checks and giving 'em a whirl. Feel free to reopen if
 you need 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] #17434 [Core Tor/DocTor]: DocTor should understand the shared randomness protocol

[Tor Bug Tracker & Wiki]

#17434: DocTor should understand the shared randomness protocol
-+--
 Reporter:  asn  |  Owner:  atagar
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dgoulet):

 Looks good! No idea if it actually works but I'll trust you on that!

 Is this detection is reasonable to do with DocTor you think? Quoting the
 tor-dev@ email:

 {{{
 It would also be useful if consensus-health fetched all the votes *seen*
 by an
 authority, and not just the one it publishes. This way we can find attacks
 where
 the attacker sends different votes to different honest auths. We can fetch
 the
 alien votes seen by an authority using the URL tor/status-vote/next/.z
 .
 }}}

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

Re: [tor-bugs] #17434 [Core Tor/DocTor]: DocTor should understand the shared randomness protocol

[Tor Bug Tracker & Wiki]

#17434: DocTor should understand the shared randomness protocol
-+--
 Reporter:  asn  |  Owner:  atagar
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by atagar):

 * status:  reopened => needs_review


Comment:

 Hi George, hi David. Sorry about the long delay here. Pushed checks #1-3
 to my ticket1434 branch. Check #4 requires remembering values from hour to
 hour and DocTor is largely stateless so unless it's vital I'm passing on
 that one.

 Mind reviewing the changes to make sure they're what you want?

 https://gitweb.torproject.org/user/atagar/doctor.git/log/?h=ticket17434

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

Re: [tor-bugs] #21250 [Community/Translations]: Suggestions for translations source strings

[Tor Bug Tracker & Wiki]

#21250: Suggestions for translations source strings
+---
 Reporter:  scootergrisen   |  Owner:  phoul
 Type:  enhancement | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Trivial | Resolution:
 Keywords:  translation |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by scootergrisen):

 Should the "" be in there strings?
 Perhaps remove "".

 {{{
 torproject.tor-misc-exoneratorproperties

 footer.abouttor.body.text=Tor is an international software project to
 anonymize Internet traffic by %s. Therefore, if you see traffic from
 a Tor relay, this traffic usually originates from someone using Tor,
 rather than from the relay operator. The Tor Project and Tor relay
 operators have no records of the traffic that passes over the network and
 therefore cannot provide any information about its origin. Be sure
 to %s, and don't hesitate to %s for more information.

 footer.aboutexonerator.body=The ExoneraTor service maintains a database of
 IP addresses that have been part of the Tor network. It answers the
 question whether there was a Tor relay running on a given IP address on a
 given date. ExoneraTor may store more than one IP address per relay
 if relays use a different IP address for exiting to the Internet than for
 registering in the Tor network, and it stores whether a relay permitted
 transit of Tor traffic to the open Internet at that time.

 }}}

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

Re: [tor-bugs] #20940 [Applications/Tor Browser Sandbox]: Deprecate x86 support.

[Tor Bug Tracker & Wiki]

#20940: Deprecate x86 support.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  sandbox-security Yawning201612|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

 * status:  reopened => 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] #21254 [Applications/Tor Browser Sandbox]: Deprecate x86 and arm support.

[Tor Bug Tracker & Wiki]

#21254: Deprecate x86 and arm support.
--+-
 Reporter:  cypherpunks   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  sandbox-security Yawning201612|  Actual Points:
Parent ID:  #20940| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

 * status:  new => closed
 * 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] #19263 [Applications/Tor Browser]: Tor browser is not rounding the width correctly in tiling WMs

[Tor Bug Tracker & Wiki]

#19263: Tor browser is not rounding the width correctly in tiling WMs
---+--
 Reporter:  torbrowseruser2016 |  Owner:  tbb-team
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by crile):

 Relating to further development; would it be possible to include an option
 of setting the size how the webpages get displayed, no matter the size of
 the TB window?
 That way fingerprinting would not only be much harder because of the
 100px/200px steps, but one could also easily choose, wich webpage
 resolution they want to use. This would may be be a good option to prevent
 fingerprinting for people using more uncommon screen resolutions, too
 (Relating to the following site, the 1366x768 and 1920x180 screen
 resolutions are by far the most common: http://gs.statcounter.com/#desktop
 +console-resolution-ww-monthly-201512-201612).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21254 [Applications/Tor Browser Sandbox]: Deprecate x86 and arm support.

[Tor Bug Tracker & Wiki]

#21254: Deprecate x86 and arm support.
-+-
 Reporter:  cypherpunks  |  Owner:  yawning
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser Sandbox|   Keywords:  sandbox-security
 Severity:  Normal   |  Yawning201612
Actual Points:   |  Parent ID:  #20940
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 >There's lots of reasons why this is a good idea:
 >* All x86-compatible CPUs and arm core are developed by USA-based
 companies which will do anything NSA wants them do.
 >* They contain hardware backdoors: Management Engine, its analogues,
 TPMs, SecureBoot, Anti-Theft, DRM, SGX, TrustZone.
 >* Shadow stack-related headaches.
 >* Supporting hardware I don't have, running software I don't use, to
 ultimately obtain results that are empirically worse than the other
 supported
 platform is a poor use of development time.
 >* AnyShittyDistro gave up on supporting x86 and arm for kernel.

 Chinesse allwinner and loongsoon are our only hopes ;)!

 More seriously, if anyone is using 32 bit OS, this means he have to use
 that shit because his hardware is shit. In fat it is not quite shit
 because it was manufactured before all these backdoors in consumer
 electronics have appeared, so it can be considered clean. I expect that in
 a few years that old shithardware will cost more than a supernew
 superfast superbackdoored superglamour superpatriotic "hi-end" one.

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

Re: [tor-bugs] #20940 [Applications/Tor Browser Sandbox]: Deprecate x86 support.

[Tor Bug Tracker & Wiki]

#20940: Deprecate x86 support.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  task  | Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox-security Yawning201612|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  closed => reopened
 * 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] #20684 [Core Tor/Tor]: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM

[Tor Bug Tracker & Wiki]

#20684: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM
-+
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy intro typo  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  assigned => merge_ready


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

Re: [tor-bugs] #20684 [Core Tor/Tor]: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM

[Tor Bug Tracker & Wiki]

#20684: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM
-+
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy intro typo  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Actually, the issue was that `DIRCACHE_MIN_MEM` was used instead of
 `DIRCACHE_MIN_MB_MEM` in the test. I've fixed it using the attached
 commit. Test passes now.

 See branch `bug20684_030_01`

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

Re: [tor-bugs] #21062 [Core Tor/Tor]: get_options_mutable: Assertion global_options failed; aborting -- b/c LearnCircuitBuildTimeout 0

[Tor Bug Tracker & Wiki]

#21062: get_options_mutable: Assertion global_options failed; aborting -- b/c
LearnCircuitBuildTimeout 0
--+
 Reporter:  alecmuffett   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.7-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * owner:   => dgoulet
 * status:  new => accepted
 * cc: dgoulet (removed)


Comment:

 See branch `bug21062_030_01`.

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

Re: [tor-bugs] #21062 [Core Tor/Tor]: get_options_mutable: Assertion global_options failed; aborting -- b/c LearnCircuitBuildTimeout 0

[Tor Bug Tracker & Wiki]

#21062: get_options_mutable: Assertion global_options failed; aborting -- b/c
LearnCircuitBuildTimeout 0
--+
 Reporter:  alecmuffett   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.7-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => 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] #21108 [Core Tor/Tor]: Dir auths should vote BadExit even if they don't vote Running

[Tor Bug Tracker & Wiki]

#21108: Dir auths should vote BadExit even if they don't vote Running
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{AuthDirListBadExits 1}}} is set, yes.

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

Re: [tor-bugs] #21242 [Core Tor/Tor]: Start-up error

[Tor Bug Tracker & Wiki]

#21242: Start-up error
--+
 Reporter:  Felixix   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information


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

Re: [tor-bugs] #21253 [Core Tor/Tor]: Add link handshakes to benchmark program

[Tor Bug Tracker & Wiki]

#21253: Add link handshakes to benchmark program
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorU-must
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21253 [Core Tor/Tor]: Add link handshakes to benchmark program

[Tor Bug Tracker & Wiki]

#21253: Add link handshakes to benchmark program
---+
 Reporter:  nickm  |  Owner:
 Type:  task   | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  SponsorU-must  |
---+
 Our ed25519 handshake may have slowed link handshakes down a little.  How
 much? We should add a couple of items to ./src/test/bench

 This is follow-on item for sponsor U, prop220, and #15055.

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

Re: [tor-bugs] #21250 [Community/Translations]: Suggestions for translations source strings

[Tor Bug Tracker & Wiki]

#21250: Suggestions for translations source strings
+---
 Reporter:  scootergrisen   |  Owner:  phoul
 Type:  enhancement | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Trivial | Resolution:
 Keywords:  translation |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by scootergrisen):

 I few strings are using space " " before "...".
 I suspect they should note have the space.

 {{{
 Waiting for contact ...
 Generating private key for %S (%S) ...
 Waiting for contact ...
 }}}

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

Re: [tor-bugs] #20956 [Core Tor/Tor]: optionally do not write command line config to torrc

[Tor Bug Tracker & Wiki]

#20956: optionally do not write command line config to torrc
+
 Reporter:  mcs |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-wants 029-backport  |  Actual Points:  .2
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+

Comment (by arma):

 tiny typo, "for the each time"

 I didn't try running it, or hunting for other things that it forgets to
 fix, but I endorse the approach it takes!

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

Re: [tor-bugs] #21245 [Applications/Tor Browser]: Add danish (da) translation

[Tor Bug Tracker & Wiki]

#21245: Add danish (da) translation
--+--
 Reporter:  scootergrisen |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 Until we resolve #17400, one answer could be "Install a Firefox language
 pack."  Unfortunately, this does not work for Danish and many other
 locales because Torbutton does not include up-to-date locale files for
 many languages.  The problem is that our trans_tools/import-
 translations.sh script only pulls in some translations from Transifex but
 we ship everything (which is wrong).

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

Re: [tor-bugs] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

[Tor Bug Tracker & Wiki]

#19760: Update longclaw's hard-coded IPv6 address
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  dir-auth, ipv6, 029-proposed,|  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_information
 * milestone:  Tor: unspecified => Tor: 0.3.1.x-final


Comment:

 Once micah figure out the IPv6 address that should be used, he'll add it
 to this ticket. Putting that one in 031 so we don't forget about 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] #17847 [Core Tor/Tor]: Unify router_pick_directory_server_impl and router_pick_trusteddirserver_impl

[Tor Bug Tracker & Wiki]

#17847: Unify router_pick_directory_server_impl and
router_pick_trusteddirserver_impl
+
 Reporter:  teor|  Owner:  ahf
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  nickm   |Sponsor:
+
Changes (by nickm):

 * status:  needs_review => new
 * keywords:  easy, refactor, review-group-15 => easy, refactor


Comment:

 Looks like a good start, and I'd be happy to take it as-is, but unless I'm
 missing something it doesn't yet actually unify  the two functions yet?
 They're still two separate functions with mostly duplicated logic.

 I've merged it, with a change to pass tor_addr_t by reference rather than
 on the stack. Calling this ticket "new" again.

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

Re: [tor-bugs] #19357 [Core Tor/Tor]: keypin_load_journal_impl() might break if journal file contains NUL

[Tor Bug Tracker & Wiki]

#19357: keypin_load_journal_impl() might break if journal file contains NUL
-+-
 Reporter:  andrea   |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  isaremoved,  |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Agree with comment:1 and I can't find a way that a NUL value could get
 written to the file even with a partial write or write() error...

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

Re: [tor-bugs] #21242 [Core Tor/Tor]: Start-up error

[Tor Bug Tracker & Wiki]

#21242: Start-up error
--+
 Reporter:  Felixix   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Can you share the contents of your configuration for this tor instance?

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

Re: [tor-bugs] #21142 [Core Tor/Tor]: prop271: circuits_pending_other_guards not properly maintained

[Tor Bug Tracker & Wiki]

#21142: prop271: circuits_pending_other_guards not properly maintained
--+
 Reporter:  asn   |  Owner:  asn
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  0.3
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

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


Comment:

 ack; merged; thank you!

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

Re: [tor-bugs] #20956 [Core Tor/Tor]: optionally do not write command line config to torrc

[Tor Bug Tracker & Wiki]

#20956: optionally do not write command line config to torrc
+
 Reporter:  mcs |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-wants 029-backport  |  Actual Points:  .2
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+
Changes (by gk):

 * cc: gk (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] #20956 [Core Tor/Tor]: optionally do not write command line config to torrc

[Tor Bug Tracker & Wiki]

#20956: optionally do not write command line config to torrc
+
 Reporter:  mcs |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-wants 029-backport  |  Actual Points:  .2
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * keywords:  tbb-wants => tbb-wants 029-backport
 * status:  accepted => needs_review
 * actualpoints:   => .2


Comment:

 My branch "feature_20956_029" adds `__SocksPort`, etc for every kind of
 port, while retaining the behavior of the old SocksPort options.  (Unlike
 the patch above, it shouldn't cause regular socksports to get dropped by
 SAVECONF.)

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

Re: [tor-bugs] #20906 [Core Tor/Tor]: SocksPorts and ControlPorts should be stored in a set, not a list

[Tor Bug Tracker & Wiki]

#20906: SocksPorts and ControlPorts should be stored in a set, not a list
-+
 Reporter:  arthuredelstein  |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tbb-wants|  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


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

Re: [tor-bugs] #20906 [Core Tor/Tor]: SocksPorts and ControlPorts should be stored in a set, not a list

[Tor Bug Tracker & Wiki]

#20906: SocksPorts and ControlPorts should be stored in a set, not a list
-+
 Reporter:  arthuredelstein  |  Owner:  nickm
 Type:  enhancement  | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-wants|  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I'm currently planning to wontfix this in favor of 20956.

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

Re: [tor-bugs] #21252 [Applications/Tor Browser]: Wrong color for rounded tabs

[Tor Bug Tracker & Wiki]

#21252: Wrong color for rounded tabs
--+--
 Reporter:  scootergrisen |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by scootergrisen):

 Using Linux + GNOME.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21252 [Applications/Tor Browser]: Wrong color for rounded tabs

[Tor Bug Tracker & Wiki]

#21252: Wrong color for rounded tabs
--+--
 Reporter:  scootergrisen |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Graphics of the rounded tabs dont have same color as the rest of the tab.
 Using 6.0.8 (based on Mozilla Firefox 45.6.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] #20545 [Core Tor/Tor]: Default Value Incorrect in Tor Manual

[Tor Bug Tracker & Wiki]

#20545: Default Value Incorrect in Tor Manual
+--
 Reporter:  agd |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  invalid
 Keywords:  doc, tor-03-unspecified-201612  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

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


Comment:

 Default is indeed 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] #21150 [Core Tor/Tor]: HiddenServiceStatistics gets set to 0 in your torrc, and stays 0 when you become a relay

[Tor Bug Tracker & Wiki]

#21150: HiddenServiceStatistics gets set to 0 in your torrc, and stays 0 when 
you
become a relay
--+
 Reporter:  arma  |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:2 arma]:
 > Replying to [comment:1 cypherpunks]:
 > > No, respecting the user's torrc settings is **not** a bug or a bad
 thing. The root problem here is Sponsor R, inappropriate closeness between
 Tor and the US government, and dictats from them being shamefully and
 ineffectively laundered as "community decisions".
 >
 > Sorry Mr angry person, but you are mistaken.
 >
 > If you want the default to be different, that's a different topic.
 The default should be `0`. And let relay operators who 1. understand what
 it does and 2. want to do it, set it to `1` if they wish. Not the other
 way round!

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

Re: [tor-bugs] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards

[Tor Bug Tracker & Wiki]

#21052: Bad prop271 behavior when exhausting all guards
+--
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop271, tor-guard, regression  |  Actual Points:  0.6
Parent ID:  #20822  | Points:  1.5
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * owner:  nickm => asn
 * status:  needs_review => assigned
 * reviewer:   => nickm


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

Re: [tor-bugs] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards

[Tor Bug Tracker & Wiki]

#21052: Bad prop271 behavior when exhausting all guards
+--
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  needs_review
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop271, tor-guard, regression  |  Actual Points:  0.6
Parent ID:  #20822  | Points:  1.5
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * 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] #21142 [Core Tor/Tor]: prop271: circuits_pending_other_guards not properly maintained

[Tor Bug Tracker & Wiki]

#21142: prop271: circuits_pending_other_guards not properly maintained
--+
 Reporter:  asn   |  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  0.3
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * 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] #21142 [Core Tor/Tor]: prop271: circuits_pending_other_guards not properly maintained

[Tor Bug Tracker & Wiki]

#21142: prop271: circuits_pending_other_guards not properly maintained
--+
 Reporter:  asn   |  Owner:  asn
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  0.3
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * owner:  nickm => asn
 * status:  needs_review => assigned
 * reviewer:   => nickm


Comment:

 Fixing owner (and 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] #21150 [Core Tor/Tor]: HiddenServiceStatistics gets set to 0 in your torrc, and stays 0 when you become a relay

[Tor Bug Tracker & Wiki]

#21150: HiddenServiceStatistics gets set to 0 in your torrc, and stays 0 when 
you
become a relay
--+
 Reporter:  arma  |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:8 arma]:
 > So we're violating the #4244 rule of "thou shalt not modify the options
 to make it look like the user picked A when actually it said B" on all of
 these config options -- it just happens that the other ones already
 default to 0 so they aren't being noticed yet.

 Thinking a bit more on it, I think those other config options, where they
 default to 0 but we set them to 0 explicitly if we're not a relay, are
 also bugs: imagine the user set them to 1 in their torrc, but then spent a
 bit of time not being a relay. saveconf would quietly set them to 0 in
 their torrc. That can't be what the user expects.

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

Re: [tor-bugs] #21134 [Core Tor/Tor]: Fail if file is too large to mmap.

[Tor Bug Tracker & Wiki]

#21134: Fail if file is too large to mmap.
+--
 Reporter:  junglefowl  |  Owner:
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  tor_mmap_file, review-group-15  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #21134 [Core Tor/Tor]: Fail if file is too large to mmap.

[Tor Bug Tracker & Wiki]

#21134: Fail if file is too large to mmap.
+--
 Reporter:  junglefowl  |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  tor_mmap_file, review-group-15  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  nickm   |Sponsor:
+--

Comment (by nickm):

 Oh, one more: off_t is a signed type, and size_t isn't, so the comparison
 of the two can be 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] #21134 [Core Tor/Tor]: Fail if file is too large to mmap.

[Tor Bug Tracker & Wiki]

#21134: Fail if file is too large to mmap.
+--
 Reporter:  junglefowl  |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  tor_mmap_file, review-group-15  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * status:  needs_information => needs_review


Comment:

 We build with large-file support by default, since we have
 "AC_SYS_LARGEFILE" in our configure.ac.

 Looking at the code, I think this needs these changes.

   * It needs a changes file (see doc/HACKING/GettingStarted.md)
   * We should really allow the case where st.st_size == SIZE_MAX.
   * This should be at least a warning, not an INFO message, since we can't
 really recover from this 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] #21229 [Core Tor/Tor]: Lack of KEYID explanation in tor-spec.txt

[Tor Bug Tracker & Wiki]

#21229: Lack of KEYID explanation in tor-spec.txt
--+
 Reporter:  KolK  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #21226 [Core Tor/Tor]: Torspec: Proposal 224 has a wrong/unclear time period example

[Tor Bug Tracker & Wiki]

#21226: Torspec: Proposal 224 has a wrong/unclear time period example
---+
 Reporter:  nicoo  |  Owner:
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords:  tor-hs, prop224, spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 lgtm; 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] #21058 [Core Tor/Tor]: Manual Modifications: Correction and Improvement

[Tor Bug Tracker & Wiki]

#21058: Manual Modifications: Correction and Improvement
--+
 Reporter:  agd   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 ok, 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] #19953 [Core Tor]: DataDirectoryGroupReadable does not take effect when relay enabled

[Tor Bug Tracker & Wiki]

#19953: DataDirectoryGroupReadable does not take effect when relay enabled
--+
 Reporter:  redfish   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #21033 [Core Tor/Tor]: hs: HiddenServiceNumIntroductionPoints can't go below the default value of 3

[Tor Bug Tracker & Wiki]

#21033: hs: HiddenServiceNumIntroductionPoints can't go below the default value 
of
3
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorR-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] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

[Tor Bug Tracker & Wiki]

#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, dns,   |  Actual Points:  .2
  TorCoreTeam201609, 029-backport|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  029-proposed, dns, TorCoreTeam201609, 029-backport, review-
 group-15 => 029-proposed, dns, TorCoreTeam201609, 029-backport
 * milestone:  Tor: 0.3.0.x-final => Tor: 0.2.9.x-final


Comment:

 Squashed, with phw's fix for #19025, as `bug19769_19025_029`.

 Merged `bug19769_19025_029` to master; possible 0.2.9 backport.

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

Re: [tor-bugs] #19025 [Core Tor/Tor]: Exit relays always return DNS TTL 60 to tor clients

[Tor Bug Tracker & Wiki]

#19025: Exit relays always return DNS TTL 60 to tor clients
-+-
 Reporter:  phw  |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  dns, TorCoreTeam201607,  |  Actual Points:
  029-proposed, review-group-15  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I've rolled this into my branch for #19769.

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

Re: [tor-bugs] #19025 [Core Tor/Tor]: Exit relays always return DNS TTL 60 to tor clients

[Tor Bug Tracker & Wiki]

#19025: Exit relays always return DNS TTL 60 to tor clients
-+-
 Reporter:  phw  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  dns, TorCoreTeam201607,  |  Actual Points:
  029-proposed, review-group-15  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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

[tor-bugs] #21251 [Community/Translations]: Missing translation even for languages that are 100% translated

[Tor Bug Tracker & Wiki]

#21251: Missing translation even for languages that are 100% translated
+---
 Reporter:  scootergrisen   |  Owner:  phoul
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 Multiple translations are 100% on transifex but does not appear on
 https://www.torproject.org/projects/torbrowser.html.en#downloads for
 people to download.

 Maybe there should be instructions on how to get the translation put into
 use.

 I'm not sure how thigs work with Tor Browser but maybe follow the same way
 Firefox uses translations. That you can download a xpi file with the
 language you wish to use.

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

Re: [tor-bugs] #21250 [Community/Translations]: Suggestions for translations source strings

[Tor Bug Tracker & Wiki]

#21250: Suggestions for translations source strings
+---
 Reporter:  scootergrisen   |  Owner:  phoul
 Type:  enhancement | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Trivial | Resolution:
 Keywords:  translation |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by scootergrisen):

 Double spaces:

 {{{
 torproject.tor-launcher-network-settingsdtd

 

 ---

 torproject.3-https-everywhere-https-everywhere-dtd

 

 ---

 torproject.3-https-everywhere-ssl-observatory-dtd

 https://www.something.com, the certificate
 received by the Observatory will indicate that somebody visited
 www.something.com, but not who visited the site, or what specific page
 they
 looked at.  Mouseover the options for further details:">

 

 

 

 }}}

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

Re: [tor-bugs] #21250 [Community/Translations]: Suggestions for translations source strings

[Tor Bug Tracker & Wiki]

#21250: Suggestions for translations source strings
+---
 Reporter:  scootergrisen   |  Owner:  phoul
 Type:  enhancement | Status:  new
 Priority:  Very Low|  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Trivial | Resolution:
 Keywords:  translation |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by gk):

 * owner:   => phoul
 * component:  - Select a component => Community/Translations


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

Re: [tor-bugs] #21250 [- Select a component]: Suggestions for translations source strings

[Tor Bug Tracker & Wiki]

#21250: Suggestions for translations source strings
--+-
 Reporter:  scootergrisen |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  translation   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by scootergrisen):

 {{{
 email adress
 >
 email address

 torproject.3-whisperback-whisperback-pot

 #: ../whisperBack/gui.py:232
 msgid "The contact email adress doesn't seem valid."

 ---

 developpers
 >
 developers

 torproject.3-whisperback-whisperback-pot

 #: ../whisperBack/gui.py:383
 msgid "Copyright © 2009-2012 Tails developpers (ta...@boum.org)"

 ---

 Perhaps always use " for HTML attribute values in stead of sometimes " and
 sometimes '.

 
 
 

 ---

 }}}

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

Re: [tor-bugs] #21126 [Internal Services/Tor Sysadmin Team]: restart redis stunnel before CRL expires

[Tor Bug Tracker & Wiki]

#21126: restart redis stunnel before CRL expires
-+
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #21216 [Internal Services/Tor Sysadmin Team]: Need a virtual host to run OnionPerf

[Tor Bug Tracker & Wiki]

#21216: Need a virtual host to run OnionPerf
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 Host is papillare, put service related files directly into
 /srv/onionperf.torproject.org, as user onionperf.  port 80 redirects to
 10080.

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