date:20190723

Re: [tor-bugs] #31230 [Circumvention/Snowflake]: Firefox addon blocked from agent by Google Safe Browsing service

2019-07-23 Thread Tor Bug Tracker & Wiki

#31230: Firefox addon blocked from agent by Google Safe Browsing service
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 I wonder if it's related to the zip bomb article I posted recently. That
 was on www.bamsoftware.com, not snowflake-broker.bamsoftware.com, but
 perhaps it carries across subdomains. I noticed about 2019-07-20 that
 Twitter started calling it an
 
[https://twitter.com/safety/unsafe_link_warning?unsafe_link=https://www.bamsoftware.com/hacks/zipbomb/
 "unsafe link"]. There's some kind of lookup service for Safe Browsing
 [https://support.google.com/webmasters/answer/3258249?hl=en_topic=4596795
 here], but it looks like it needs a Google account login.

 If it's the case that *.bamsoftware.com is blocked by Safe Browsing, we'll
 need a new top-level domain for the broker (and bridge). It's not that
 hard to do: we just need
  * a DNS record pointing to the broker's IP address
  * to restart the broker with the new domain name in `--acme-hostnames`
  * to update `brokerUrl` in config.js
  * push a new release of the WebExtension and update
 snowflake.torproject.org

 I don't think we need to push a new release of the client software, only
 the in-browser software.

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

Re: [tor-bugs] #30953 [Core Tor/Tor]: ServerTransportListenAddr is ignored when stated second time for the IPv6 address

2019-07-23 Thread Tor Bug Tracker & Wiki

#30953: ServerTransportListenAddr is ignored when stated second time for the 
IPv6
address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  duplicate
 Keywords:  ipv6, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by phw):

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


Comment:

 This is a duplicate of #11211. Let's continue the discussion over there.

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

Re: [tor-bugs] #20348 [Circumvention/Censorship analysis]: Allot Communications blocking of vanilla Tor, obfs4, and meek in Kazakhstan, starting 2016-06

2019-07-23 Thread Tor Bug Tracker & Wiki

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

