Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:04:33Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34142Integrate reprocessing mode into analysis mode2020-06-13T18:04:33ZKarsten LoesingIntegrate reprocessing mode into analysis modeWhen we added the _reprocess_ mode a while back, we should have tried harder to add that functionality as part of the existing _analyze_ mode which does almost the same.
Right now, the reprocessing module is a wrapper on top of the curr...When we added the _reprocess_ mode a while back, we should have tried harder to add that functionality as part of the existing _analyze_ mode which does almost the same.
Right now, the reprocessing module is a wrapper on top of the current analyze mode. It matches log files, has filtering capabilities, and multi-processes the jobs in a pool.
Maybe it's as simple as accepting a directory where we accept a single file right now.
First step here is to brainstorm possible user interface changes and discuss them here. Coding will be step two.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34141Stop generating .tpf files2020-06-13T18:04:33ZKarsten LoesingStop generating .tpf filesAs of last week, CollecTor, metrics-lib, and metrics-web all know how to process OnionPerf's .json files. Unless anything else uses .tpf files we can now stop generating those.
Suggested process:
- Discuss any remaining uses of .tpf fi...As of last week, CollecTor, metrics-lib, and metrics-web all know how to process OnionPerf's .json files. Unless anything else uses .tpf files we can now stop generating those.
Suggested process:
- Discuss any remaining uses of .tpf files where .json files are not yet supported.
- Stop generating .tpf files on deployed instances op-{hk,nl,us}2, and if somebody complains, re-generate them from existing log files until they have switched.
- Remove the code that generates .tpf files from OnionPerf.https://gitlab.torproject.org/legacy/trac/-/issues/34140Require semicolons2020-06-13T18:22:06ZArlo BreaultRequire semicolonshttps://eslint.org/docs/rules/semi
From https://github.com/arlolra/snowflake-webext/commit/d0fc6aa10cc6a8cc85b9037d780e53282ae83bea#r38995051https://eslint.org/docs/rules/semi
From https://github.com/arlolra/snowflake-webext/commit/d0fc6aa10cc6a8cc85b9037d780e53282ae83bea#r38995051https://gitlab.torproject.org/legacy/trac/-/issues/34139Build Tor without warnings or test failures with OpenSSL 3.0.02020-06-13T15:53:30ZNick MathewsonBuild Tor without warnings or test failures with OpenSSL 3.0.0According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still poss...According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still possible to build Tor with it, but you get a lot of deprecated-item warnings. We should fix those warnings before OpenSSL 3 is released.
Further, if we build without fatal warnings, there are some test failures. We should see if they are tor bugs or new openssl bugs, and fix them in the first case or report them in the second.
I don't think we necessarily need to backport this: OpenSSL 1.1 will be supported until 2023-09-11 [release-strat], whereas support for 0.3.5 is scheduled to end on 2020-02-02.
[release-strat] https://www.openssl.org/policies/releasestrat.html
[openssl-3] https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34138Replace to better captcha2020-06-13T17:02:06ZTracReplace to better captchabridges.tpo(big, readable) is much better than trac.tpo's captcha(colorful, small, hard to read).
It is very hard to read if you have eye problem with a color of computer screen.
Could you replace trac's captcha to bridge's one to resol...bridges.tpo(big, readable) is much better than trac.tpo's captcha(colorful, small, hard to read).
It is very hard to read if you have eye problem with a color of computer screen.
Could you replace trac's captcha to bridge's one to resolve accessibility problem?
**Trac**:
**Username**: ThernetJens KubiezielJens Kubiezielhttps://gitlab.torproject.org/legacy/trac/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2020-06-13T15:53:29ZteorMake sure inform_testing_reachability() reports the correct portsIn #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that ...In #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34136Audit the Content Process Sandbox Level bump in ESR68.8 on Windows2020-06-16T01:12:55ZcypherpunksAudit the Content Process Sandbox Level bump in ESR68.8 on WindowsTo fix CVE-2020-12388 and CVE-2020-12389, Mozilla set `security.sandbox.content.level` to `6`.
The code to support that was backported to ESR: https://hg.mozilla.org/mozilla-unified/file/esr68/security/sandbox/win/src/sandboxbroker/sandb...To fix CVE-2020-12388 and CVE-2020-12389, Mozilla set `security.sandbox.content.level` to `6`.
The code to support that was backported to ESR: https://hg.mozilla.org/mozilla-unified/file/esr68/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#l505
Correctness and completeness of the backport should be audited.https://gitlab.torproject.org/legacy/trac/-/issues/34135Feature suggestion: SOCKS5 internal DNS resolver.2020-06-13T15:53:28ZTracFeature suggestion: SOCKS5 internal DNS resolver.There are many programs that forward DNS request over SOCKS5 proxies, to work with tor the most of them send the queries in TCP format.
But they cannot use the DNS of Tor relays, they can only send to an external DNS server, so disablin...There are many programs that forward DNS request over SOCKS5 proxies, to work with tor the most of them send the queries in TCP format.
But they cannot use the DNS of Tor relays, they can only send to an external DNS server, so disabling access to .onion sites.
That's why a virtual DNS server in the TOR SOCKS5 server would be useful, so these programs can use relays DNS and handle .onion queries.
Another case are transparent forwarders that use a upstream SOCKS5 address, DNS should be provided by a kind of program like above or a DNS over TCP scheme (available in the Linux GLIBC since 2015, see https://web.archive.org/web/20150518063349/http://man7.org:80/linux/man-pages/man5/resolv.conf.5.html).
By adding the option "use-vc" in the Linux /etc/resolv.conf file, DNS queries can be done over the transparent proxy using external DNS servers, BUT NOT DNS of Tor relays and it cannot resolves .onion sites.
For these cases a virtual DNS resolver in the TOR SOCKS port would be useful, it can be only TCP (not UDP).
This is for DNS forwarders that use SOCKS proxies, and provide DNS in TCP mode to environments over transparent proxies.
The virtual addresses could be 224.0.0.1 for IPv4 and [2001:db8::1] for IPv6.
**Trac**:
**Username**: pcrhttps://gitlab.torproject.org/legacy/trac/-/issues/34134yahoo hates tor-announce mails: "User is receiving mail too quickly"2020-06-13T17:02:05ZRoger Dingledineyahoo hates tor-announce mails: "User is receiving mail too quickly"When we send mail to tor-announce@, we get hundreds of bounces, one from each person at yahoo.com give or take.
More investigation shows that yahoo is giving us a "450 User is receiving mail too quickly tnmpmscs (in reply to RCPT TO com...When we send mail to tor-announce@, we get hundreds of bounces, one from each person at yahoo.com give or take.
More investigation shows that yahoo is giving us a "450 User is receiving mail too quickly tnmpmscs (in reply to RCPT TO command)" response for each permanent failure.
I wonder if there's a line we can add in our postfix to slow down (spread out) delivery to this domain.https://gitlab.torproject.org/legacy/trac/-/issues/34133Tor documentation missing sandbox and %include limitations2020-06-13T15:53:28ZJigsaw52Tor documentation missing sandbox and %include limitationsThe tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.The tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34132Fix running an npm globally installed snowflake2020-06-13T18:22:05ZArlo BreaultFix running an npm globally installed snowflakeSnowflake is now an [npm published package](https://www.npmjs.com/package/snowflake-pt) that can install a global bin with `npm i -g`
It seems to be missing a `#!/usr/bin/env node` at the top of the script thoughSnowflake is now an [npm published package](https://www.npmjs.com/package/snowflake-pt) that can install a global bin with `npm i -g`
It seems to be missing a `#!/usr/bin/env node` at the top of the script thoughhttps://gitlab.torproject.org/legacy/trac/-/issues/34131Fix logic error in parse_extended_hostname2020-06-13T15:53:27ZNick MathewsonFix logic error in parse_extended_hostnameFound with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Found with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34129Use STUN to determine NAT behaviour of peers2020-06-30T16:07:44ZCecylia BocovichUse STUN to determine NAT behaviour of peersIn investigating high proxy failure rates at clients (#33666) and the logistics of running our own STUN server (#25591), I came across [RFC5780](https://tools.ietf.org/html/rfc5780), which outlines steps to identify NATs with "endpoint i...In investigating high proxy failure rates at clients (#33666) and the logistics of running our own STUN server (#25591), I came across [RFC5780](https://tools.ietf.org/html/rfc5780), which outlines steps to identify NATs with "endpoint independent mapping and filtering".
[Section 4.3](https://tools.ietf.org/html/rfc5780#section-4.3) outlines how a client can use a STUN server with an alternate IP address (returned in the first STUN binding request response) to determine how restrictive their NAT is.
This would be useful to match up clients with snowflake proxies that have compatible NATs. We still have the following questions:
- ~~are there public STUN servers that support this feature?~~
Yes there are several candidates.
- ~~does the pion/stun library we use support this feature for STUN clients?~~
Not yet but we can implement the feature.
- If we're able to implement our own STUN server behind a domain-fronted connection (#25591), how can we implement this functionality?
I see at least one open source STUN server implementation that claims to support this (written in C): https://github.com/coturn/coturnCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/34128The badge should have a version number discoverable in the source2020-06-13T18:22:04ZArlo BreaultThe badge should have a version number discoverable in the sourceIt's not clear if https://snowflake.torproject.org/embed.html is running `0.3.0`
Was it published after the most recent release?It's not clear if https://snowflake.torproject.org/embed.html is running `0.3.0`
Was it published after the most recent release?https://gitlab.torproject.org/legacy/trac/-/issues/34127npm publish as part of the release process2020-06-13T18:22:03ZArlo Breaultnpm publish as part of the release processConsider `npm publish`ing when a new release is made.
The patch here makes updating the package.json part of the release process,
https://github.com/arlolra/snowflake-webext/commit/7231928c56ad509419c20ed1bb9be5645373c86cConsider `npm publish`ing when a new release is made.
The patch here makes updating the package.json part of the release process,
https://github.com/arlolra/snowflake-webext/commit/7231928c56ad509419c20ed1bb9be5645373c86chttps://gitlab.torproject.org/legacy/trac/-/issues/34126Handle onicecandidate firing after connection closed2020-06-13T18:22:02ZArlo BreaultHandle onicecandidate firing after connection closedThis may just be an issue with node-webrtc, but `Broker.sendAnswer` fires when waiting on an offer times out.
https://github.com/arlolra/snowflake-webext/commit/529a789bfcb9539176288f6659e7f2a60c2d6271This may just be an issue with node-webrtc, but `Broker.sendAnswer` fires when waiting on an offer times out.
https://github.com/arlolra/snowflake-webext/commit/529a789bfcb9539176288f6659e7f2a60c2d6271https://gitlab.torproject.org/legacy/trac/-/issues/34125Fix torbutton proxy api due to change in Firefox 77.2020-06-16T01:28:35ZAlex CatarineuFix torbutton proxy api due to change in Firefox 77.We should fix torbutton code due to the breaking API change in `nsIProtocolProxyFilter` from https://bugzilla.mozilla.org/show_bug.cgi?id=1584797.We should fix torbutton code due to the breaking API change in `nsIProtocolProxyFilter` from https://bugzilla.mozilla.org/show_bug.cgi?id=1584797.https://gitlab.torproject.org/legacy/trac/-/issues/34124snowflake funktioniert nicht2020-06-13T18:22:02Zcypherpunkssnowflake funktioniert nichtAnzeige: WebRTC-Fähigkeit nicht erkannt.
Was soll ich tun?Anzeige: WebRTC-Fähigkeit nicht erkannt.
Was soll ich tun?https://gitlab.torproject.org/legacy/trac/-/issues/34123Provide secrets/passwords management for Tor Browser Nightly signing2020-06-13T17:02:05ZMatthew FinkelProvide secrets/passwords management for Tor Browser Nightly signingAs mentioned in #34121, the Tor Browser Nightly signing machine will host an OpenPGP key and an NSSDB private key. Both of these should be password-protected. Instead of hard-coding these passphrases in a file or script on the server, ha...As mentioned in #34121, the Tor Browser Nightly signing machine will host an OpenPGP key and an NSSDB private key. Both of these should be password-protected. Instead of hard-coding these passphrases in a file or script on the server, having a password management system from where the passwords can be retrieved would be very nice.HiroHiro