Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-11-15T18:55:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15545Document TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.2021-11-15T18:55:15ZYawning AngelDocument TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume ...This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume that tor will keep stdin open, and to treat stdin being closed as the same as a `SIGTERM` (graceful shutdown immediately).Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/11150Remove client code for connecting to and using 0.2.2 servers2020-07-31T12:53:28ZNick MathewsonRemove client code for connecting to and using 0.2.2 serversWe can finally drop support for the client-side V2 link handshake!We can finally drop support for the client-side V2 link handshake!Tor: 0.2.8.x-finalTvdWTvdWhttps://gitlab.torproject.org/legacy/trac/-/issues/9580Tor should accept combined pluggable transport names2020-06-13T18:34:31ZGeorge KadianakisTor should accept combined pluggable transport namesThe plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little...The plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little-t-tor. However, in little-t-tor we do some checks on the transport names (in torrc, etc.) and ensure that they are C-identifiers -- but "websocket|obfs2" is not a C-identifier.
We should relax those checks so that they don't choke when we give them "websocket|obfs2".https://gitlab.torproject.org/legacy/trac/-/issues/18949Update BridgeDB's CI to run tests with next version of Twisted2020-06-13T18:28:37ZIsis LovecruftUpdate BridgeDB's CI to run tests with next version of Twisted[BridgeDB's CI](https://travis-ci.org/isislovecruft/bridgedb/builds/127250227) is set up to run the tests several times, with the idea that it runs one time each with installed versions of Twisted and PyOpenSSL included in both Debian st...[BridgeDB's CI](https://travis-ci.org/isislovecruft/bridgedb/builds/127250227) is set up to run the tests several times, with the idea that it runs one time each with installed versions of Twisted and PyOpenSSL included in both Debian stable and testing (so that we always know that we can run on the next stable release). Since we recently upgraded to Debian jessie, these versions are now outdated.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/15850Don't assign HSDir flag to relay that can't handle BEGIN_DIR2020-06-13T17:47:51ZDavid Gouletdgoulet@torproject.orgDon't assign HSDir flag to relay that can't handle BEGIN_DIRChild ticket of #15801.
Because of #14202 (introduced in 0.2.6), directory authorities can assign the HSDir flag to a relay without a DirPort but relay can't handle `BEGIN_DIR` cell if they don't have the DirPort set (see #15849).
Comm...Child ticket of #15801.
Because of #14202 (introduced in 0.2.6), directory authorities can assign the HSDir flag to a relay without a DirPort but relay can't handle `BEGIN_DIR` cell if they don't have the DirPort set (see #15849).
Commit 80bed1ac96a3035f8c55ddced5528f0d7d16d386 should be reverted and backported. Right now, we have 8 directory authorities that are >= 0.2.6 so we should backport this fix asap to 026.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15344Integrate tests into automake test suite2020-06-13T16:50:34ZcypherpunksIntegrate tests into automake test suiteThe ntor, backtrace and zero lengths keys tests are not integrated into the automake test suite. This means these tests not being include in the test results (with PASS/FAIL/etc), clutter up the terminal with their own output, and are po...The ntor, backtrace and zero lengths keys tests are not integrated into the automake test suite. This means these tests not being include in the test results (with PASS/FAIL/etc), clutter up the terminal with their own output, and are potentially not being run parallel.Tor: 0.2.7.x-finalcypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/18348Tor conflates IPv4 Dir port with IPv6 OR Port2020-06-13T16:03:34ZMatthew FinkelTor conflates IPv4 Dir port with IPv6 OR PortSince #17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too. The prima...Since #17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too. The primary problem arises when a relay attempt a descriptor upload/fetch with a directory authority with an IPv6 OR port.
Currently all configuration options allow configuring IPv6 OR ports, but none specify dir ports. When a client attempts a dir port connection, it implicitly assumes the dir port is listening on the same ip address as the OR port.
Currently most of the dir auths Dir ports are only listening on their ipv4 address, including the dir auths with ipv6 OR addresses. An easy (but not necessary correct) solution is Dir Auth Op configure their dirauths so they accept ipv6 connections on the dir port. A better solution is tor knows when a dir port is ipv4 or ipv6 and chooses the correct corresponding ip address.
Now, as a relay, in fascist_firewall_allows_dir_server() we choose the destination's ipv4 address. However, when we subsequently call directory_choose_address_routerstatus() we don't remember which address we prefer:
```
} else {
/* We use an IPv6 address if we have one and we prefer it.
* Use the preferred address and port if they are reachable, otherwise,
* use the alternate address and port (if any).
*/
have_or = fascist_firewall_choose_address_rs(status,
FIREWALL_OR_CONNECTION, 0,
use_or_ap);
}
have_dir = fascist_firewall_choose_address_rs(status,
FIREWALL_DIR_CONNECTION, 0,
use_dir_ap);
```
Therefore directory_initiate_command_rend() uses the ipv6 address by default.
As an example (with additional debug messages):
```
Feb 19 16:57:33.000 [info] router_upload_dir_desc_to_dirservers: Uploading relay descriptor to directory authorities
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:9131.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 32).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 32, address 128.31.0.39, n_conns 36.
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:80.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 33).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 33, address 2001:858:2:2:aabb:0:563b:1526, n_conns 37.
...
Feb 19 16:57:33.000 [debug] conn_read_callback: socket 33 wants to read.
Feb 19 16:57:33.000 [debug] connection_handle_read_impl: Closing conn after error: Connection refused (61)
Feb 19 16:57:33.000 [info] connection_close_immediate: fd 33, type Directory, state connecting, 3298 bytes on outbuf.
Feb 19 16:57:33.000 [debug] conn_close_if_marked: Cleaning up connection (fd -1).
Feb 19 16:57:33.000 [info] connection_dir_request_failed: Setting dir 2001:858:2:2:aabb:0:563b:1526 as down after failed request.
Feb 19 16:57:33.000 [debug] router_set_status: Setting 86.59.21.38 as running: 0
Feb 19 16:57:33.000 [debug] router_set_status: Marking router $847B1F850344D7876491A54892F904934E4EB85D~tor26 at 86.59.21.38 as down.
Feb 19 16:57:33.000 [debug] connection_remove: removing socket -1 (type Directory), n_conns now 47
```
(this issue is only in master, not in any released version)
To make matters worse (and the reason I found this), eventually after most of the ipv6-enabled dir auths are marked as down due to the connection being refused, relays later get this scary thing:
```
Feb 19 09:26:53.000 [warn] router_picked_poor_directory_log: Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directo
ry. (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: Node search initiated by. Stack trace: (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1157ff8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10af99c <hid_serv_responsible_for_desc_id+0xebc> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10a6ae6 <router_pick_trusteddirserver+0x76> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1126333 <directory_get_from_dirserver+0x293> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad4ba <launch_descriptor_downloads+0x4ba> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad27a <launch_descriptor_downloads+0x27a> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10adbcb <update_consensus_router_descriptor_downloads+0x6cb> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ac856 <update_all_descriptor_downloads+0x66> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10602c8 <directory_info_has_arrived+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1128a40 <connection_dir_reached_eof+0x1160> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x110810b <connection_handle_read+0xb3b> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105f044 <connection_add_impl+0x214> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x801aa538e <event_base_loop+0x81e> at /usr/local/lib/libevent-2.0.so.5 (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1060cc5 <do_main_loop+0x5c5> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1062fcf <tor_main+0xdf> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ed49 <main+0x19> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ec41 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
```
Because we already asked the useful dir auths for descriptors and those requests are still outstanding, so we don't have any viable directories remaining. (Ignore the mention of hid_serv_responsible_for_desc_id+0xbfb, it is actually router_pick_trusteddirserver_impl()).Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8766Tor never recovers when started with skewed clock2020-06-13T15:41:11ZproperTor never recovers when started with skewed clockHow to reproduce...
Start Tor with a skewed clock. For example, +/- one week.
Tor will detect, that the clock is skewed.
```
Received directory with skewed time (server '...'):
It seems that our clock is ahead by 6 days, 23 hours,
59 ...How to reproduce...
Start Tor with a skewed clock. For example, +/- one week.
Tor will detect, that the clock is skewed.
```
Received directory with skewed time (server '...'):
It seems that our clock is ahead by 6 days, 23 hours,
59 minutes, or that theirs is behind. Tor requires an
accurate clock to work: please check your time,
timezone, and date settings.
I learned some more directory information, but not
enough to build a circuit: We have no recent usable
consensus.
```
Then reset clock back to correct time. Tor will also detect that.
```
Your system clock just jumped 604800 seconds backward;
assuming established circuits no longer work.
```
Result:
Tor still won't work (no connections possible).
Expected result:
Tor recovers and can now connect.
Version:
getinfo version: 250-version=0.2.3.25 (git-3fed5eb096d2d187)
(On Debian Wheezy.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15515Don't allow multiple INTRODUCE1s on the same circuit2020-06-13T15:17:27ZGeorge KadianakisDon't allow multiple INTRODUCE1s on the same circuitCurrently, it seems like clients are able to send multiple INTRODUCE1 cells to the IP. The result is that many INTRODUCE2 cells reach the HS, which means that the HS will try to establish multiple rendezvous circuits.
This gives a bette...Currently, it seems like clients are able to send multiple INTRODUCE1 cells to the IP. The result is that many INTRODUCE2 cells reach the HS, which means that the HS will try to establish multiple rendezvous circuits.
This gives a better position to attackers who want to flood a HS with rendezvous circuits (like #15463), since with a single circuit they can cause hundreds of rendezvous.
We should fix this in the IP-side, by closing the circuit after sending the `INTRODUCE_ACK` to the client. An alternate behavior, is to change the state of the circuit after `INTRODUCE1` is received and close it if more such cells are received.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16792Have a way to mark lines as "unreachable by unit tests"2020-06-13T15:15:02ZNick MathewsonHave a way to mark lines as "unreachable by unit tests"It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4296Trivial issues in tor_spawn_background()/tor_check_port_forwarding()2020-06-13T15:09:27ZGeorge KadianakisTrivial issues in tor_spawn_background()/tor_check_port_forwarding()Some things I noticed while coding #3472 stuff:
* In tor_spawn_background():
```
retval = pipe(stderr_pipe);
if (-1 == retval) {
```
if pipe() fails, the file descriptors of `pipe(stdout_pipe)` above are never closed.
* In the tor_...Some things I noticed while coding #3472 stuff:
* In tor_spawn_background():
```
retval = pipe(stderr_pipe);
if (-1 == retval) {
```
if pipe() fails, the file descriptors of `pipe(stdout_pipe)` above are never closed.
* In the tor_check_port_forwarding() code or in the Windows version of tor_read_all_handle() the stdout/stderr handles are not CloseHandle()d on stream error.
I'll prepare a patch.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8195tor and capabilities2020-06-13T15:07:30Zweasel (Peter Palfrader)tor and capabilitiesWe should figure out what it takes to keep the CAP_NET_BIND_SERVICE capability when changing the user away from root, so that we can re-open low listening ports later again.We should figure out what it takes to keep the CAP_NET_BIND_SERVICE capability when changing the user away from root, so that we can re-open low listening ports later again.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18184Remove "support" for unsigned time_t2020-06-13T15:07:18ZNick MathewsonRemove "support" for unsigned time_tI maintain that unsigned time_t does not actually exist, and that time_t is signed everywhere that matters. Further, we probably have all kinds of assumptions in our code that it is signed. So let's remove the "support" for unsigned ti...I maintain that unsigned time_t does not actually exist, and that time_t is signed everywhere that matters. Further, we probably have all kinds of assumptions in our code that it is signed. So let's remove the "support" for unsigned time_t, since it probably wouldn't work anyway.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17909'GETINFO config-text' always includes HiddenServiceStatistics2020-06-13T15:05:15ZDamian Johnson'GETINFO config-text' always includes HiddenServiceStatisticsSimilar to #2362, our new HiddenServiceStatistics option always appears in our 'GETINFO config-text' output even if unset...
```
% cat /tmp/simple_torrc
ControlPort 9051
% tor-prompt
>>> GETINFO config-text
250+config-text=
ControlPor...Similar to #2362, our new HiddenServiceStatistics option always appears in our 'GETINFO config-text' output even if unset...
```
% cat /tmp/simple_torrc
ControlPort 9051
% tor-prompt
>>> GETINFO config-text
250+config-text=
ControlPort 9051
DataDirectory /home/atagar/.tor
HiddenServiceStatistics 0
Log notice stdout
.
250 OK
```
As such saving your torrc in applications like vidalia, arm, and maybe tor browser (does it have the ability to save your torrc?) append this needless option.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18626Cannot compile Tor for 64-bit architectures with Xcode 7.32020-06-13T15:05:08ZTracCannot compile Tor for 64-bit architectures with Xcode 7.3Not sure exactly why this appeared after the release of Xcode 7.3, but we are no longer able to finish the configure phase due to a missing stdlib.h include in the conftests for OpenSSL and zlib.
For example:
```
conftest.c:69:25: erro...Not sure exactly why this appeared after the release of Xcode 7.3, but we are no longer able to finish the configure phase due to a missing stdlib.h include in the conftests for OpenSSL and zlib.
For example:
```
conftest.c:69:25: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
RAND_add((void*)0,0,0); exit(0);
^
conftest.c:69:25: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
| void RAND_add(const void *buf, int num, double entropy);
| int
| main ()
| {
| RAND_add((void*)0,0,0); exit(0);
| ;
| return 0;
| }
```
When I edited configure.ac to add the include for both OpenSSL and zlib and re-ran autoconf, I was able to make the tests pass and finish configure.
```
TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI],
[#include <openssl/rand.h>],
[#include <stdlib.h>],
[void RAND_add(const void *buf, int num, double entropy);],
[RAND_add((void*)0,0,0); exit(0);], [],
[/usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/athena /opt/openssl])
TOR_SEARCH_LIBRARY(zlib, $tryzlibdir, [-lz],
[#include <zlib.h>],
[#include <stdlib.h>],
[const char * zlibVersion(void);],
[zlibVersion(); exit(0);], [--with-zlib-dir],
[/opt/zlib])
```
We are also tracking this issue on GitHub here: https://github.com/ursachec/CPAProxy/issues/40
**Trac**:
**Username**: chrisballingerTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18963Download authority certificates even under blackholed authorities or fallbacks2020-06-13T14:59:06ZteorDownload authority certificates even under blackholed authorities or fallbacksOur fix for #18816 is still not great if a significant number of fallbacks are blocked or blackholed.
There are a few options to deal with this:
* do what we do with the consensus, and try multiple, simultaneous connections to both autho...Our fix for #18816 is still not great if a significant number of fallbacks are blocked or blackholed.
There are a few options to deal with this:
* do what we do with the consensus, and try multiple, simultaneous connections to both authorities and fallback directories, use the first one that succeeds, and close the rest,
* if the connection to a fallback fails, try an authority (this still doesn't help with blackholed fallbacks),
* or any of the other options arma mentions in #18816:
> Longer term (0.2.9 and later), I think we should explore a) having directory_get_from_dirserver() notice that there are tls conns established to dir mirrors that we just recently used (and prefer them), or b) trying to explicitly remember the dir mirror that gave us the consensus and re-use it, and/or c) designing a piggy-back mechanism so we can ask for "the certs that go with this consensus" when we're fetching a consensus and we know we will want the certs for it too (thus saving a round-trip).Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18840dir auths vote "package" lines out of order2020-06-13T14:58:00ZRoger Dingledinedir auths vote "package" lines out of orderIn proposal 227, we say
```
Votes and consensuses may include any number of "package" lines,
but no vote or consensus may include more than one "package" line
with the same PACKAGENAME and VERSION values. All "package"
lines...In proposal 227, we say
```
Votes and consensuses may include any number of "package" lines,
but no vote or consensus may include more than one "package" line
with the same PACKAGENAME and VERSION values. All "package"
lines must be sorted by "PACKAGENAME VERSION", in
lexical (strcmp) order.
```
but I just had moria1 set up its torrc with
```
RecommendedPackages shouldbesecond 0 http digest=digest
RecommendedPackages outoforder 0 http digest=digest
```
and sure enough, its vote now says
```
package shouldbesecond 0 http digest=digest
package outoforder 0 http digest=digest
```
I've looked through the code, and it looks like the lines do get sorted for the consensus. And maybe there is no problem with having them unsorted in the votes? In that case should we just update the proposal document so future me doesn't get confused? Or, better, should we change votes to sort them too, because it can't hurt and it might help?Tor: 0.2.9.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/13538Stop signed left shift overflows in curve25519-donna (non-64-bit)2020-06-13T14:57:34ZteorStop signed left shift overflows in curve25519-donna (non-64-bit)Similarly to #13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrapv, this cau...Similarly to #13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrapv, this causes a trap/crash.
I've used a similar strategy to the one in #13280, where we automate the entire SHL32/SHL64 conversion using a perl script. The first commit sets up the macros.
The safe SHL32/SHL64 macros perform potentially overflowing left shifts in unsigned arithmetic.
I'll post a branch as soon as I've set up a change entry (for which I need the bug number).
Version: tor 2.6.?-alpha
git: fc5cab44724e8328e2186f22114625388f1c8f0d (Thu Oct 16 13:29:14 2014 -0400)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17150Tor 0.2.7.3-rc: "Extrainfo digest did not match digest256 from routerdesc"2020-06-13T14:57:30ZtoralfTor 0.2.7.3-rc: "Extrainfo digest did not match digest256 from routerdesc"Installing tor the 2nd time in a row gives tons of these warnings :
```
Sep 24 23:00:53.000 [warn] router info incompatible with extra info (ri id: 000149E6EF7102AACA9690D6E8DD2932124B94AB, ei id 000149E6EF7102AACA9690D6E8DD2932124B94AB,...Installing tor the 2nd time in a row gives tons of these warnings :
```
Sep 24 23:00:53.000 [warn] router info incompatible with extra info (ri id: 000149E6EF7102AACA9690D6E8DD2932124B94AB, ei id 000149E6EF7102AACA9690D6E8DD2932124B94AB, reason: Extrainfo digest did not match digest256 from routerdesc)
...
```Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19063The tor_parse_* functions should check and warn on max < min2020-06-13T14:57:27ZteorThe tor_parse_* functions should check and warn on max < minIf a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if...If a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if that's not the case. (I really don't think we should assert.)
We should do this for all similar tor_parse_* functions.
But are there any circumstances where we should allow min to be greater than max? (it will always fail)
Existing callers pass constants to this function, so it's not going to trigger for them.Tor: 0.2.9.x-final