Comment (by phw):

 The [https://censoredplanet.org Censored Planet] project has
 [https://censoredplanet.org/kazakhstan a summary of this attack].

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

Re: [tor-bugs] #31230 [Circumvention/Snowflake]: Firefox addon blocked from agent by Google Safe Browsing service

2019-07-23 Thread Tor Bug Tracker & Wiki

#31230: Firefox addon blocked from agent by Google Safe Browsing service
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 More info: the workaround doesn't persist, after restarting Firefox it
 goes back to being blacklisted again. While blacklisted, it logs the two
 errors above and also the line "Snowflake: Broker ERROR: Unexpected 0 - ".
 That last line is also looped if I use the in-page version of the proxy
 from https://snowflake.torproject.org/snowflake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31230 [Circumvention/Snowflake]: Firefox addon blocked from agent by Google Safe Browsing service

2019-07-23 Thread Tor Bug Tracker & Wiki

#31230: Firefox addon blocked from agent by Google Safe Browsing service
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 I opened the browser console for other work, and saw that the Snowflake
 addon was looping with the errors "The resource at “https://snowflake-
 broker.bamsoftware.com/proxy” was blocked by Safe Browsing." and "Cross-
 Origin Request Blocked: The Same Origin Policy disallows reading the
 remote resource at https://snowflake-broker.bamsoftware.com/proxy.
 (Reason: CORS request did not succeed)."

 I worked around the problem by going to that URL in a new tab and clicking
 the "do it anyway" option when the warning appeared, and now the addon is
 looping normally with the "at client capacity" message. But
 bypassing/disabling Safe Browsing is obviously a non-starter for general
 users, so someone needs to determine why the agent URL was blacklisted by
 Google and get it cleared, or the Firefox addon will be effectively dead.

 Addon version 0.0.5.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31229 [Core Tor/Tor]: 3-hop tor circuit and malicious middle relays

2019-07-23 Thread Tor Bug Tracker & Wiki

#31229: 3-hop tor circuit and malicious middle relays
--+--
 Reporter:  JessieTessie  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Component:  Core Tor/Tor
  Version:|   Severity:  Critical
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Tor traffic can be correlated if someones know both the guard and exit.
 The middle relay seems to know both the guard and exit. To make Tor secure
 again, we will need an extra pair of relays to make sure that no-one knows
 both the guard and exit except the user.

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

Re: [tor-bugs] #31228 [Core Tor/Tor]: Support spawning multiple transport instances

2019-07-23 Thread Tor Bug Tracker & Wiki

#31228: Support spawning multiple transport instances
--+
 Reporter:  phw   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by dcf):

 It's interesting to compare the torrc configuration with the
 [https://github.com/twisteroidambassador/ptadapter ptadapter] one.
 ptadapter introduces another layer of naming: named instance keys above
 the level of the transport names.
 
[https://github.com/twisteroidambassador/ptadapter/blob/master/example_config.ini
 Example config].

 I haven't tested it, but I believe you could run two instances of obfs4
 with different options using something like:

 {{{
 [server]
 exec = /usr/bin/obfs4proxy
 forward = 127.0.0.1:7000
 tunnels = server_the_first

 [server_the_first]
 transport = obfs4
 listen = 0.0.0.0:1
 options-cert=a

 [server]
 exec = /usr/bin/obfs4proxy
 forward = 127.0.0.1:7000
 tunnels = server_the_second

 [server_the_second]
 transport = obfs4
 listen = 0.0.0.0:2
 options-cert=bb
 }}}

 Note that while you can mix multiple `tunnels` (`[server_*]` sections)
 with different transport names under the same `[server]` section, the PT
 protocol wouldn't allow multiple `tunnels` with the ''same'' transport
 name, so you have to split them out into multiple processes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31228 [Core Tor/Tor]: Support spawning multiple transport instances

2019-07-23 Thread Tor Bug Tracker & Wiki

#31228: Support spawning multiple transport instances
--+
 Reporter:  phw   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  10|   Reviewer:
  Sponsor:|
--+
 One Tor instance can only handle one transport instance, i.e., one cannot
 run two obfs4 instances in one tor. Adding support for this use case will
 require changes in our PT spec, in PT spec implementations, and in tor.

 As pointed out
 [https://trac.torproject.org/projects/tor/ticket/29285#comment:5 in this
 comment], tor would need the config options `ServerTransportPlugin`,
 `ServerTransportListenAddr`, and `ServerTransportOptions` to support
 multiple instances of a single transport. One way to accomplish this would
 be to append a numeric, incrementing suffix to a transport's name, e.g.:

 {{{
 ServerTransportPlugin obfs4-0 exec /usr/bin/obfs4proxy
 ServerTransportPlugin obfs4-1 exec /usr/bin/obfs4proxy

 ServerTransportListenAddr obfs4-0 0.0.0.0:1
 ServerTransportListenAddr obfs4-1 0.0.0.0:2
 }}}

 #11211 is vaguely related in that it aims to add dual stack support for
 bridges so that, say, an obfs4 instance can listen on both an IPv4 and
 IPv6 address. #29285 is also related because it tracks our PT spec
 improvement process and supporting multiple instances of a transport is
 one potential improvement.

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

[tor-bugs] #31227 [Circumvention/Snowflake]: Firefox plugin loses broker connection

2019-07-23 Thread Tor Bug Tracker & Wiki

#31227: Firefox plugin loses broker connection
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:  snowflake-   |  Actual Points:
  webextension   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 When the Firefox proxy add-on is turned on, it establishes a persistent
 tcp connection to the agent at snowflake-broker.bamsoftware.com
 (37.218.240.96). It polls for and occasionally serves clients as expected
 for many hours, up to maybe a day, and then the agent tcp connection is
 somehow dropped, after which it never seems to serve any clients again
 until the state is reset by toggling it off/on or Firefox is restarted,
 then the cycle repeats.

 My browser is normally left running 24/7 with various tabs open, so it
 seems like a perfect Snowflake proxy candidate, but this bug means it
 stops serving clients after the first day or so and doesn't resume until I
 think to toggle the add-on or happen to restart Firefox, which could be
 weeks of lost proxy time.

 The add-on should either fix the problem causing it to drop the
 connection, or perhaps check for the lost connection while polling and
 reset itself as needed.

 Using Firefox 68.0.1 64-bit on Windows 10 with add-on 0.0.5.

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

Re: [tor-bugs] #31200 [Circumvention/Snowflake]: Hand out proxy-go snowflakes more frequently than webextension snowflakes

2019-07-23 Thread Tor Bug Tracker & Wiki

#31200: Hand out proxy-go snowflakes more frequently than webextension 
snowflakes
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25681   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 @cohosh did you change anyhing? I'm seeing a record low number for
 available current snowflakes respective to the 50-70 range that was
 happening just yesterday.

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

Re: [tor-bugs] #30794 [Circumvention/Censorship analysis]: Create lightweight censorship analyser for users

2019-07-23 Thread Tor Bug Tracker & Wiki

#30794: Create lightweight censorship analyser for users
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 I tried it at commit [https://dip.torproject.org/anti-
 censorship/emma/tree/c8924dce26a28193b8478f72941d3b857a24c343
 c8924dce26a28193b8478f72941d3b857a24c343] and got the following output:
 {{{
 Testing TCP port of default bridges.
 reachable: 109.105.109.163:38980
 reachable: 109.105.109.163:47779
 reachable: 109.105.109.165:10527
 reachable: 109.105.109.147:13764
 unreachable: 85.17.30.79:443 (dial tcp 85.17.30.79:443: connect:
 connection refused)
 reachable: 38.229.1.78:80
 reachable: 38.229.33.83:80
 unreachable: [2001:470:b381:bfff:216:3eff:fe23:d6c3]:443 (dial tcp
 [2001:470:b381:bfff:216:3eff:fe23:d6c3]:443: i/o timeout)
 reachable: 192.95.36.142:443
 reachable: 37.218.240.34:40035
 reachable: 37.218.245.14:38224
 reachable: 85.31.186.98:443
 reachable: 85.31.186.26:443
 reachable: 216.252.162.21:46089
 reachable: 144.217.20.138:80
 Testing TCP port of directory authorities.
 reachable: 128.31.0.39:9131
 reachable: [2001:858:2:2:aabb:0:563b:1526]:443
 reachable: 86.59.21.38:80
 reachable: 194.109.206.212:80
 reachable: 66.111.2.131:9030
 reachable: [2001:638:a000:4140:::189]:443
 reachable: 131.188.40.189:80
 reachable: [2001:678:558:1000::244]:443
 reachable: 193.23.244.244:80
 reachable: [2001:67c:289c::9]:80
 reachable: 171.25.193.9:443
 reachable: 154.35.175.225:80
 reachable: 199.58.81.140:80
 reachable: [2620:13:4000:6000::1000:118]:443
 reachable: 204.13.164.118:80
 Testing *.torproject.org domains.
 Everything as expected.
 }}}

 Ideas:
  * If emma.exe is double-clicked on Windows, it may open a terminal
 window, display the output, then close the window again. Perhaps in the
 default configuration, it should append its output (timestamped) to a
 file.
  * For reachability tests, it would be good to show an elapsed time, in
 both the reachable and unreachable case.
  * For the DNS lookups, it would be nice to see what names were resolved.
 This is in case there are multiple versions of the program distributed, so
 we can tell from the output whether the domains included a particular one
 that we care about.

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

Re: [tor-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

2019-07-23 Thread Tor Bug Tracker & Wiki

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Alex, we have a couple of questions about the rebasing process:

 1. Do you want to rebase your rebased patches onto the tip of Mozilla's
 esr68 branch (or a recent tag) before Kathy and I do our rebasing work? I
 think that makes sense unless it turns out to be very time consuming.

 2. Previous attempts to reorder the patches while rebasing have not gone
 well; it would be better if we preserved the order so for example the
 #4234 patch comes before the other updater-related patches such as the
 #16940 one. Is it OK if Kathy and I create a new branch with the rebased
 patches for the following tickets inserted in a similar place within the
 commit stream as for the ESR60 Tor Browser branches: #18900, #13252,
 #19121, #4234, #13379? The only downside that I see is that if you are
 working in parallel with us someone will need to cherry pick some patches
 from our branch along with all of your patches to create a consolidated
 branch (or do something else magical with git).

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

Re: [tor-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

2019-07-23 Thread Tor Bug Tracker & Wiki

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:13 gk]:
 > mcs/brade: to not lose this in the previous wall of text: I thought it
 could be helpful if you'd had a second look at commits
 >
 > 45072c2fea6a535a712ac0888f12f881393cccbd

 R.e. the `char16_t` question: a while ago, Mozilla changed
 `FormatStringFromName()` to take a
 `const char *` so the new code is good.

 R.e. gk's second comment: Kathy and I would prefer to always initialize
 `profileStatus` (seems safer).

 R.e. gk's last comment about possibly adding an another call to
 `CheckProfileWriteAccess()`: we think it is OK to skip this case.

 In the `ProfileErrorDialog()` function, please reinstate the `rv` check
 for the call to `sb->FormatStringFromName()` (I think it was lost during a
 previous rebase).

 In `nsToolkitProfileService::SelectStartupProfile()` the first call to
 `GetProfileByName()` is wrong. We should not be passing a path to that
 function (it looks like the ESR60 patch is wrong too). Instead, once we
 obtain `lf`, we should call `CheckProfileWriteAccess(lf)`. In other words,
 we can remove the entire chunk that contains the first call to
 `GetProfileByName()` as well as a call to
 `CheckProfileWriteAccess(profile)` and
 instead make the second call earlier.

 Also, Mozilla has made several changes to these files since Alex started
 the ESR68 TB rebasing work. Kathy and I would like to take another look at
 the patch after those changes have been accounted for.


 > 9d8ca4380e947c2097d0fd3554b1f3dad20de634

 It looks like event listeners are handled by via the `LEGACY_ACTORS`
 object. See the large comment near the beginning of
 `toolkit/modules/ActorManagerParent.jsm`. If that is correct, we should
 remove the `removeMessageListener()` and `removeEventListener()` calls
 from `browser/actors/AboutTBUpdateChild.jsm`.

 R.e. `isAboutTBUpdate()`, that is replaced by the `matches` property
 within the `LEGACY_ACTORS` object.

 R.e. `BrowserContentHandler.jsm` being moved to `EXTRA_PP_COMPONENTS`:
 that was part of the #4234 patch.

 Otherwise, this looks good. We will need to test it once the other updater
 patches have been rebased.

 > 5269df12586ac7e4e45803a0f1b8c15da9ef529a

 This looks good to us, although testing is required. The reason the
 `EXTRA_PP_JS_MODULES` change appears in this patch is because a similar
 change is included in the #4234 patch (which was applied before this
 patch).

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

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

2019-07-23 Thread Tor Bug Tracker & Wiki

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 just a quick mention that gitlab could solve a request for private wikis
 we had about a year ago: #26714

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

Re: [tor-bugs] #26714 [Internal Services/Tor Sysadmin Team]: Read-restricted wiki

2019-07-23 Thread Tor Bug Tracker & Wiki

#26714: Read-restricted wiki
-+-
 Reporter:  atagar   |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 for what it's worth, i've been using ikiwiki for years now, and i'm not
 really happy with it. it's hard to deploy and kind of slow at generating
 rendered version of pages. its support for private things is basically
 non-existent (as in "out of scope"): you get to make the git repo and
 rendered website private yourself, which isn't a great improvement.

 for my personal website, i'm currently considering a switch to hugo, but
 there are many other static site generators out there that could fit the
 bill.

 in the context of TPI/TPO, however, you might be interested to know that
 we're considering a transition to GitLab and I believe GitLab has support
 for private projects and (therefore?) private wikis. Wikis are just git
 repositories with markdown files in it that get rendered on the website.
 so that could fit this requirement really well. see #30857 for the
 migration project.

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

Re: [tor-bugs] #30920 [Core Tor/Tor]: Detect uint64 overflow in config_parse_units()

2019-07-23 Thread Tor Bug Tracker & Wiki

#30920: Detect uint64 overflow in config_parse_units()
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  easy overflow  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by guigom):

 Replying to [comment:7 teor]:

 Hi teor, #30864 has been merged and I have a couple of questions.

 Nick added a couple of commented out tests in which it is expected for
 config_parse_memunit (and thus config_parse_units) to return 0 instead of
 UINT64_MAX when detecting 64-bit overflow.

 {{{
 // tt_u64_op(config_parse_memunit("2000 TB", ), OP_EQ, 0);
 // tt_assert(!ok);
 }}}

 Is this the expected behavior, or should it fallback to UINT64_MAX?

 

 In case of using the nowrap mul function inside
 unitparse.c:config_parse_units

 `make check-includes` tells that it is forbidden to include muldiv.h
 inside unitparse.c

 Should `lib/intmath/*.h` be appended to confmgt .may_include?

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

Re: [tor-bugs] #30310 [Circumvention/Snowflake]: Snowflake localization

2019-07-23 Thread Tor Bug Tracker & Wiki

#30310: Snowflake localization
-+-
 Reporter:  cohosh   |  Owner:  arlolra
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  l10n, snowflake-webextension, anti-  |  Actual Points:
  censorship-roadmap-august  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-

Comment (by arlolra):

 https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/PluralRules

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

Re: [tor-bugs] #30310 [Circumvention/Snowflake]: Snowflake localization

2019-07-23 Thread Tor Bug Tracker & Wiki

#30310: Snowflake localization
-+-
 Reporter:  cohosh   |  Owner:  arlolra
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  l10n, snowflake-webextension, anti-  |  Actual Points:
  censorship-roadmap-august  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-

Comment (by dcf):

 This implementation looks good.
  * It may be worth doing the `/^__MSG_([^_]*)__$/` HTML replacement
 recursively on every element, to reduce coupling between popup.html and
 popup.js.
  * The popupStatusOn and popupDescOn strings are going to result in
 displays like "1 clients connected" and "Your snowflake has helped 1
 users". Splitting into singular/plural strings isn't enough, because
 Polish and Russian may need more distinctions depending on how it is
 phrased ("1 użytkownik", "2 użytkownicy", "5 użytkowników). We may need
 some custom logic here, something like
{{{
 const numUsersStringEN = (n) => if (n == 1) { return "1 user"; } else {
 return String(n) + " users"; };
 const NUM_USERS_STRING = new Map([
   "en": (n) => numUsersStringEN,
   "fr": (n) => if (n == 1) { return "1 client"; } else { return String(n)
 + " clients"; },
   "pl": (n) => {
 if (n == 1) {
   return "1 użytkownik";
 }
 let d = n % 10;
 if ((d == 2 || d == 3 || d == 4) && n < 10 && n >= 20) {
   return String(n) + " użtkownicy";
 }
 return String(n) + " użytkowników";
   },
 ]);
 function numUsersString(n) {
   return (NUM_USERS_STRING.get(chrome.i18n.getUILanguage()) ||
 numUsersStringEN)(n);
 }
 ...
 popup.setStatusText(chrome.i18n.getMessage('popupStatusOn',
 numUsersString(clients)));
}}}
An alternative is to rephrase the UI so it's less dependent on grammar:
 "Number of users helped: 1".

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

Re: [tor-bugs] #31194 [Metrics/Library]: Upgrade metrics-lib to Debian buster libraries

2019-07-23 Thread Tor Bug Tracker & Wiki

#31194: Upgrade metrics-lib to Debian buster libraries
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31193   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by karsten):

 Hmm, random thought: can you try installing a newer Java version (as in:
 JRE, `java` command, not necessarily JDK/`javac`)? In theory, it shouldn't
 hurt to use a newer Java version, because we're still building for 1.8
 compatibility in `src/build/java/base.xml`. Maybe you could do the upgrade
 in a way that allows a downgrade again, just in case this wasn't 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] #30219 [Metrics/CollecTor]: Add Tom's bandwidth file archive to CollecTor

2019-07-23 Thread Tor Bug Tracker & Wiki

#30219: Add Tom's bandwidth file archive to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me. (I did not run the code but it all looks sensible.)

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

Re: [tor-bugs] #31194 [Metrics/Library]: Upgrade metrics-lib to Debian buster libraries

2019-07-23 Thread Tor Bug Tracker & Wiki

#31194: Upgrade metrics-lib to Debian buster libraries
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31193   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by irl):

 You're right, it is `/usr/share/java/cobertura-2.1.1.jar` but for some
 reason I didn't have that file in my system. An apt remove and apt install
 later and it was back, and now `ant coverage` does something that looks
 more like expected.

 {{{
 [cobertura-report] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See
 COPYRIGHT file
 [cobertura-report] Exception in thread "main"
 java.lang.UnsupportedClassVersionError:
 org/apache/oro/text/regex/MalformedPatternException has been compiled by a
 more recent version of the Java Runtime (class file version 54.0), this
 version of the Java Runtime only recognizes class file versions up to 52.0
 [cobertura-report]  at java.lang.ClassLoader.defineClass1(Native
 Method)
 [cobertura-report]  at
 java.lang.ClassLoader.defineClass(ClassLoader.java:763)
 [cobertura-report]  at
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 [cobertura-report]  at
 java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
 [cobertura-report]  at
 java.net.URLClassLoader.access$100(URLClassLoader.java:74)
 [cobertura-report]  at
 java.net.URLClassLoader$1.run(URLClassLoader.java:369)
 [cobertura-report]  at
 java.net.URLClassLoader$1.run(URLClassLoader.java:363)
 [cobertura-report]  at
 java.security.AccessController.doPrivileged(Native Method)
 [cobertura-report]  at
 java.net.URLClassLoader.findClass(URLClassLoader.java:362)
 [cobertura-report]  at
 java.lang.ClassLoader.loadClass(ClassLoader.java:424)
 [cobertura-report]  at
 sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
 [cobertura-report]  at
 java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 [cobertura-report]  at
 net.sourceforge.cobertura.dsl.Cobertura.(Cobertura.java:61)
 [cobertura-report]  at
 
net.sourceforge.cobertura.reporting.ReportMain.parseArgumentsAndReport(ReportMain.java:91)
 [cobertura-report]  at
 
net.sourceforge.cobertura.reporting.ReportMain.generateReport(ReportMain.java:141)
 [cobertura-report]  at
 net.sourceforge.cobertura.reporting.ReportMain.main(ReportMain.java:151)
 }}}

 ...but it fails

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

