Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:47:11Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40520module thinko in src/lib/crypt_ops/crypto_rand.c2022-07-07T00:47:11Ztoralfmodule thinko in src/lib/crypt_ops/crypto_rand.c### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
ind...### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
index 5bf3a65b3b..90a755537c 100644
--- a/src/lib/crypt_ops/crypto_rand.c
+++ b/src/lib/crypt_ops/crypto_rand.c
@@ -568,9 +568,10 @@ crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
prefixlen = strlen(prefix);
resultlen = prefixlen + strlen(suffix) + randlen + 16;
- rand_bytes_len = ((randlen*5)+7)/8;
- if (rand_bytes_len % 5)
- rand_bytes_len += 5 - (rand_bytes_len%5);
+ rand_bytes_len = randlen*5;
+ if (rand_bytes_len % 8)
+ rand_bytes_len += 8 - (rand_bytes_len%8);
+ rand_bytes_len /= 8;
rand_bytes = tor_malloc(rand_bytes_len);
crypto_rand(rand_bytes, rand_bytes_len);
```
Or?Tor: 0.4.7.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40445tor_tls_finish_handshake warning spamming logs during relay operation2022-07-07T00:47:11Zharpiator_tls_finish_handshake warning spamming logs during relay operation### Summary
The following message is rapidly filling my notice-level logs during the Tor middle relay operation:
```
[warn] tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake didn't get set. Fixing that. (on Tor 0.4.5.9 )
``...### Summary
The following message is rapidly filling my notice-level logs during the Tor middle relay operation:
```
[warn] tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake didn't get set. Fixing that. (on Tor 0.4.5.9 )
```
The log file is growing fast. I've sent a bug report to OpenBSD via email, but I'm not sure they received it - no response so far. That's why I brought it here. Maybe it's reproducible upstream too.
### Steps to reproduce:
1. Install the tor package with "pkg_add tor"
2. Edit /etc/tor/torrc as in this gist: https://gist.github.com/o-alquimista/ba5b1043cb1be05eb76e0dd7831bf44d
3. Start tor service
The tor service may fail to start due to "permission denied" when writing the notice log file. I had to manually create the /var/log/tor directory and set its ownership to the "_tor" user.
4. Watch the notices.log file. In spite of the warnings, the relay runs without any noticeable problems. You can see it here: https://metrics.torproject.org/rs.html#details/3FA93D41E9A7C4C47B77C0D7F617999B6D5D0B62
### Environment
- Tor 0.4.5.9
- OpenBSD 6.9 arm64 (-stable)
- The device is a Raspberry Pi 4 Model B Rev 1.2
- Installation method is pkg_add (OpenBSD package)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40317Cannot SAVECONF when the seccomp sandbox is enabled2022-07-07T00:47:10ZanonymCannot SAVECONF when the seccomp sandbox is enabled### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug ...### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug behavior?
Sending a `SAVECONF` currently results in this answer:
```
250 OK
551 Unable to write configuration to disk.
250 closing connection
```
and `tor` logs:
```
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1"
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Operation not permitted
```
and unsurprisingly the current `tor` configuration was not saved to `torrc`.
### What is the expected behavior?
`SAVECONF` should work even when the seccomp sandbox is enabled.
### Environment
I tried with both `tor` 0.4.4.6 and 0.4.5.6 on an Debian Buster, using your `.deb`:s.
### Relevant logs and/or screenshots
Except the log I posted above, sometimes I saw this instead but I don't know why it's different:
```
Mar 05 12:06:00.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.tmp (on Tor 0.4.4.6 )
Mar 05 12:06:00.000 [warn] Couldn't open "/etc/tor/torrc.tmp" (/etc/tor/torrc) for writing: Operation not permitted
```Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40629Allow ignoring of SIGINT2022-06-23T21:13:51ZtlaAllow ignoring of SIGINT### Summary
Add an option (.e.g `--IgnoreSigint 1`) which allows to ignore `SIGINT`.
iOS has a feature which enables apps to keep running in the background for a certain amount of time:
https://developer.apple.com/documentation/uikit/...### Summary
Add an option (.e.g `--IgnoreSigint 1`) which allows to ignore `SIGINT`.
iOS has a feature which enables apps to keep running in the background for a certain amount of time:
https://developer.apple.com/documentation/uikit/uiapplication/1623031-beginbackgroundtask
However, even when we're making use of that, iOS is sending `SIGINT` to the app process, as soon as the user swipes away the app. (Sends it into background.)
Tor is currently hardcoded to stop working, when it receives that `SIGINT`:
https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/app/main/main.c#L223-228
### What is the expected behavior?
When the mentioned configuration option is set, Tor just ignores the `SIGINT` and continues running, to enable processing in the background.Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40418Man page no longer accurate for onion authorization instructions2022-05-09T16:35:19ZnyxnorMan page no longer accurate for onion authorization instructions[2019 TPO docs](https://2019.www.torproject.org/docs/tor-manual.html.en)
Outdated:
> Client Authorization
> Revoking a client can be done by removing their ".auth" file, however the revocation will be in effect only after the tor proce...[2019 TPO docs](https://2019.www.torproject.org/docs/tor-manual.html.en)
Outdated:
> Client Authorization
> Revoking a client can be done by removing their ".auth" file, however the revocation will be in effect only after the tor process gets restarted even if a SIGHUP takes place.
Revoking a key does work with sighup now.Developer portalSilvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40479SIGHUP managed proxies when logs reopened2022-04-21T16:37:20ZtwildeSIGHUP managed proxies when logs reopenedWe use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and...We use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and sending a SIGHUP manually is to do a full tor restart, which will kill and restart the managed proxy as well. Perhaps all SIGHUPs to Tor should just be passed along to any (unchanged argument) managed proxies?https://gitlab.torproject.org/tpo/core/tor/-/issues/40168Circuit Build Timeout should ignore abandon circuits, lower min timeout2022-02-28T18:16:02ZMike PerryCircuit Build Timeout should ignore abandon circuits, lower min timeoutWhile working on https://gitlab.torproject.org/tpo/core/tor/-/issues/40157, @asn and I discovered that the Circuit Build Timeout learned by CBT was too high. It is counting failed circuits and circuits that did not complete as if they we...While working on https://gitlab.torproject.org/tpo/core/tor/-/issues/40157, @asn and I discovered that the Circuit Build Timeout learned by CBT was too high. It is counting failed circuits and circuits that did not complete as if they were the longest build-time ("right-censored" in the Pareto estimator). This caused the resulting Pareto curve to be a poor fit. These circuits weren't actually that slow; their relays were just down or unresponsive. We should not count these circuits in our build time stats. Doing so in onionperf testing makes the Pareto curve fit much tighter.
Additionally, there is a #define CBT_DEFAULT_TIMEOUT_MIN_VALUE that makes the minimum timeout value 1.5 seconds. This is way too high -- timeouts on the network range from 80ms to 500ms now. This minimum should be like 25 or 50ms now.
This should be backported to stable clients for a couple reasons -- we want to eventually tune the network-wide circuit build timeout quantile for Sponsor61 experiments, but we can't do that until all clients compute the same circuit build timeout. Additionally, it is abysmal UX to wait for 1.5 seconds on circuits that will never ever build.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8214"getinfo address" should work more consistently soon after startup2021-12-10T09:04:38ZRoger Dingledine"getinfo address" should work more consistently soon after startupTor learns its own address, either by using the interface or by reading the http headers in directory responses.
But if your Tor had enough dir info cached when it came back up, it doesn't make any directory requests for a while. And th...Tor learns its own address, either by using the interface or by reading the http headers in directory responses.
But if your Tor had enough dir info cached when it came back up, it doesn't make any directory requests for a while. And then getinfo address will not have any opinion.
I think the best plan here is to expand the set of things inside Tor that remembers address guesses, to include address guesses we get from netinfo cells.
Wanted by legacy/trac#7348.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25630Bug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard state2021-11-06T14:54:53ZmeejahBug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard stateAfter discussion on #tor-dev, arma told me to file this; I am hitting this for every circuit my exit-scanner creates when using tor master (0eed0899cdeadd84).
The circuits created all start with a current guard (but probably not any of ...After discussion on #tor-dev, arma told me to file this; I am hitting this for every circuit my exit-scanner creates when using tor master (0eed0899cdeadd84).
The circuits created all start with a current guard (but probably not any of "my" current guards). I've tried with both purpose=general and purpose=controller but the result is the same (except for the 5 vs 21 in the error message)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40496We log when we stop having enough dir info, but we never log when we resume h...2021-11-03T22:53:05ZRoger DingledineWe log when we stop having enough dir info, but we never log when we resume having enoughWhen something goes wrong with our ability to use the network, we get a notice-level log like this one:
```
Oct 23 05:21:03.818 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptor...When something goes wrong with our ability to use the network, we get a notice-level log like this one:
```
Oct 23 05:21:03.818 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6432/6432). That's ok. We will try to fetch missing descriptors soon.
```
But when things recover, that message is only at info-level:
```
Oct 23 05:21:04.822 [info] We now have enough directory information to build circuits.
```
The original plan is described in the comments in update_router_have_minimum_dir_info():
```
/* a) make us log when we next complete a circuit, so we know when Tor
* is back up and usable, and b) disable some activities that Tor
* should only do while circuits are working, like reachability tests
* and fetching bridge descriptors only over circuits. */
note_that_we_maybe_cant_complete_circuits();
```
but then we lost that notice-level log in commit eee62e13 (in Tor 0.3.5.1-alpha):
```
- log_notice(LD_GENERAL,
- "Tor has successfully opened a circuit. "
- "Looks like client functionality is working.");
[...]
+ log_info(LD_GENERAL,
+ "Tor has successfully opened a circuit. "
+ "Looks like client functionality is working.");
```
as part of the shift in #14950 to reduce log clutter.
We should make sure there is a corresponding "we're back" message for each "we can't work yet" message that we write.https://gitlab.torproject.org/tpo/core/tor/-/issues/40427enable TCP timestamps on outgoing ORcon2021-11-01T17:10:27ZpseudonymisaTorenable TCP timestamps on outgoing ORcon### Summary
Make use of TCP timestamps, enable it via socks options on outgoing connections. [Defined in RFC 1323](https://datatracker.ietf.org/doc/html/rfc1323#section-4).
Tor could benefit from some better TCP congestion flow control...### Summary
Make use of TCP timestamps, enable it via socks options on outgoing connections. [Defined in RFC 1323](https://datatracker.ietf.org/doc/html/rfc1323#section-4).
Tor could benefit from some better TCP congestion flow control? The Client or relay does not know what TCP congestion algorithm the other peer may use.
> TCP timestamps are enabled by default In Linux kernel.
It was once disabled in some distros, because the bad implementation of timestamp start time was your system uptime and this fingerprinting could leak your uptime on every connection. This was fixed 2 decades ago. So why not use it now for all and not only some? All Tor Connection should look most identical for fingerprinting reasons.
Why not use it? Worst thing to happen is, that it could add 8 extra bytes of TCP header in total.
### What is the expected behavior?
TCP connections should be always enabling timestamps, to make fingerprinting harder.
WiP: [+TCP_TIMESTAMPS.patch](/uploads/fcbb3a72f3cbfdb91eab7b8e26af26f3/+TCP_TIMESTAMPS.patch)Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26299Reproducible Tor releases2021-10-29T13:21:31ZAlexander Færøyahf@torproject.orgReproducible Tor releasesIt might be useful to have that the generation of the Tor release tarballs are reproducible by multiple people from the Git source tree.
This could allow us to do things like:
- Having multiple people sign a release (since they are able...It might be useful to have that the generation of the Tor release tarballs are reproducible by multiple people from the Git source tree.
This could allow us to do things like:
- Having multiple people sign a release (since they are able to generate the release themselves and sign it).Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40185relay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR12021-10-22T14:17:38Ztoralfrelay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR1It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one...It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one which is listing at default ports (80 and 443) behaves fine, the other (9001 and 9030 and being a FallbackDir too) however is affected by this issue.
Update: It is independent from being a FallbackDir or not, with bc6c37b202e907ed now the other relay refused to restart - and today -TERM was ignored too at 1 relay.
Nowadays a _kill -HUP_ is ignored after an uptime of only few hours.
I use this cronjob for now to keep both relays aware of signals
```
@hourly (/sbin/rc-service tor reload; /sbin/rc-service tor2 reload) 1>/dev/null
```Tor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40310CI: Somehow, test_switch_id.sh is failing on 0352021-10-22T13:26:01ZDavid Gouletdgoulet@torproject.orgCI: Somehow, test_switch_id.sh is failing on 035See: https://gitlab.torproject.org/dgoulet/tor/-/pipelines/3132See: https://gitlab.torproject.org/dgoulet/tor/-/pipelines/3132Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40352Nonauthoritative directory does not accept posted server descriptors2021-10-19T12:31:25ZTommaso GragnatoNonauthoritative directory does not accept posted server descriptors```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107...```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107.47.215](https://metrics.torproject.org/rs.html#details/45E9240AD4ECE01793A1977C1260503B2C2C861F) is running 0.4.6 alpha and does not understand descriptors for v2 onions. Hence the 400.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40266#note_2724898
Should this be handled gracefully? What's the phase out plan?Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40294Detect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configure2021-10-19T12:29:39ZAlexander Færøyahf@torproject.orgDetect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configureCurrently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9...Currently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9cc2b2928eab045f89d0abf95a9e5c75e290ff8, this was enabled for our AppVeyor builds by explicitly setting the definition in the `CFLAGS` variable.
An example of the error that happens when this is not set:
```
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
from ./src/core/or/or.h:31,
from src/core/mainloop/connection.c:58:
src/core/mainloop/connection.c: In function ‘connection_free_minimal’:
src/core/mainloop/connection.c:875:16: error: unknown conversion type character ‘l’ in format [-Werror=format=]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:875:16: error: too many arguments for format [-Werror=format-extra-args]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_close_immediate’:
src/core/mainloop/connection.c:1056:21: error: unknown conversion type character ‘l’ in format [-Werror=format=]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:1056:21: error: too many arguments for format [-Werror=format-extra-args]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_connect_sockaddr’:
src/core/mainloop/connection.c:2242:10: error: unknown conversion type character ‘l’ in format [-Werror=format=]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:2242:10: error: too many arguments for format [-Werror=format-extra-args]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_dump_buffer_mem_stats’:
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: too many arguments for format [-Werror=format-extra-args]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: too many arguments for format [-Werror=format-extra-args]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:12417: src/core/mainloop/connection.o] Error 1
make[2]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make[1]: *** [Makefile:7346: all] Error 2
make[1]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make: *** [Makefile:81: tor] Error 2
```Tor: 0.4.7.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30797Stop shipping an abandoned systemd script?2021-09-16T14:23:38ZRoger DingledineStop shipping an abandoned systemd script?legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attenti...legacy/trac#19759, legacy/trac#19761, legacy/trac#19762 are bugs filed on the systemd script that we ship in "contrib/dist/tor.service.in".
The bugs haven't been looked at in years, and it looks like nobody on our side is paying attention to this systemd script. That sounds to me like we would consider people foolish if they tried to use it.
Should we confirm that somebody, somewhere else on the internet, has a better systemd script than we do, and then remove ours?Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40384move doxygen docs to GitLab CI or deprecate2021-08-30T17:59:27Zanarcatmove doxygen docs to GitLab CI or deprecatein tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
s...in tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
so retiring those would mean leaving that stale website in place for the foreseeable future.
could you move that to GitLab CI and GitLab pages? the following should get you started:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab/#publishing-gitlab-pages
if not, do let me know what's your blocker. i *believe* the resulting URL for core tor would be:
https://tpo.pages.torproject.net/core/tor/
once that is done we can retire the jenkins job, and then provide a redirect to the gitlab pages.
makes sense?Retire JenkinsAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/29220Update review guidelines to list best practices2021-07-22T16:19:43ZNick MathewsonUpdate review guidelines to list best practicesWhen we come up with some target guidelines in legacy/trac#29219 , we should make sure that our coding standards document them.When we come up with some target guidelines in legacy/trac#29219 , we should make sure that our coding standards document them.https://gitlab.torproject.org/tpo/core/tor/-/issues/40172Build failure on macOS on master2021-07-09T17:30:28ZMatthew FinkelBuild failure on macOS on masterIn tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) ...In tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) is causing this. Attached is the latest build log when building commit df1637600469 (tip of master, at build time).
[tor-osx-x86_64.log](/uploads/f83b8ec1bc057c5cd7f8774936b35aa5/tor-osx-x86_64.log)Tor: 0.4.5.x-stableNick MathewsonNick Mathewson