The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-07T15:56:39Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/191Replace caret with num-derive, popularity.2022-02-07T15:56:39ZcheakoReplace caret with num-derive, popularity.I believe this would get tangled with #165.
The [`caret`](https://crates.io/crates/caret) create has sometimes 4 downloads a day, when [`num-derive`](https://crates.io/crates/num-derive) has thousands.
Effects `tor-cell`.
```
[depende...I believe this would get tangled with #165.
The [`caret`](https://crates.io/crates/caret) create has sometimes 4 downloads a day, when [`num-derive`](https://crates.io/crates/num-derive) has thousands.
Effects `tor-cell`.
```
[dependencies]
num-traits = "0.2"
num-derive = "0.3"
```
Note: Investigate `NumCast`, `NumOpt` makes no sense being math only and doesn't cover `Ord` and `Eq`.
```
use num_derive::{FromPrimitive, ToPrimitive};
```
https://fasterthanli.me/series/making-our-own-ping/part-11
```
#[derive(Debug, FromPrimitive, ToPrimitive)]
#[repr(u8)]
pub enum Protocol {
ICMP = 0x01,
TCP = 0x06,
UDP = 0x11,
}
```https://gitlab.torproject.org/tpo/web/community/-/issues/233[Onion Services] Update NYT onion service2021-10-20T13:23:15Zchampionquizzerchampionquizzer@torproject.org[Onion Services] Update NYT onion serviceNew York Times have updated their onion service to v3: https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/
.. and we must update it on the 'featured onions' section: https://community.torproject.org/onion-servic...New York Times have updated their onion service to v3: https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/
.. and we must update it on the 'featured onions' section: https://community.torproject.org/onion-services/#featured-onions
Proof: TLS/SSL certificate and onion-location header on https://www.nytimes.com/HackerNCoderhackerncoder@encryptionin.spaceHackerNCoderhackerncoder@encryptionin.spacehttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/70Unexpected Naming Scheme in Semantic Versioning Represention Structure2022-09-27T09:58:21ZshelikhooUnexpected Naming Scheme in Semantic Versioning Represention StructureIn the [Version](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/f7d0b7451e242a711f3c9887348b84a6ae054c38/pkg/usecases/resources/links.go#L14) Structure, "Major" version is named "Mayor" version, which is different from it...In the [Version](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/f7d0b7451e242a711f3c9887348b84a6ae054c38/pkg/usecases/resources/links.go#L14) Structure, "Major" version is named "Mayor" version, which is different from its [definition](https://semver.org/) form. If this is unintentional, we could consider renaming it to its definition form.https://gitlab.torproject.org/tpo/web/tpo/-/issues/262Remove jinja template escaping from "Become a Member" section2022-07-09T04:26:25ZGusRemove jinja template escaping from "Become a Member" sectionhttps://www.torproject.org/about/membership/
```
Become a Member
{ _("Join the Tor Project Membership Program and demonstrate your commitment to privacy online and become more deeply involved in the Tor community. Email us at giving@to...https://www.torproject.org/about/membership/
```
Become a Member
{ _("Join the Tor Project Membership Program and demonstrate your commitment to privacy online and become more deeply involved in the Tor community. Email us at giving@torproject.org. to get started.") }
```emmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/support/-/issues/275Dead link on FAQ2022-01-13T18:10:35ZcypherpunksDead link on FAQOn main page of support website, in section named "Gmail warns me that my account may have been compromised", there is a link to fscked.org, which seems to be a long-dead mikeperry's website.On main page of support website, in section named "Gmail warns me that my account may have been compromised", there is a link to fscked.org, which seems to be a long-dead mikeperry's website.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40733MOZ_ASSERT on about:tor2022-10-04T19:46:41ZPier Angelo VendrameMOZ_ASSERT on about:tor### Summary
`about:tor` crashes in debug builds, because a `MOZ_ASSERT` is triggered.
### Steps to reproduce:
1. Compile Tor Browser with `ac_add_options --enable-debug` in the `mozconfig`
2. Run Tor Browser
3. Connect to the Tor net...### Summary
`about:tor` crashes in debug builds, because a `MOZ_ASSERT` is triggered.
### Steps to reproduce:
1. Compile Tor Browser with `ac_add_options --enable-debug` in the `mozconfig`
2. Run Tor Browser
3. Connect to the Tor network
4. You will see the tab crashing
5. Try to go to any other address, it will work
6. Try to write `about:tor` in the address bar, and go there: the tab will crash
### What is the current bug behavior?
The tab crashes, and Tor Browser asks you whether you want to reload it.
But if you press it, the tab crashes again. Other tabs work normally.
If you attach a debugger to Tor Browser, it will stop in one of the `MOZ_ASSERT` of `nsresult NS_CompareLoadInfoAndLoadContext(nsIChannel* aChannel)`.
File: `netwerk/base/nsNetUtil.cpp`, line: around 3092 (the first `MOZ_ASSERT` of the function).
Visual Studio tells that it is a dereferenced `nullptr`, but I do not understand why (it seem to me it is using normal objects allocated on stack; I will have to investigate more).
### What is the expected behavior?
I wanted to see the normal `about:tor` page :smile:
### Environment
I tested on a 91.3.0/11.0.1 Windows build compiled by me, with `ac_add_options --enable-debug`.
This happened both on Windows 10 and Windows 11.
This happens on Linux as well (remember to update the `build` as well, to copy debug `geckodriver`).
### Relevant logs and/or screenshots
![about_tor](/uploads/16177a720b8246d5a840c038ce77b1aa/about_tor.png)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40429hash_incrementals script hangs on sha256sum when no .incremental.mar files ar...2022-02-14T15:01:10Zrichardhash_incrementals script hangs on sha256sum when no .incremental.mar files are presentRan into this today when attempting to build tbb-11.5a4-build1
I had incorrectly set `torbrowser_incremental_from` to 11.5a3 which was an Android-only release. As 11.5a4 is Desktop-only, there were no .incremental-mar files to be used.
...Ran into this today when attempting to build tbb-11.5a4-build1
I had incorrectly set `torbrowser_incremental_from` to 11.5a3 which was an Android-only release. As 11.5a4 is Desktop-only, there were no .incremental-mar files to be used.
We should verify that the set of filenames output by `ls -1 | grep '\.incremental\.mar$' | sort` is not empty, otherwise sha256sum will hang indefinitely waiting for data to be read in from stdin.boklmboklmhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40115Scrub pt.Log calls like other logs2022-11-07T16:25:28ZDavid Fifielddcf@torproject.orgScrub pt.Log calls like other logs!67 added [`ptEventLogger`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/bd636a1374efb514bbc40acbd1dcaf0ecec26916/client/lib/pt_event_logger.go) which sends messages to the managing process usin...!67 added [`ptEventLogger`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/bd636a1374efb514bbc40acbd1dcaf0ecec26916/client/lib/pt_event_logger.go) which sends messages to the managing process using `pt.Log`. But these logs are not scrubbed of IP addresses the way all other logs are scrubbed (as in
#21304).
I saw this in the Tor Logs in Tor Browser:
```
3/17/22, 02:24:50.145 [NOTICE] Managed proxy "./TorBrowser/Tor/PluggableTransports/snowflake-client": offer created
3/17/22, 02:24:50.146 [NOTICE] Managed proxy "./TorBrowser/Tor/PluggableTransports/snowflake-client": broker failure dial tcp: lookup cdn.sstatic.net on 192.168.0.1:53: dial udp 192.168.0.1:53: connect: network is unreachable
```itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40116Soften Tor log output for non critical events2022-04-12T15:57:06ZCecylia BocovichSoften Tor log output for non critical eventsWe had a forum post from a user who interpreted one of the snowflake connection events as a critical failure of snowflake: https://forum.torproject.net/t/snowflake-does-not-work-anymore/2650/2
While a failure to connect to the broker ca...We had a forum post from a user who interpreted one of the snowflake connection events as a critical failure of snowflake: https://forum.torproject.net/t/snowflake-does-not-work-anymore/2650/2
While a failure to connect to the broker can be critical, a failure to open a data channel with a snowflake is not unusual and snowflake can easily recover from it. Let's make a small change of the log message from "connection failed" to "trying a new proxy: [error message]" or something like thatitchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40118Fix misleading proxy usage statistics message on launch2022-05-31T20:36:21Zmeskiomeskio@torproject.orgFix misleading proxy usage statistics message on launchAs soon as you launch the proxy it displays:
```
2022/03/23 09:27:18 In the last 1h0m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
I guess it will be better to don't display that until some time has actually passed. Or ...As soon as you launch the proxy it displays:
```
2022/03/23 09:27:18 In the last 1h0m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
I guess it will be better to don't display that until some time has actually passed. Or at least don't say `In the last 1h`, because it hasn't being running 1hour.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40044Update BridgeDB's Bridge Pool Assignments documentation2022-09-05T16:56:14ZGeorg KoppenUpdate BridgeDB's Bridge Pool Assignments documentationLooking over a recent bridge pool assignment file one can see:
```
005fd4d7decbb250055b861579e6fdc79ad17bee email transport=obfs4 ip=4 blocklist=ru
00782946f4c54ce1d028f21e541ef8440ecaa0ee settings ip=4 blocklist=ru
00a4295a8477453d6afe1...Looking over a recent bridge pool assignment file one can see:
```
005fd4d7decbb250055b861579e6fdc79ad17bee email transport=obfs4 ip=4 blocklist=ru
00782946f4c54ce1d028f21e541ef8440ecaa0ee settings ip=4 blocklist=ru
00a4295a8477453d6afe1ca4c2f19e3708e63fc4 email ip=4
00afd5ca2f89305b89171450cf34f247858f14e8 settings transport=obfs4 ip=4 blocklist=ru
00e1ae6cb75e47e363e6aef9f67a49c0e854fde7 moat transport=obfs4 ip=4
00e6f1d633d4e29db31f43d1e6e3e928e5c1810d moat transport=obfs4 ip=4 blocklist=ru
0110a6cf41a07637808fff79c0783ff37462b525 email ip=4 blocklist=ru
01292375ae04f41e7453d8e85df446c22a8d7101 settings ip=4 port=443 blocklist=ru
01341c9b4bc01b3a11e80a645a0bde45db02f04b moat transport=obfs4 ip=4
01436ef5b118fd95004a75f4616a6094d4aa4748 moat transport=obfs4 ip=4
0145c4524211a250519864627e4ae31eecccd39f moat transport=obfs4 ip=4
01520c1bb2c46bf0f54969b71217be04c1f8eb58 telegram transport=obfs4 ip=4 port=443
```
. However, our website does not know anything about `settings` or `telegram` or `ip` or `blocklist` or `transport` etc.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40121add prometheus support to snowflake proxy2024-02-14T16:48:40Zcypherpunksadd prometheus support to snowflake proxyfrom today's relay meetup:
For better maintainability and service monitoring please add a prometheus exporter to snowflake proxy with at least the following data:
- bandwidth
- memory usage
- uptime
- sockets/connections
- version
Th...from today's relay meetup:
For better maintainability and service monitoring please add a prometheus exporter to snowflake proxy with at least the following data:
- bandwidth
- memory usage
- uptime
- sockets/connections
- version
This will allow us to detect when the service crashed and got restarted or uses significantly less/more bw/memory/sockets.https://gitlab.torproject.org/tpo/web/support/-/issues/300Search bar with fixed width2022-07-26T20:57:11ZGusSearch bar with fixed widthKeeping the search bar a fixed width (like \~600px) before the mobile breakpoint would be great too, otherwise it gets a little short at tablet sizes.
https://gitlab.torproject.org/tpo/web/support/-/merge_requests/108#note_2799154Keeping the search bar a fixed width (like \~600px) before the mobile breakpoint would be great too, otherwise it gets a little short at tablet sizes.
https://gitlab.torproject.org/tpo/web/support/-/merge_requests/108#note_2799154Sponsor 9 - Phase 6 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40134Log messages from client NAT check failures are confusing2022-05-31T22:11:07ZDavid Fifielddcf@torproject.orgLog messages from client NAT check failures are confusingWhen [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the message...When [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the messages confusingly appear to refer to the broker rendezvous, not the STUN server connection:
```
Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
Front URL: cdn.sstatic.net
Error: no response from server
Error: no response from server
Error: no response from server
```
In this situation, communication with the broker has succeeded and a proxy has been assigned, but the client is having trouble checking its own NAT type. These log messages should say "STUN" or "NAT" somewhere in them, and ideally also the address of the server that failed (possibly subject to safe-log scrubbing).
Refactoring suggestion: instead of having a log call at every return of `isRestrictedMapping`, you can use [`fmt.Errorf("...: %w")`](https://pkg.go.dev/errors) to wrap the underlying error with additional context, and just return the error. That way, the logging can be consolidated in [`updateNATType`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?h=v2.1.0#n239), which is also where the STUN server address can be added and displayed.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/web/team/-/issues/38Broken link on archive.torproject.org2022-05-12T16:23:06ZsreadyBroken link on archive.torproject.orgIn README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?In README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?anarcatanarcathttps://gitlab.torproject.org/tpo/core/tor/-/issues/40613Remove socket_failed_from_resource_exhaustion heuristic2022-12-12T20:12:55ZAlex XuRemove socket_failed_from_resource_exhaustion heuristicsocket_failed_from_resource_exhaustion says:
```
/**
* A socket failed from resource exhaustion.
*
* Among other actions, warn that an accept or a connect has failed because
* we're running out of TCP sockets we can use on current s...socket_failed_from_resource_exhaustion says:
```
/**
* A socket failed from resource exhaustion.
*
* Among other actions, warn that an accept or a connect has failed because
* we're running out of TCP sockets we can use on current system. Rate-limit
* these warnings so that we don't spam the log. */
static void
socket_failed_from_resource_exhaustion(void)
{
/* When we get to this point we know that a socket could not be
* established. However the kernel does not let us know whether the reason is
* because we ran out of TCP source ports, or because we exhausted all the
* FDs on this system, or for any other reason.
*
* For this reason, we are going to use the following heuristic: If our
* system supports a lot of sockets, we will assume that it's a problem of
* TCP port exhaustion. Otherwise, if our system does not support many
* sockets, we will assume that this is because of file descriptor
* exhaustion.
*/
```
The first part of the second comment is wrong for two reasons:
1. the kernel returns EADDRINUSE if TCP ports were exhausted, EMFILE if the process reached its FD limit, and ENFILE if the system reached its FD limit; and
2. we know in advance which failure condition could apply based on the system call: socket and accept can't fail due to lack of TCP ports, and bind and connect can't fail due to lack of FDs. actually, socket_failed_from_resource_exhaustion isn't even called when bind or connect fails anyways, so it's not currently possible for it to fail due to lack of TCP ports. The second part of the first comment is misleading: socket_failed_from_resource_exhaustion is not called when connect fails, it is called when connection_connect_sockaddr fails due to socket failing. This is probably fine anyways though: if connect fails due to EADDRINUSE, then it is because thousands of connections have been made to the same destination, which is not a relay overload.
Therefore, as far as I can tell, the heuristic is not necessary and should be replaced with either or both of the preceding rules.https://gitlab.torproject.org/tpo/core/tor/-/issues/40619Typo in microdesc.c2022-07-21T19:19:42ZcypherpunksTypo in microdesc.cThe file src/feature/nodelist/microdesc.c currently has the following strings:
<code>
if (tor_memeq(node->rs->descriptor_digest,
(*mdp)->digest, DIGEST256_LEN)) {
rs_match = "Microdesc digest in RS...The file src/feature/nodelist/microdesc.c currently has the following strings:
<code>
if (tor_memeq(node->rs->descriptor_digest,
(*mdp)->digest, DIGEST256_LEN)) {
rs_match = "Microdesc digest in RS matches";
} else {
rs_match = "Microdesc digest in RS does match";
}
</code>
It looks like a typo that should read "digest in RS does *not* match".Tor: 0.4.8.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19560running tor trying to access its ed25519_signing_secret_key, log message too ...2022-07-08T15:07:58Zweasel (Peter Palfrader)running tor trying to access its ed25519_signing_secret_key, log message too loudI keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
I...I keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
It probably shouldn't want that.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40625an number should not be formatted with decimals2022-07-07T00:47:11Ztoralfan number should not be formatted with decimalsThis
```
$> git grep -n ', and had '
src/core/or/status.c:277: "one was alive for %lf seconds, and had %lf unrecognized cells.",
```
gives
```
, and had 1.000000 unrecognized cells.
```
IMO something like ".0" is missing in the fo...This
```
$> git grep -n ', and had '
src/core/or/status.c:277: "one was alive for %lf seconds, and had %lf unrecognized cells.",
```
gives
```
, and had 1.000000 unrecognized cells.
```
IMO something like ".0" is missing in the formatter string to count cells and not fractions of cells.https://gitlab.torproject.org/tpo/core/tor/-/issues/40630Fails to build with LibreSSL 3.52022-08-09T12:33:45ZsqrtdFails to build with LibreSSL 3.5Fails to build with LibreSSL 3.5. Build log: https://paste.sr.ht/blob/55b7cf5eebceee820f42a4d2165069be3952e7b0
Patches to fix this are available on the OpenBSD Ports.
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-s...Fails to build with LibreSSL 3.5. Build log: https://paste.sr.ht/blob/55b7cf5eebceee820f42a4d2165069be3952e7b0
Patches to fix this are available on the OpenBSD Ports.
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-src_lib_crypt_ops_crypto_dh_openssl_c
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-src_lib_crypt_ops_crypto_rsa_openssl_c
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-src_lib_tls_x509_openssl_c
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-src_test_test_crypto_c
https://github.com/openbsd/ports/blob/master/net/tor/patches/patch-src_test_test_crypto_openssl_c