Re: [tor-bugs] #25217 [Metrics]: metrics-base: Update checkstyle to debian stable

2019-07-23 Thread Tor Bug Tracker & Wiki

#25217: metrics-base: Update checkstyle to debian stable
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+---
Changes (by karsten):

 * status:  merge_ready => needs_information


Comment:

 Replying to [comment:9 irl]:
 > Ah ok, should have looked at all the tickets first.
 >
 > This looks good to me.

 Great!

 > It is probable that the error is that the antlr version used to build
 the jar in debian was older, and then was later updated without the
 checkstyle jar being rebuilt.
 >
 > I will ask that the jar is rebuilt.

 Oh, does it make sense to wait until this has happened, or should we just
 move ahead, accept the warning, and upgrade if there's a newer checkstyle
 jar around that removes the warning for us? What's your preference?

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

Re: [tor-bugs] #31194 [Metrics/Library]: Upgrade metrics-lib to Debian buster libraries

2019-07-23 Thread Tor Bug Tracker & Wiki

#31194: Upgrade metrics-lib to Debian buster libraries
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31193   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:2 irl]:
 > The two commits look good, all the versions match up with what I see as
 the versions in Debian stable.

 Okay, great, I'll move forward with upgrading our other code bases then.

 > The jar for cobertura looks like it is called "cobertura-annotations-
 api-2.1.1.jar" but I've never actually got that to work so I don't know if
 that's the same jar or not.

 Hmm, I can see two .jar files in the
 [https://packages.debian.org/buster/all/libcobertura-java/filelist
 `libcobertura-java` package]. Why do you think that we need this one, not
 the other?

 And why did you never get that to work? Does `ant coverage` not generate a
 report at `generated/coverage-report/index.html` for you?

 > The installed paths look like:
 >
 > [...]
 >
 > and then I just symlink these into the lib directory.

 That should work, yes.

 > I had a go at using the latest checkstyle, but I also hit the same
 "unable to create root module" error. That might need more digging than we
 have time for right now.

 Let's tackle this one in the other ticket and close this ticket as soon as
 we have resolved the Cobertura questions above.

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

Re: [tor-bugs] #31088 [Core Tor/Tor]: Check IPv4 and IPv6 private addresses in descriptors, first hops, and extends

2019-07-23 Thread Tor Bug Tracker & Wiki

#31088: Check IPv4 and IPv6 private addresses in descriptors, first hops, and
extends
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, tor-client, tor-|  Actual Points:
  dirauth|
Parent ID:  #24403   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I have made the changes.

 Replying to [comment:4 nickm]:
 > Two issues.
 >
 > First, have a look at your checks in circuit_extend(): it will make the
 extend cell get rejected only when *BOTH* of the target addresses are
 internal.  I don't think that's right.

 I fixed it.

 > Second, I see that in dirserv_router_has_valid_address() you're testing
 the address for is_null, but in circuit_extend() you aren't.  What's the
 reasoning there?

 I originally planned to do this in the if statement, but broke off it. I
 decided to remove the is_null check and pushed it also.

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

Re: [tor-bugs] #31154 [Circumvention/Snowflake]: Ideas for hosting Tor Snowflake bridges with changing residential IP addresses?

2019-07-23 Thread Tor Bug Tracker & Wiki

#31154: Ideas for hosting Tor Snowflake bridges with changing residential IP
addresses?
-+---
 Reporter:  subscriptionblocker  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  not a bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by dcf):

 * status:  needs_information => closed
 * resolution:   => not a bug


Comment:

 I think the short answer is: don't worry about making your IP address
 change. If you have a fixed residential IP address, just run a snowflake.
 If some censors find your IP address and block you, that's fine, there are
 other censors that won't block you, so you can still be useful. The model
 is based around the idea that snowflakes (individually) do not need to be
 hard to block.

 And if you set something up so that your IP address ''does'' change, I
 don't think that will cause a problem with any other part of the system.
 Like cohosh says, each interaction with the broker will use whatever your
 current IP address happens to be.

 Cross-linking the Reddit discussion:
 
https://www.reddit.com/r/TOR/comments/ccsamd/ideas_for_hosting_tor_snowflake_bridges_with/

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

Re: [tor-bugs] #31092 [Circumvention/Snowflake]: Specify a location where users can report issues for the Snowflake WebExtension

2019-07-23 Thread Tor Bug Tracker & Wiki

#31092: Specify a location where users can report issues for the Snowflake
WebExtension
-+
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:  #30999   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Looks fixed to me.

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

Re: [tor-bugs] #31140 [Applications/Tor Browser]: Tor Browser for Android 60.8.0 crash on aarch64

2019-07-23 Thread Tor Bug Tracker & Wiki

#31140: Tor Browser for Android 60.8.0 crash on aarch64
--+--
 Reporter:  j3tracey  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by j3tracey):

 Replying to [comment:4 sisbell]:
 > Which device is this failing on? That may give us a better starting
 point to see if there is a workaround.

 Device is a Samsung Galaxy A5 (2017), running LineageOS 14.1 (Android
 7.1.2). Let me know if you need any additional logcat output or anything.

 Replying to [comment:5 cypherpunks]:
 > Where did you find TBA in https://search.f-droid.org/?q=tor=en?

 TBA ships in the Guardian Project repo that comes with F-Droid, not the
 default repo (you can enable it in the settings). I'll note that the
 64-bit build is only listed in the Alpha version of TBA, though both alpha
 and non-alpha list the current version as 60.8.0. I ''think'' these are
 Guardian Project builds, but armv8 isn't listed on the
 [https://guardianproject.info/releases/ Guardian Project listings] nor the
 [https://dist.torproject.org/torbrowser/8.5.4/ Tor Project listings], so I
 don't know where else to find 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] #31072 [Circumvention/Snowflake]: State clearly that the snowflake proxy only connects to a bridge and does not make outcoming traffic to the internet

2019-07-23 Thread Tor Bug Tracker & Wiki

#31072: State clearly that the snowflake proxy only connects to a bridge and 
does
not make outcoming traffic to the internet
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:  #30999   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * status:  needs_review => merge_ready


Comment:

 Works for me.

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

Re: [tor-bugs] #31201 [Circumvention/Snowflake]: Allow webextension users to specify how many resources it uses

2019-07-23 Thread Tor Bug Tracker & Wiki

#31201: Allow webextension users to specify how many resources it uses
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by dcf):

 There's currently some [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/util.js?h=webext-0.0.5#n266 rate-
 limiting code] that's activating using the undocumented
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/init-badge.js?h=webext-0.0.5#n41
 ratelimit] query string parameter. E.g.
 https://snowflake.torproject.org/embed.html?ratelimit=200k. It's not much
 tested and it's not exposed in the WebExtension interface.

 We could have a slider where the bottom is the minimum rate we think is
 useful (less than that and they should just turn it off), and the top is
 "unlimited".
 {{{
 [400 kbps === 100 Mbps == unlimited]
 }}}

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

Re: [tor-bugs] #31088 [Core Tor/Tor]: Check IPv4 and IPv6 private addresses in descriptors, first hops, and extends

2019-07-23 Thread Tor Bug Tracker & Wiki

#31088: Check IPv4 and IPv6 private addresses in descriptors, first hops, and
extends
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, tor-client, tor-|  Actual Points:
  dirauth|
Parent ID:  #24403   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Two issues.

 First, have a look at your checks in circuit_extend(): it will make the
 extend cell get rejected only when *BOTH* of the target addresses are
 internal.  I don't think that's right.

 Second, I see that in dirserv_router_has_valid_address() you're testing
 the address for is_null, but in circuit_extend() you aren't.  What's the
 reasoning there?

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

Re: [tor-bugs] #31040 [Core Tor/Tor]: Stop showing git scripts changes, unless the base is master

2019-07-23 Thread Tor Bug Tracker & Wiki

#31040: Stop showing git scripts changes, unless the base is master
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready
 * keywords:   => asn-merge


Comment:

 looks okay to me

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

Re: [tor-bugs] #24963 [Core Tor/Tor]: dos: Block single hop clients at the intro point

2019-07-23 Thread Tor Bug Tracker & Wiki

#24963: dos: Block single hop clients at the intro point
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor2web, tor-hs,|  implemented
  034-triage-20180328, 034-removed-20180328  |  Actual Points:  0.1
Parent ID:  #24962   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by nickm):

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


Comment:

 Travis seems pleased; merging this 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] #31222 [Circumvention/Snowflake]: Remove/or Improve Tor Browser detection in snowflake.js

2019-07-23 Thread Tor Bug Tracker & Wiki

#31222: Remove/or Improve Tor Browser detection in snowflake.js
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 Replying to [comment:1 cohosh]:
 > I suggest removing the code since it doesn't work, and letting the lack
 of WebRTC support take care of the rest.

 Yes, I think that is a good call.

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

Re: [tor-bugs] #31170 [Circumvention/Snowflake]: Addon Icon looks horrible Firefox Dark Mode.

2019-07-23 Thread Tor Bug Tracker & Wiki

#31170: Addon Icon looks horrible Firefox Dark Mode.
-+--
 Reporter:  knowguy  |  Owner:  dcf
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * status:  assigned => needs_review


Comment:

 Here is a branch that successfully styles the popup in dark mode and
 unsuccessfully tries to set the appropriate toolbar icon in dark mode.
  *
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=darkmode=44882d2b0f598ecddb4612aedcbf76f3b03da911
 darkmode 44882d2b0f]
  *
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=darkmode=44882d2b0f598ecddb4612aedcbf76f3b03da911=f795fb5a3366c80a7ea24c11128366ab39b179f7
 diff against master]

 antonela: It appears that it is not currently possible to set different
 toolbar icons based on the current light/dark mode setting. We may need a
 single set of icons that work in both light mode and dark mode. More
 details below.

 [[Image(popup-light.png)]] [[Image(popup-dark.png)]]

 Styling the popup is pretty easy. There is a new
 [https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-
 scheme prefers-color-scheme] CSS media query that lets us override certain
 styling in dark mode. To enable dark mode:
  * In Firefox 67+, go to about:config and set `ui.systemUsesDarkTheme=1`
 (and optionally `browser.in-content.dark-mode=true`, to make pages like
 about:addons also be dark). Go to https://bugzilla.mozilla.org/ to check
 if it's working (that site has
 [https://hacks.mozilla.org/2019/05/firefox-67-dark-mode-css-webrender/ its
 own dark theme]).
* Note that the `ui.systemUsesDarkTheme` setting is ''independent'' of
 the "Dark theme" that you can set at about:addons. You may ''also'' have
 to enable the Dark theme at about:addons to make the toolbar appear dark.
  * In Chrome 76+, run with the `--force-dark-mode` command-line option. I
 haven't tested this myself because my Chromium is not new enough.

 Changing the toolbar icon is harder. The problem is that while we have
 separate status-on.png and status-on-dark.png images, there is no way
 (that I could find) to test whether dark mode is enabled from the
 WebExtension JavaScript. In Firefox, manifest.json can have a
 [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/manifest.json/browser_action#Syntax theme_icons] with
 separate `"light"` and `"dark"` icons, and
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=darkmode=44882d2b0f598ecddb4612aedcbf76f3b03da911
 I am using it], but the problem is that it only applies at first startup.
 Once the extension starts running, the code controls the icon using
 [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/browserAction/setIcon browserAction.setIcon], and
 here is where I couldn't find a way to detect dark mode. (If you reload
 the extension in dark mode, you can see it use the correct, lighter-color
 icon for a split second before the code takes control.) Here are things I
 tried that didn't work:
  * [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/theme/getCurrent theme.getCurrent()] always returns
 `undefined`. (It's meant for custom extension-set themes, not the built-in
 themes.)
  * By calling `browserAction.setIcon({})`, we could revert back to the
 proper theme-specific `theme_icons` setting, but that only distinguishes
 light and dark mode, not the off/on/running states of the snowflake.
 There's [https://bugzilla.mozilla.org/show_bug.cgi?id=1416871 apparently
 no way] to control the `theme_icons` externally either.
  * There's no `browserAction.getIcon` counterpart to
 `browserAction.getIcon` that would allow us to inspect the filename.
  * Mozilla's own icons use a special SVG `"context-fill"` that changes
 color based on the theme, but
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1394579 it's not allowed]
 for non-Mozilla extensions.
  * More discussion:
* https://discourse.mozilla.org/t/how-to-correctly-design-color-icon-
 to-be-visible-across-themes/27713
* https://discourse.mozilla.org/t/use-theme-colors-for-svg-
 favicons/29165

 tl;dr: Unless I'm missing something, we can't use separate toolbar icons
 for light and dark mode. We need a single set of icons that work in either
 mode. I am picturing something like a semi-transparent white circle behind
 the snowflake that would be almost invisible in light themes, and provide
 the needed contrast in dark themes. That's only for the icons in the

Re: [tor-bugs] #31170 [Circumvention/Snowflake]: Addon Icon looks horrible Firefox Dark Mode.

2019-07-23 Thread Tor Bug Tracker & Wiki

#31170: Addon Icon looks horrible Firefox Dark Mode.
-+--
 Reporter:  knowguy  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "popup-dark.png" added.

 Dark-mode Firefox screenshot of
 
https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=darkmode=44882d2b0f598ecddb4612aedcbf76f3b03da911

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

Re: [tor-bugs] #31170 [Circumvention/Snowflake]: Addon Icon looks horrible Firefox Dark Mode.

2019-07-23 Thread Tor Bug Tracker & Wiki

#31170: Addon Icon looks horrible Firefox Dark Mode.
-+--
 Reporter:  knowguy  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "popup-light.png" added.

 Light-mode Firefox screenshot of
 
https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=darkmode=44882d2b0f598ecddb4612aedcbf76f3b03da911

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-23 Thread Tor Bug Tracker & Wiki

#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 so the two CRM instances talk to each other? i know how redis can be used
 as a message cache, i was just wondering why we were passing messages
 between the two instances if we wanted those to be separate in the first
 place.

 and yes, weasel found out about a crash and quickly fixed it during the
 night (~PDT). we haven't found the cause of the crash this time around
 either and nothing significant showed up in the logs.

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

Re: [tor-bugs] #24963 [Core Tor/Tor]: dos: Block single hop clients at the intro point

2019-07-23 Thread Tor Bug Tracker & Wiki

#24963: dos: Block single hop clients at the intro point
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor2web, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * cc: nickm-merge (added)


Comment:

 Replying to [comment:13 nickm]:
 > The testing fix here is a bit ugly; it's best not to make fake objects
 and bypass the channel_new() interface.
 >
 > Instead, I suggest a change to hs_intropoint.c.  What do you think of
 the branch `ticket24963_042_02` with PR at
 https://github.com/torproject/tor/pull/1188 ?

 Indeed much simpler! Lets go with this! Nick I think you can just go ahead
 and merge this :). Travis is still feeding...

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-23 Thread Tor Bug Tracker & Wiki

#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by peterh):

 It's because we're using Redis as a message broker as well as a key/value
 store. I was surprised the first time I heard of this, too, but tons of
 people use Redis to pass messages between apps. It has a list data
 structure that turns out to be really good for message queues. It's nice
 because it's really lightweight compared to the other message brokers
 which makes it good for this kind of small application.

 It looks like maybe stunnel went down again between about 3AM and 5AM PDT
 today. I'm guessing your new detection thing means you got it back up
 faster? If so, awesome! Anything in the stunnel logs on crm-int-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] #24963 [Core Tor/Tor]: dos: Block single hop clients at the intro point

2019-07-23 Thread Tor Bug Tracker & Wiki

#24963: dos: Block single hop clients at the intro point
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor2web, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by nickm):

 * status:  merge_ready => needs_review


Comment:

 The testing fix here is a bit ugly; it's best not to make fake objects and
 bypass the channel_new() interface.

 Instead, I suggest a change to hs_intropoint.c.  What do you think of the
 branch `ticket24963_042_02` with PR at
 https://github.com/torproject/tor/pull/1188 ?

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

Re: [tor-bugs] #31003 [Core Tor/Tor]: heap-use-after-free src/feature/nodelist/routerlist.c:704 in router_get_by_descriptor_digest

2019-07-23 Thread Tor Bug Tracker & Wiki

#31003: heap-use-after-free src/feature/nodelist/routerlist.c:704 in
router_get_by_descriptor_digest
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crash, tor-hs, 041-backport, |  Actual Points:  .1
  040-backport?, 035-backport?, 041-should?, |
  041-regression?, 041-must, asn-merge   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * cc: asn-merge (removed)
 * cc: asn (added)
 * keywords:
 tor-crash, tor-hs, 041-backport, 040-backport?, 035-backport?,
 041-should?, 041-regression?, 041-must
 =>
 tor-crash, tor-hs, 041-backport, 040-backport?, 035-backport?,
 041-should?, 041-regression?, 041-must, asn-merge


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

Re: [tor-bugs] #31112 [Core Tor/Tor]: remove specified target_hopnum from relay-side machines

2019-07-23 Thread Tor Bug Tracker & Wiki

#31112: remove specified target_hopnum from relay-side machines
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  wtf-pad   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks for the explanation!  Merged to master; not backporting.

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

Re: [tor-bugs] #31098 [Core Tor/Tor]: transition when we send our first padding packet, not on received

2019-07-23 Thread Tor Bug Tracker & Wiki

#31098: transition when we send our first padding packet, not on received
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  041-backport-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 Thanks for the explanation!  Merged to master; not backporting.

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

Re: [tor-bugs] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-23 Thread Tor Bug Tracker & Wiki

#31113: Circuitpadding updated comments
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * keywords:  041-can =>
 * resolution:   => implemented


Comment:

 LGTM too; merged to master.

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

Re: [tor-bugs] #31225 [Webpages/Website]: unindex 2019.tpo from search engines

2019-07-23 Thread Tor Bug Tracker & Wiki

#31225: unindex 2019.tpo from search engines
--+--
 Reporter:  anarcat   |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 This is done. Do we also want to add it to Apache?

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

Re: [tor-bugs] #30942 [Core Tor/Tor]: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.

2019-07-23 Thread Tor Bug Tracker & Wiki

#30942: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-padding  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 One comment. Let me know if doable? Else the code flow does work.

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

Re: [tor-bugs] #31226 [Internal Services/Tor Sysadmin Team]: add validation checks in puppet

2019-07-23 Thread Tor Bug Tracker & Wiki

#31226: add validation checks in puppet
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 some example implementations:

  * https://redmine.koumbit.net/projects/git-hooks, specifically:
* https://redmine.koumbit.net/projects/git-
 hooks/repository/revisions/master/entry/update-verify-puppet-syntax
* https://redmine.koumbit.net/projects/git-
 hooks/repository/revisions/master/entry/pre-receive-check-allowed-
 puppetmodules
* https://redmine.koumbit.net/projects/git-
 hooks/repository/revisions/master/entry/pre-receive-enforce-gpg-signatures
* ... and other hooks: https://redmine.koumbit.net/projects/git-
 hooks/repository
  * https://github.com/drwahl/puppet-git-hooks is more elaborate, but
 unmaintained (since 2017)

 there are probably many others such checks out there...

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

[tor-bugs] #31226 [Internal Services/Tor Sysadmin Team]: add validation checks in puppet

2019-07-23 Thread Tor Bug Tracker & Wiki

#31226: add validation checks in puppet
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 we often do "YOLO" (You Only Live Once) commits in Puppet because of silly
 syntax errors and typos that could be caught by automated systems. even
 just a simple git hook checking for syntax errors in manifests would be an
 improvement, but we could also run tests and so on.

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

Re: [tor-bugs] #31200 [Circumvention/Snowflake]: Hand out proxy-go snowflakes more frequently than webextension snowflakes

2019-07-23 Thread Tor Bug Tracker & Wiki

#31200: Hand out proxy-go snowflakes more frequently than webextension 
snowflakes
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25681   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by dcf):

 A cheap and easy way to do this is to increase `defaultBrokerPollInterval`
 in config.js, while letting proxy-go continue to use a shorter interval.
 Related to #25598.

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

Re: [tor-bugs] #29583 [Core Tor/Tor]: HSv3: Faulty cross-certs in introduction point keys (allows naive onionbalance for v3s)

2019-07-23 Thread Tor Bug Tracker & Wiki

#29583: HSv3: Faulty cross-certs in introduction point keys (allows naive
onionbalance for v3s)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, scaling, onionbalance,   |  Actual Points:
  040-backport, 035-backport, needs-proposal,|
  network-team-roadmap-september, security,  |
  041-longterm, 041-deferred-20190530|
Parent ID:  #26768   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by pili):

 * sponsor:  Sponsor27-must => Sponsor27-can


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

Re: [tor-bugs] #31222 [Circumvention/Snowflake]: Remove/or Improve Tor Browser detection in snowflake.js

2019-07-23 Thread Tor Bug Tracker & Wiki

#31222: Remove/or Improve Tor Browser detection in snowflake.js
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [comment:1 cohosh]:
 > - People seem to be concerned about the safety issues with running
 WebRTC in Tor Browser. Do we have a good understanding of this?

 Yes: the Firefox webrtc code is full of proxy bypass bugs. That is, the
 webrtc code will make network connections that bypass your proxy settings.
 That's why Tor Browser compiles it out: #8178.

 I talked to tjr about the issue at one of the Moz All Handses, and he
 seemed to think it would be a lot of work on the Firefox side to fix.

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

Re: [tor-bugs] #31199 [Internal Services/Tor Sysadmin Team]: Need rpm.torproject.org to host rpm packages for Tor project

2019-07-23 Thread Tor Bug Tracker & Wiki

#31199: Need rpm.torproject.org to host rpm packages for Tor project
-+-
 Reporter:  kushaldas|  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 depends on #31220

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

Re: [tor-bugs] #31052 [Internal Services/Services Admin Team]: Guest accounts in the ticketing system

2019-07-23 Thread Tor Bug Tracker & Wiki

#31052: Guest accounts in the ticketing system
---+-
 Reporter:  gaba   |  Owner:  qbi
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Services Admin Team  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ticket-system-migration|  Actual Points:
Parent ID:  #30857 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by anarcat):

 recaptcha is a plugin, and not mandatory, and we're unlikely to force our
 users into it. but it's true it's strongly dependent on Javascript. I
 think that classifying it as "malware" is a huge overstatement, however.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31225 [Webpages/Website]: unindex 2019.tpo from search engines

2019-07-23 Thread Tor Bug Tracker & Wiki

#31225: unindex 2019.tpo from search engines
--+--
 Reporter:  anarcat   |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 As part of the audit on possibly flooded OpenPGP keys (#31168), we noticed
 that the old website suggests users fetch keys from keyserver. This is a
 problem right now because the keyserver has poisoned keys for TBB, among
 other things.

 During a discussion on the topic, weasel suggest we unindex the archived
 website (2019.torproject.org) from search engine so that people stop
 referencing it. We should also make sure this specific page is not linked
 anywhere in our live documentation, if possible:

 https://2019.www.torproject.org/docs/signing-keys.html.en

 This could be accomplished by a `X-Robots-Tag: noindex` header, or by
 dropping a robots.txt file in the root of the site.

 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] #1851 [Core Tor/Tor]: Learn which bridges can't reach baidu

2019-07-23 Thread Tor Bug Tracker & Wiki

#1851: Learn which bridges can't reach baidu
-+--
 Reporter:  arma |  Owner:  (none)
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  blocking tor-bridge  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * cc: cohosh (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] #31222 [Circumvention/Snowflake]: Remove/or Improve Tor Browser detection in snowflake.js

2019-07-23 Thread Tor Bug Tracker & Wiki

#31222: Remove/or Improve Tor Browser detection in snowflake.js
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * keywords:   => snowflake-webextension


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

Re: [tor-bugs] #31222 [Circumvention/Snowflake]: Remove/or Improve Tor Browser detection in snowflake.js

2019-07-23 Thread Tor Bug Tracker & Wiki

#31222: Remove/or Improve Tor Browser detection in snowflake.js
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 We had a discussion about this at the meeting last week. I think the
 decision was to remove this code since it doesn't work as intended anyway.

 There was also a discussion just now in #tor about this that brought up
 several points:
 - I'm not sure whether Tor Browser is built with webRTC support (see
 https://trac.torproject.org/projects/tor/ticket/25483#comment:49). I just
 tried adding the addon to Tor Browser and got the message
 {{{
 Snowflake is off

 WebRTC feature is not detected.
 }}}
  even though `media.peerconnection.enabled` is set to `true` in
 about:config

 - People seem to be concerned about the safety issues with running WebRTC
 in Tor Browser. Do we have a good understanding of 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] #29398 [Internal Services/Tor Sysadmin Team]: Create a template for requesting infrastructure resources

2019-07-23 Thread Tor Bug Tracker & Wiki

#29398: Create a template for requesting infrastructure resources
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 kushal pointed us to resources from fedora that might be useful here:

  * https://fedoraproject.org/wiki/Request_For_Resources
  * https://infrastructure.fedoraproject.org/infra/docs/docs/sysadmin-
 guide/sops/requestforresources.rst

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

Re: [tor-bugs] #13194 [Core Tor/Tor]: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

2019-07-23 Thread Tor Bug Tracker & Wiki

#13194: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
-+-
 Reporter:  arma |  Owner:  neel
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, needs-design  |  Actual Points:
  privcount-maybe metrics performance|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * status:  needs_review => new
 * sponsor:  SponsorQ-can => Sponsor27-can
 * milestone:  Tor: 0.4.2.x-final => Tor: unspecified


Comment:

 Yeah I will echo teor's questions here and add more.

 I think it is very useful to have this timing but we should get this value
 into a more broad framework that does timing measurements _only_ if
 enabled (torrc or configure or ...).

 Then get that data out differently then `log_info()`... Parsing logs for
 this kind of measurements is really not where we should go.

 It is totally possible that this kind of work (timing measurements) falls
 under s27 work as we are about to start working on this big piece: #30200

 I'm deferring this until we get a clearer picture of where we want to go
 with these type of measurements. But for now, I'm not very keen on merging
 this approach with `log_info()`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31224 [Internal Services/Service - git]: Create new repository for Training Materials

2019-07-23 Thread Tor Bug Tracker & Wiki

#31224: Create new repository for Training Materials
-+
 Reporter:  pili |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor9 |
-+
 We want to have a gitweb repository to hold our training materials.

 We would like to have this available in gitlab also. I have already
 created the project:
 https://dip.torproject.org/torproject/community/training but I realised we
 probably need the repo created in gitweb first...

 We probably need at least gus, emma, antonela and myself to have write
 access to this repo.

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

Re: [tor-bugs] #31214 [Internal Services/Tor Sysadmin Team]: audit account-keyring

2019-07-23 Thread Tor Bug Tracker & Wiki

#31214: audit account-keyring
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> Look at all the keys in account-keyring, for each key:
>
>  1. if the account is locked in LDAP, remove the key
>  2. if the key is expired, consider locking it in LDAP

New description:

 Look at all the keys in account-keyring, for each key:

  1. if the account is locked in LDAP, remove the key
  2. if the key is expired, consider locking it in LDAP

 Consider automating this, or at least make it so automation wouldn't be
 harder, see #29671.

--

Comment (by anarcat):

 mention keyring management issue

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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

2019-07-23 Thread Tor Bug Tracker & Wiki

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:16 neel]:
 > I have a new PR on a different branch here:
 https://github.com/torproject/tor/pull/1161

 I don't think this will work as expected.

 First, I believe this is only a v2 problem because in v3, when picking an
 intro point from the descriptor, we do _not_ pick unusable IPs.

 Where with v2, this check is not done when picking the intro point but
 rather when sending the INTRO cell. Problem lies with
 `rend_client_any_intro_points_usable()` I believe because it select a new
 intro point and only checks at `ip->timed_out` and not the failure cache.

 Once a NACK arrives, the v2 code actually removes the intro point from the
 parsed descriptor so we can't even check the IP object for an error. We
 really need to query the failure cache.

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

Re: [tor-bugs] #27385 [Circumvention/Snowflake]: https://snowflake.torproject.org/embed is confusing

2019-07-23 Thread Tor Bug Tracker & Wiki

#27385: https://snowflake.torproject.org/embed is confusing
-+-
 Reporter:  cypherpunks3 |  Owner:  arlolra
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Major| Resolution:
 Keywords:  snowflake, ux-team, anti-|  Actual Points:
  censorship-roadmap-july|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by arlolra):

 * cc: cohosh (added)


Comment:

 > It's rather invasive and doesn't offer much in terms of explanation,
 sorry.

 Ok, looking this over, the goal was to,

 * reuse the html and css from the webextension for the badge
 * move setting the cookie over to the badge, using the on/off toggle (as
 suggested in this ticket)
 * consolidate the use specific code in one place (init, ui, etc)

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

Re: [tor-bugs] #31003 [Core Tor/Tor]: heap-use-after-free src/feature/nodelist/routerlist.c:704 in router_get_by_descriptor_digest

2019-07-23 Thread Tor Bug Tracker & Wiki

#31003: heap-use-after-free src/feature/nodelist/routerlist.c:704 in
router_get_by_descriptor_digest
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crash, tor-hs, 041-backport, |  Actual Points:  .1
  040-backport?, 035-backport?, 041-should?, |
  041-regression?, 041-must  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * cc: asn-merge (added)
 * status:  needs_review => merge_ready


Comment:

 Minimal fix looks good to me. I do strongly recommend backport here. Until
 then, go for 041 + master.

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

Re: [tor-bugs] #30864 [Core Tor/Tor]: Move variable manipulation code out of confparse.c

2019-07-23 Thread Tor Bug Tracker & Wiki

#30864: Move variable manipulation code out of confparse.c
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  dgoulet-merge  |  Actual Points:  3
Parent ID:  #29211 | Points:  1
 Reviewer:  catalyst   |Sponsor:  Sponsor31-can
---+
Changes (by dgoulet):

 * 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] #31025 [Core Tor/Tor]: Coverity is confused by switch statement in siphash24 implementation

2019-07-23 Thread Tor Bug Tracker & Wiki

#31025: Coverity is confused by switch statement in siphash24 implementation
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  coverity dgoulet-merge  |  Actual Points:  .1
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by dgoulet):

 * 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] #29280 [Core Tor/Tor]: Use Chutney in Tor's CI

2019-07-23 Thread Tor Bug Tracker & Wiki

#29280: Use Chutney in Tor's CI
-+-
 Reporter:  cohosh   |  Owner:  teor
 Type:  task | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs, 029-backport,   |  Actual Points:  2
  035-backport, 040-backport, network-team-  |
  roadmap-2019-Q1Q2, reviewer-was-   |
  teor-20190422, tor-ci, 041-deferred-20190530,  |
  dgoulet-merge  |
Parent ID:  #29267   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19
-+-
Changes (by dgoulet):

 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.0.x-final


Comment:

 Merged in 041 and master. Moving to 040 for 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] #31221 [Core Tor/Tor]: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111

2019-07-23 Thread Tor Bug Tracker & Wiki

#31221: Line unexpectedly reached at channel_tls_handle_cell at
../src/core/or/channeltls.c:
--+
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #31136 [Core Tor/Tor]: tor_bug_occurred_() channel_tls_handle_cell: This line should not have been reached.

2019-07-23 Thread Tor Bug Tracker & Wiki

#31136: tor_bug_occurred_() channel_tls_handle_cell: This line should not have 
been
reached.
-+-
 Reporter:  fingau   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-channel,  |  Actual Points:
  041-backport 040-backport 035-backport |
Parent ID:  #31107   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 See also #31221, a possible duplicate.

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

Re: [tor-bugs] #25217 [Metrics]: metrics-base: Update checkstyle to debian stable

2019-07-23 Thread Tor Bug Tracker & Wiki

#25217: metrics-base: Update checkstyle to debian stable
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Ah ok, should have looked at all the tickets first.

 This looks good to me.

 It is probable that the error is that the antlr version used to build the
 jar in debian was older, and then was later updated without the checkstyle
 jar being rebuilt.

 I will ask that the jar is rebuilt.

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

Re: [tor-bugs] #31194 [Metrics/Library]: Upgrade metrics-lib to Debian buster libraries

2019-07-23 Thread Tor Bug Tracker & Wiki

#31194: Upgrade metrics-lib to Debian buster libraries
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31193   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 The two commits look good, all the versions match up with what I see as
 the versions in Debian stable.

 The jar for cobertura looks like it is called "cobertura-annotations-
 api-2.1.1.jar" but I've never actually got that to work so I don't know if
 that's the same jar or not.

 The installed paths look like:

 {{{
 /usr/share/java/asm4-5.0.4.jar
 /usr/share/java/asm4-analysis-5.0.4.jar
 /usr/share/java/asm4-commons-5.0.4.jar
 /usr/share/java/asm4-tree-5.0.4.jar
 /usr/share/java/asm4-util-5.0.4.jar
 /usr/share/java/checkstyle-8.15.jar
 /usr/share/java/cobertura-annotations-api-2.1.1.jar
 /usr/share/java/commons-codec-1.11.jar
 /usr/share/java/commons-compress-1.18.jar
 /usr/share/java/commons-lang3-3.8.jar
 /usr/share/java/hamcrest-all-1.3.jar
 /usr/share/java/jackson-annotations-2.9.8.jar
 /usr/share/java/jackson-core-2.9.8.jar
 /usr/share/java/jackson-databind-2.9.8.jar
 /usr/share/java/junit4-4.12.jar
 /usr/share/java/logback-classic-1.2.3.jar
 /usr/share/java/logback-core-1.2.3.jar
 /usr/share/java/oro-2.0.8.jar
 /usr/share/java/slf4j-api-1.7.25.jar
 /usr/share/java/xz-1.8.jar
 }}}

 and then I just symlink these into the lib directory.

 I had a go at using the latest checkstyle, but I also hit the same "unable
 to create root module" error. That might need more digging than we have
 time for right 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] #31218 [Internal Services/Tor Sysadmin Team]: document archive-01 luks passphrase

2019-07-23 Thread Tor Bug Tracker & Wiki

#31218: document archive-01 luks passphrase
-+-
 Reporter:  weasel   |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 anarcat figured out that we had that info in our git at some point, but an
 editing snafu by me dropped that info.  all restored.

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

Re: [tor-bugs] #31223 [Core Tor/Tor]: Research approaches for improving the availability of services under DoS

2019-07-23 Thread Tor Bug Tracker & Wiki

#31223: Research approaches for improving the availability of services under DoS
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  #2  | Points:  15
 Reviewer:  |Sponsor:  Sponsor27-must
+
Changes (by asn):

 * parent:   => #2


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

Re: [tor-bugs] #31223 [Core Tor/Tor]: Research approaches for improving the availability of services under DoS

2019-07-23 Thread Tor Bug Tracker & Wiki

#31223: Research approaches for improving the availability of services under DoS
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  | Points:  15
 Reviewer:  |Sponsor:  Sponsor27-must
+

Comment (by asn):

 Also see related thread: https://lists.torproject.org/pipermail/tor-
 dev/2019-June/013882.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

[tor-bugs] #31223 [Core Tor/Tor]: Research approaches for improving the availability of services under DoS

2019-07-23 Thread Tor Bug Tracker & Wiki

#31223: Research approaches for improving the availability of services under DoS
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  tor-hs tor-dos
Actual Points:  |  Parent ID:
   Points:  15  |   Reviewer:
  Sponsor:  Sponsor27-must  |
+
 We've been improving the health of the network during onion service DoS,
 but not the onion service availability. This is a task for looking at this
 angle.

 During the related Stockholm session we looked into various approaches
 that could help us towards that goal. Here are some of them:

 - Introducing application-layer anonymous tokens that allow legit clients
 to get priority over DoS attacker
 - PoW approaches like argon2
 - CAPTCHA approaches like introducing a token server giving reCAPTCHA
 tokens
 - Hiding introduction points by rate limiting how quickly clients can find
 them. Valet nodes?
 - Having intros check that clients don't use the same IP over and over.
 Proof-of-existence?
 - Pay bitcoin to introduce

 Each of the above solutions has problems and this is a ticket to
 investigate at least the most promising of them, and attempt to move
 forward with something.

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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed

2019-07-23 Thread Tor Bug Tracker & Wiki

#30992: circpadding: Circsetup machines give out warnings when client-side intro
gets NACKed
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.4.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  wtf-pad circpad 041-should  |  Actual Points:
Parent ID:  | Points:  0.4
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Thanks for the logs.

 Can't quite figure it out. Maybe it has something to do with the mark for
 close right above? But these logs seem so high-velocity that it's not easy
 to correlate 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

[tor-bugs] #31222 [Circumvention/Snowflake]: Remove/or Improve Tor Browser detection in snowflake.js

2019-07-23 Thread Tor Bug Tracker & Wiki

#31222: Remove/or Improve Tor Browser detection in snowflake.js
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Right now the code seems to be outdated,

 {{{
 Util.TBB_UAS = [
   'Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0',
   'Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0',
   'Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0',
   'Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0'
 ];
 }}}

 Nowadays people enabling RFP in Firefox will get the same UA as TB, so
 using the UA alone is not sufficient. I suggest either removing this
 (snowflake won't work either way, it's better to just say that WebRTC is
 disabled) or improving it with some other heuristic for detecting TB.

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

Re: [tor-bugs] #31112 [Core Tor/Tor]: remove specified target_hopnum from relay-side machines

2019-07-23 Thread Tor Bug Tracker & Wiki

#31112: remove specified target_hopnum from relay-side machines
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * keywords:   => wtf-pad
 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final


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

Re: [tor-bugs] #31098 [Core Tor/Tor]: transition when we send our first padding packet, not on received

2019-07-23 Thread Tor Bug Tracker & Wiki

#31098: transition when we send our first padding packet, not on received
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  041-backport-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by asn):

 * keywords:  041-backport-maybe 041-should => 041-backport-maybe


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

Re: [tor-bugs] #31098 [Core Tor/Tor]: transition when we send our first padding packet, not on received

2019-07-23 Thread Tor Bug Tracker & Wiki

#31098: transition when we send our first padding packet, not on received
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  041-backport-maybe 041-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by asn):

 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final


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

Re: [tor-bugs] #30942 [Core Tor/Tor]: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.

2019-07-23 Thread Tor Bug Tracker & Wiki

#30942: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-padding  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  new => needs_review


Comment:

 Here is an attempt at this which I have not tested on the real network:
 https://github.com/torproject/tor/pull/1187

 Some refactoring had to take place for this change to be more easily
 reviewable and to reduce technical debt.

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

Re: [tor-bugs] #31168 [Webpages/Website]: audit openpgp keys for flooding

2019-07-23 Thread Tor Bug Tracker & Wiki

#31168: audit openpgp keys for flooding
--+
 Reporter:  anarcat   |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by emmapeel):

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


Comment:

 merged, 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

[tor-bugs] #31221 [Core Tor/Tor]: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111

2019-07-23 Thread Tor Bug Tracker & Wiki

#31221: Line unexpectedly reached at channel_tls_handle_cell at
../src/core/or/channeltls.c:
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 via https://bugs.debian.org/932789

 might be a duplicate of #31136.

 {{{
 +---
 | Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at
 ../src/core/or/channeltls.c:. Stack trace: (on Tor 0.3.5.8
 +)
 | Tor[2185]: Bug: /usr/bin/tor(log_backtrace_impl+0x46)
 [0x55d7f7455aa6] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(tor_bug_occurred_+0xc0)
 [0x55d7f74511c0] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a)
 [0x55d7f72db71a] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(+0x9a16a) [0x55d7f72ff16a] (on Tor
 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(connection_handle_read+0x99d)
 [0x55d7f72c918d] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(+0x69ebe) [0x55d7f72ceebe] (on Tor
 0.3.5.8 )
 | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba)
 [0x7fe17bc599ba] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe17bc5a537] (on Tor
 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(do_main_loop+0xb0) [0x55d7f72d0290] (on
 Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x55d7f72be0d5]
 (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55d7f72bb30a] (on Tor
 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(main+0x19) [0x55d7f72baec9] (on Tor
 0.3.5.8 )
 | Tor[2185]: Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe17b53b09b] (on Tor 0.3.5.8 )
 | Tor[2185]: Bug: /usr/bin/tor(_start+0x2a) [0x55d7f72baf1a] (on Tor
 0.3.5.8 )
 +---

 (on a Debian buster system)
 }}}

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

Re: [tor-bugs] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-23 Thread Tor Bug Tracker & Wiki

#31113: Circuitpadding updated comments
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  041-can   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  needs_revision => 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] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-23 Thread Tor Bug Tracker & Wiki

#31113: Circuitpadding updated comments
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  041-can   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final


Comment:

 I added a changes file and fixed the trailing whitespace over here:
 https://github.com/torproject/tor/pull/1186

 I'm moving this to 042 since it's just documentation improvements.

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

Re: [tor-bugs] #24964 [Core Tor/Tor]: dos: Block single hop client at the HSDir

2019-07-23 Thread Tor Bug Tracker & Wiki

#24964: dos: Block single hop client at the HSDir
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor2web, tor-hs, network-   |  Actual Points:  0.4
  team-roadmap-july  |
Parent ID:  #24962   | Points:  0.1
 Reviewer:  teor |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * reviewer:  asn => teor


Comment:

 I'm officially passing this over to teor as discussed in net team meeting.
 Tim please feel free to pass me any of your review tickets. Cheers.

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

Re: [tor-bugs] #30578 [Core Tor/Tor]: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___?

2019-07-23 Thread Tor Bug Tracker & Wiki

#30578: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-
document, or ___?
-+-
 Reporter:  nickm|  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  circuitpadding, hopefully-easy,  |  Actual Points:
  wtf-pad|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * keywords:  circuitpadding, 041-should, hopefully-easy, wtf-pad =>
 circuitpadding, hopefully-easy, wtf-pad
 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final


Comment:

 I suggest we defer this to 042 since Mike's attempt did not make it work
 properly.

 If we don't want to have this disabled test in 041 whatsoever, then feel
 free to apply my branch from comment:5 in 041, and we can try to fix the
 test in 042.

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

Re: [tor-bugs] #30649 [Core Tor/Tor]: Every few hours, relays [warn] Received circuit padding stop command for unknown machine.

2019-07-23 Thread Tor Bug Tracker & Wiki

#30649: Every few hours, relays [warn] Received circuit padding stop command for
unknown machine.
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  040-backport, tor-relay, |  Actual Points:
  circuitpadding, wtf-pad|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * status:  needs_revision => merge_ready


Comment:

 OK, pushed a better backport 040 PR. If CI passes, this can be 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] #31002 [Core Tor/Tor]: circpadding: Middle node did not accept our padding request

2019-07-23 Thread Tor Bug Tracker & Wiki

#31002: circpadding: Middle node did not accept our padding request
-+-
 Reporter:  dgoulet  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circpadding, 041-backport,   |  Actual Points:
  041-deferred-20190719  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * keywords:
 tor-circpadding, 041-backport, 041-should?, 041-must?, 041-regression,
 041-deferred-20190719
 => tor-circpadding, 041-backport, 041-deferred-20190719


Comment:

 Mike took a look at this during PETS and I don't think he considers it a
 serious bug. The warning has also been downgraded to protocol warn in 041
 as part of #30649.

 I leave the ticket open so that Mike can summarize what he found out in
 case it's a bug that needs to be fixed, but I'm removing it from the 041
 milestone.

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

Re: [tor-bugs] #31098 [Core Tor/Tor]: transition when we send our first padding packet, not on received

2019-07-23 Thread Tor Bug Tracker & Wiki

#31098: transition when we send our first padding packet, not on received
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  041-backport-maybe 041-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by asn):

 * status:  needs_revision => 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] #31220 [Internal Services/Tor Sysadmin Team]: Please create LDAP account for kushal

2019-07-23 Thread Tor Bug Tracker & Wiki

#31220: Please create LDAP account for kushal
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by hiro:

Old description:

> {{{
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Please create an LDAP account for Kushal so he can start helping the
> sysadmin team with some rpm-fu
>
> Desired username: kushal
> forward address: kushal@freedom.press
> Key fingerprint = A85F F376 759C 994A 8A11  68D8 D821 9C8C 43F6 C5E1
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEaGTHNK2XKVf+k4hmo4Ql8XZ7tnwFAl02zXgACgkQo4Ql8XZ7
> tnyiGg/9Gt8YDsrhu4MiT63lcMEg2z7wpA+9Y4Wxc9gfBwtVGr8YuR0Ca1CGtuK8
> A+AUKIregct5Yiy4Cz/tLtv3pAT78SD5CpF95+gBfwcx5k3VUVDGgsJ9wpTwU4wx
> h+6pJapWKpJHOyEbDrK2lNOuBjF4e+9f+VdvPm14AhbvXNS/oHEDZ/30OEjfNnLj
> b61QWVyC02Qk27s+B0uUaNQc82rhMOQ3MggMjnOJFKogZA+CgfedBN7ANkvsSvxr
> 8KRYZBYLCwamzNVuDMJxyRDDwjmedpw1OiTerPrv6lFu5QdM8OXOuzz10vj8MR5T
> QQS+/goi7tNkxd7OgqMp3zrDXMSzYCCpqWfTY5ZG1D9rSJHqhsgSU4WY4QCBU3Ky
> Iq4cXkunuECSBWtR/OsU8qnTF+zXqkB/AxXVyDwU9t8CqtM5hgDUZrYFC/8xLgdv
> BV2vCLbRnee+R4R0/b0/jz4vnr4CwDmBZqUFkhFYLrMVtyo5G27wFBvtqWGAjlhJ
> IlJV+mnYExQaZBT5780zrL+smE1cIhm5ZxLQtwTOwlmVVvnznDkgI8+oHXeR0f5i
> tAn5KSRyubkBNNYDhn0ciSCnvQQURHQCcdYz0VE53QjnREm0HiE4FJ7nRIO8tTE0
> wfkY8j/0wlGEcxUW8+7H2IqIQCXvJxMadzVtJFzAbKdOXACpkNM=
> =0X6+
> -END PGP SIGNATURE-
>

> 
> }}}

New description:

 {{{

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please create an LDAP account for Kushal so he can start helping the
 sysadmin team with some rpm-fu

 Desired username: kushal
 forward address: m...@kushaldas.in
 Key fingerprint = A85F F376 759C 994A 8A11  68D8 D821 9C8C 43F6 C5E1
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEEaGTHNK2XKVf+k4hmo4Ql8XZ7tnwFAl02zj8ACgkQo4Ql8XZ7
 tnx9RQ//QLDnjMkFWS3FQneCRe7eWb2tbfahhCKB+ygvVtUjnm7mop4jJL94UKyZ
 +hQqyIsY2JVRVpDvP8bN+MKyHrh0ghvfXcUlIRBLsBjXoZQGKe+WTInZ4Xpqqq/O
 tiVaACn2SJdXn1Ra6/skbFM8o0ucBFY2dYkYDH/HbDET0V4GyRfTwSWXW0fxJaUn
 GWP6qffLEpbAgfOb3iQ9Q351T5ULKLlmlmNiP6Y6/R1bg2MiMKcEf9NL82Mnu+mt
 ZLWKCGZxCVoElRHBruCi6JRLG4k28uuiN0jrmmH2VoxO3ukOnMHHsRilYyMprOkX
 kcTmhD4ROQP38MI06VKqV68jB1/5RfMxKUkIiTI6rhkY87I/Ugto4WDz5LH0n5kA
 2ZuyZuD1d/A8ZvzuT+l4Q4ZURmdmR8c+mCXwaeH94v3eHTjJR0hki5jAbTkpfbAV
 FD0/hSiffIhW9sEvI1v3fM4HW4dfumJViSTlXJ6UaqNx1Nyh6d3MDI6xaM3ZwcWq
 BjdEqsWOMV5Otd73Z1se09Btw6XdUTX3XTPLB1ZsYamXImHVgarD+N+WoFMsH9tV
 Dp7UWrS2KCwiY7cdSfiYMjEbAD/lhQVgNH3E4t8wB+6y2KzSSQL80CnIjGeHNGlQ
 FqsyKtLoGyxaIyqRsSKAkRkZIkzlIUA1I1RRQX58oUQa8bZgTww=
 =AVKf
 -END PGP SIGNATURE-


 }}}

--

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

Re: [tor-bugs] #31098 [Core Tor/Tor]: transition when we send our first padding packet, not on received

2019-07-23 Thread Tor Bug Tracker & Wiki

#31098: transition when we send our first padding packet, not on received
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  041-backport-maybe 041-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by asn):

 Similarly to #31112 this is tested by running the padanalyzer script and
 making sure that it pads properly. This should not change the behavior of
 wtf-pad, and hence it's not really a bugfix so I think it can go in
 master.

 You can find it along with #31112 and a changes file in
 https://github.com/torproject/tor/pull/1185 .

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

Re: [tor-bugs] #31220 [Internal Services/Tor Sysadmin Team]: Please create LDAP account for kushal

2019-07-23 Thread Tor Bug Tracker & Wiki

#31220: Please create LDAP account for kushal
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by hiro:

Old description:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Please create an LDAP account for Kushal so he can start helping the
> sysadmin team
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEaGTHNK2XKVf+k4hmo4Ql8XZ7tnwFAl02ykYACgkQo4Ql8XZ7
> tnwITRAAu8MqJ/gHWdk1JH4HBMkcgrvB9GWIjz9ck91+3nC2e5hHw3F9fO8naYLf
> azG98xhLf7+AqMnx1e5Fc8vlqn/e6QGBT7jHBbqvxHa+g5o8hubbDVMwwzDKnQBN
> xke5GmtJXAWQy+WI73mqjCZ90tcRDOtg0197xeuiLeK6V4aMImJphd6WsF4IRBaN
> sHNMPa68IYKJRNbONJY1R62IaKz2wm0oHu3Gd6tcexulzbP2MsMCmexYF2jy5e4y
> etz+l+vH1Z8a9YLkUEz2Fr8qOCxi2Nx9wcTljcawkVtp/s/sOMeK/9eXfpdjZwLx
> kpT/7oyLeaL+Dso1sXGMfVP7dAujDw49DCgDvU3PTwmfaUw/YHWToWI8dAk8fm+R
> +BXo8g/lBe1mMiEDW6I69QPWUDOZvP/IOQNSpC2e1IMFng5gPoMftb+9aW1XPVis
> CRvFzOujqC7qSh1eGyvDN60M3qKGNLqctMXCRJccbLSh2xGjL1HGyqMM5Zl2mJ7H
> 1KydPMIkmNlV/E0DIpgmzKhOkooBdnfeKXlo5AVegRwctUYjmoQ7nAfpt0yBKe0o
> 9UgW/ZGDYNo5SgxTV9X4S8tWiEFbDFx6/IUEEn7kC+9EoXeRYXuL+qJyNi82AGdT
> U9aCP1n51f9PGDEdbEY+4T/HeB+r5gpmbv3n3QmoLQJxZrHiQbo=
> =eu0o
> -END PGP SIGNATURE-

New description:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please create an LDAP account for Kushal so he can start helping the
 sysadmin team with some rpm-fu

 Desired username: kushal
 forward address: kushal@freedom.press
 Key fingerprint = A85F F376 759C 994A 8A11  68D8 D821 9C8C 43F6 C5E1
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEEaGTHNK2XKVf+k4hmo4Ql8XZ7tnwFAl02zXgACgkQo4Ql8XZ7
 tnyiGg/9Gt8YDsrhu4MiT63lcMEg2z7wpA+9Y4Wxc9gfBwtVGr8YuR0Ca1CGtuK8
 A+AUKIregct5Yiy4Cz/tLtv3pAT78SD5CpF95+gBfwcx5k3VUVDGgsJ9wpTwU4wx
 h+6pJapWKpJHOyEbDrK2lNOuBjF4e+9f+VdvPm14AhbvXNS/oHEDZ/30OEjfNnLj
 b61QWVyC02Qk27s+B0uUaNQc82rhMOQ3MggMjnOJFKogZA+CgfedBN7ANkvsSvxr
 8KRYZBYLCwamzNVuDMJxyRDDwjmedpw1OiTerPrv6lFu5QdM8OXOuzz10vj8MR5T
 QQS+/goi7tNkxd7OgqMp3zrDXMSzYCCpqWfTY5ZG1D9rSJHqhsgSU4WY4QCBU3Ky
 Iq4cXkunuECSBWtR/OsU8qnTF+zXqkB/AxXVyDwU9t8CqtM5hgDUZrYFC/8xLgdv
 BV2vCLbRnee+R4R0/b0/jz4vnr4CwDmBZqUFkhFYLrMVtyo5G27wFBvtqWGAjlhJ
 IlJV+mnYExQaZBT5780zrL+smE1cIhm5ZxLQtwTOwlmVVvnznDkgI8+oHXeR0f5i
 tAn5KSRyubkBNNYDhn0ciSCnvQQURHQCcdYz0VE53QjnREm0HiE4FJ7nRIO8tTE0
 wfkY8j/0wlGEcxUW8+7H2IqIQCXvJxMadzVtJFzAbKdOXACpkNM=
 =0X6+
 -END PGP SIGNATURE-


 
 }}}

--

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

Re: [tor-bugs] #31112 [Core Tor/Tor]: remove specified target_hopnum from relay-side machines

2019-07-23 Thread Tor Bug Tracker & Wiki

#31112: remove specified target_hopnum from relay-side machines
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Hello. This is tested by running the usual padanalyzer script and making
 sure that the machines pad effectively. I don't think it presents any
 stability risk (which can also be verified with code reading) and it
 should go into 041.

 You can find it along with #31098 and a changes file in
 https://github.com/torproject/tor/pull/1185 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31220 [Internal Services/Tor Sysadmin Team]: Please create LDAP account for kushal

2019-07-23 Thread Tor Bug Tracker & Wiki

#31220: Please create LDAP account for kushal
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please create an LDAP account for Kushal so he can start helping the
 sysadmin team
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEEaGTHNK2XKVf+k4hmo4Ql8XZ7tnwFAl02ykYACgkQo4Ql8XZ7
 tnwITRAAu8MqJ/gHWdk1JH4HBMkcgrvB9GWIjz9ck91+3nC2e5hHw3F9fO8naYLf
 azG98xhLf7+AqMnx1e5Fc8vlqn/e6QGBT7jHBbqvxHa+g5o8hubbDVMwwzDKnQBN
 xke5GmtJXAWQy+WI73mqjCZ90tcRDOtg0197xeuiLeK6V4aMImJphd6WsF4IRBaN
 sHNMPa68IYKJRNbONJY1R62IaKz2wm0oHu3Gd6tcexulzbP2MsMCmexYF2jy5e4y
 etz+l+vH1Z8a9YLkUEz2Fr8qOCxi2Nx9wcTljcawkVtp/s/sOMeK/9eXfpdjZwLx
 kpT/7oyLeaL+Dso1sXGMfVP7dAujDw49DCgDvU3PTwmfaUw/YHWToWI8dAk8fm+R
 +BXo8g/lBe1mMiEDW6I69QPWUDOZvP/IOQNSpC2e1IMFng5gPoMftb+9aW1XPVis
 CRvFzOujqC7qSh1eGyvDN60M3qKGNLqctMXCRJccbLSh2xGjL1HGyqMM5Zl2mJ7H
 1KydPMIkmNlV/E0DIpgmzKhOkooBdnfeKXlo5AVegRwctUYjmoQ7nAfpt0yBKe0o
 9UgW/ZGDYNo5SgxTV9X4S8tWiEFbDFx6/IUEEn7kC+9EoXeRYXuL+qJyNi82AGdT
 U9aCP1n51f9PGDEdbEY+4T/HeB+r5gpmbv3n3QmoLQJxZrHiQbo=
 =eu0o
 -END PGP SIGNATURE-

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31219 [Core Tor]: Nautilus-S - FSB contractor project to spy on tor users

2019-07-23 Thread Tor Bug Tracker & Wiki

#31219: Nautilus-S - FSB contractor project to spy on tor users
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 https://gizmodo.com/hackers-reportedly-break-into-sytech-a-contractor-
 for-1836584241

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

96 matches

Mail list logo