Exit relays now reject exit attempts to known relay addresses + ORPort and
also to authorities on the ORPort and DirPort.
Closes#2667
Signed-off-by: David Goulet <dgoulet@torproject.org>
Exit relays now reject exit attempts to known relay addresses + ORPort and
also to authorities on the ORPort and DirPort.
Closes#2667
Signed-off-by: David Goulet <dgoulet@torproject.org>
We would before do an address discovery and then a lookup in the cache if not
found which is now simplified by calling relay_find_addr_to_publish() directly
which does all those combined.
Furthermore, by doing so, we won't trigger an address discovery every minute
if we have no ORPort configured for the family.
Fixes#40254
Signed-off-by: David Goulet <dgoulet@torproject.org>
Let external bridge reachability testing tools discard cached
bridge descriptors when setting new bridges, so they can be sure
to get a clean reachability test.
Implements ticket 40209.
Generates the compile_commands.json file using the "bear" application so the
ccls server can be more efficient with our code base.
Closes#40227
Signed-off-by: David Goulet <dgoulet@torproject.org>
This validation was only done if DisableNetwork was off because we would use
the global list of transports/bridges and DisableNetwork would not populate
it.
This was a problem for any user using DisableNetwork which includes Tor
Browser and thus leading to the Bug() warning.
Without a more in depth refactoring, we can't do this validation without the
global list.
The previous commit makes it that any connection to a bridge without a
transport won't happen thus we keep the security feature of not connecting to
a bridge without its corresponding transport.
Related to #40106
Signed-off-by: David Goulet <dgoulet@torproject.org>
This patch limits the number of items in the consensus diff cache to 64
on the Windows platform. Hopefully, this will allow us to investigate a
smarter fix while avoiding the situation reported in tor#24857 where
Windows relay operators report Tor using 100% CPU.
See: tor#24857
This patch removes a call to `tor_assert_nonfatal()` if
`extend_info_from_node()` returns NULL. This is unnecessary as we
already handle the case where `info` is NULL in the next `if (!info) {
... }` block in the code.
See: tor#32666.
This reverts commit d07f17f676.
We don't want to consider an entire routable IPv6 network as sybil if more
than 2 relays happen to be on it. For path selection it is very important but
not for selecting relays in the consensus.
Fixes#40243
We can end up trying to find our address from an authority while we don't have
yet its descriptor.
In this case, don't BUG() and just come back later.
Closes#40231
Signed-off-by: David Goulet <dgoulet@torproject.org>
This one should work on GCC _and_ on Clang. The previous version
made Clang happier by not having unreachable "fallthrough"
statements, but made GCC sad because GCC didn't think that the
unconditional failures were really unconditional, and therefore
_wanted_ a FALLTHROUGH.
This patch adds a FALLTHROUGH_UNLESS_ALL_BUGS_ARE_FATAL macro that
seems to please both GCC and Clang in this case: ordinarily it is a
FALLTHROUGH, but when ALL_BUGS_ARE_FATAL is defined, it's an
abort().
Fixes bug 40241 again. Bugfix on earlier fix for 40241, which was
merged into maint-0.3.5 and forward, and released in 0.4.5.3-rc.
Some gcc versions do explode if the order of the linker flags are not correct.
One issue was statically building OpenSSL which would require that "-lssl
-lcrypto" be put _before_ the "-lpthread -ldl" flags.
I have not such problem with GCC 10 but does with GCC 9.
Closes#33624
Signed-off-by: David Goulet <dgoulet@torproject.org>
Our original code for parsing these parameters out of our list of
parameters pre-dated us having the
dirvote_get_intermediate_param_value() function... and it was buggy.
Specifically, it would reject any " ... K=V ..." value
where there were additional unconverted characters after the V, and
use the default value instead,
We haven't run into this yet because we've never voted for
bwweightscale to be anything besides the default 10000, or
maxunmeasuredbw to be anything besides the default 20.
This requires a new consensus method because it is a change in how
consensuses are computed.
Fixes bug 19011; bugfix on 0.2.2.10-alpha.
Some days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.
That in turn entirely disabled onion service v3, client and service side, due
to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3
subsystem will to its job for using the best consensus tor can find. If the
entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it
should still work because the client will use the current SRV it sees which
might be the previous SRV for the service for which it still publish
descriptors for.
If the service is using an old one and somehow can't get a new one while
clients are on a new one, then reachability issues might arise. However, this
is a situation we already have at the moment since the service will simply not
work if it doesn't have a live consensus while a client has one.
Fixes#40237
Signed-off-by: David Goulet <dgoulet@torproject.org>
We're getting "fallback annotation annotation in unreachable code"
warnings when we build with ALL_BUGS_ARE_FATAL. This patch fixes
that.
Fixes bug 40241. Bugfix on 0.3.5.4-alpha.
If we get an address suggestion from a directory authority and we have no
address configured or discovered, log it at notice level so the operator can
learn what address will be used by Tor.
Fixes#40201
Signed-off-by: David Goulet <dgoulet@torproject.org>
It turns out that 9 years ago, we stopped appending data into stats file and
rather overwrite everytime we have new stats (see commit
a6a127c833)
The load_stats_file() function was still thinking that we could have the same
line many times in the file which turns out to be false since 9 years ago.
However, that did not cause problem until IPv6 connection stats came along
which introduced a new line in conn-stats: "ipv6-conn-bi-direct ...".
Before, that file contained a single line starting with the tag
"conn-bi-direct". That very tag appears also in the IPv6 tag (see above) so
the load_stats_file() function would consider that the IPv6 line as the last
tag to be appeneded to the file and fail to report the line above (for IPv4).
It would actually truncate the IPv6 line and report it (removing the "ipv6-"
part).
In other words, "conn-bi-direct" was not reported and instead
"ipv6-conn-bi-direct" was used without the "ipv6-" part.
This commit refactors the entire function so that now it looks for a
"timestamp tag" to validate and then if everything is fine, returns the entire
content of the file. The refactor simplifies the function, adds logging in
case of failures and modernize it in terms of coding standard.
Unit tests are also added that makes sure the loaded content matches the
entire file if timestamp validation passes.
Fixes#40226
Signed-off-by: David Goulet <dgoulet@torproject.org>
When making sure we have a Bridge line with a ClientTransportPlugin, we
now check in the managed proxy list and so we can catch any missing
ClientTransportPlugin for a Bridge line.
Fixes#40106
Signed-off-by: David Goulet <dgoulet@torproject.org>
Generates the compile_commands.json file using the "bear" application so the
ccls server can be more efficient with our code base.
Closes#40227
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, our code would send back an error if the socks5 request
parser said anything but DONE. But there are other non-error cases,
like TRUNCATED: we shouldn't send back errors for them.
This patch lowers the responsibility for setting the error message
into the parsing code, since the actual type of the error message
will depend on what problem was encountered.
Fixes bug 40190; bugfix on 0.3.5.1-alpha.
Previously, "--list-fingerprint --quiet" was an error. Now, the
handler for optional arguments to "--list-fingerprint" can tell that
"--quiet" is a flag, not an argument.
This only affects flags that take an _optional_ argument, so you can
still put your torrc file in a location starting with "-".
Closes#40223.
The "-static" compile flag was set globally which means that all autoconf test
were attempting to be built statically and lead to failures of detecting
OpenSSL libraries and others.
This commit adds this flag only to the "tor" binary build.
There is also a fix on where to find libevent.a since it is using libtool, it
is in .libs/.
At this commit, there are still warnings being emitted that informs the user
that the built binary must still be linked dynamically with glibc.
Fixes#40111
Signed-off-by: David Goulet <dgoulet@torproject.org>
The time diffs were misleading and unpretty when a channel has not seen
a client, a cell or transmitted a cell.
This commit adds some prettier messages.
Fixes#40182
When sending the stream level SENDME, it is possible the cirucit was marked
for close or any other failures that can occur. These events can occur
naturally.
Fixes#40142
Signed-off-by: David Goulet <dgoulet@torproject.org>
The function in charge of removing duplicate ORPorts from our configured ports
was skipping all non ORPorts port but only for the outer loop thus resulting
in comparing an ORPort with a non-ORPort which lead to problems.
For example, tor configured with the following would fail:
ORPort auto
DirPort auto
Both end up being the same configuration except that one is a OR listener and
one is a Dir listener. Thus because of the missing check in the inner loop,
they looked exactly the same and thus one is removed.
Fixes#40195
Signed-off-by: David Goulet <dgoulet@torproject.org>
This changes the behaviour of `tor --version` in such a way.
```console
src/app/tor --version
Tor version 0.4.5.1-alpha-dev (git-46ccde66a97d7985).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1h, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.4.5 and Glibc 2.31 as libc.
Tor compiled with GCC version 10.2.0
```
Fixes#32102
Commit c3a0f75796 added this feature for ORPort
that we ignore any port that is not the family of our default address when
parsing the port. So if port_parse_config() was called with an IPv4 default
address, all IPv6 address would be ignored.
That makes sense for ORPort since we call twice port_parse_config() for
0.0.0.0 and [::] but for the rest of the ports, it is not good since a
perfectly valid configuration can be:
SocksPort 9050
SocksPort [::1]:9050
Any non-ORPort only binds by default to an IPv4 except the ORPort that binds
to both IPv4 and IPv6 by default.
The fix here is to always parse all ports within port_parse_config() and then,
specifically for ORPort, remove the duplicates or superseding ones. The
warning is only emitted when a port supersedes another.
A unit tests is added to make sure SocksPort of different family always exists
together.
Fixes#40183
Signed-off-by: David Goulet <dgoulet@torproject.org>
We already did this, but we did it by accident, which is pretty
risky: if we hadn't, then our code would have treated extra data in
the inbuf as having been transmitted as TLS-authenticated data.
Closes ticket 40017; Found by opara.
Previously, hashlib.shake_256 was a class (if present); now it can
also be a function. This change invalidated our old
compatibility/workaround code, and made one of our tests fail.
Fixes bug 40179; bugfix on 0.3.1.6-rc when the workaround code was
added.
It turns out that STAP_PROBEV() is not available on FreeBSD thus having
sdt/sdt.h is not enough. Look for it now at configure time.
Closes#40174
Signed-off-by: David Goulet <dgoulet@torproject.org>
The loop in the earlier patch would invoke undefined behavior in two
ways: First, it would check whether it was looking at a space before
it checked whether the pointer was in-range. Second, it would let a
pointer reach a position _before_ the start of a string, which is
not allowed.
I've removed the assertion about empty messages: empty messages can
be their own warning IMO.
I've also added tests for this formatting code, to make sure it
actually works.
First I began with a set of candidates:
The client's _required_ list starts with all the protocols
supported by every release in 0.2.9-stable through current
master.
The client's _required_ list starts with all the protocols
supported by every release in 0.3.5-stable through current
master.
Everybody's _recommended_ list starts with all the protocols
supported by every release in 0.3.5-stable through current master.
Then I removed the protocol versions that we do not actually want to
require or recommend:
DirCache=1 (deprecated)
HSDir=1, HSIntro=1-3, HSRend=1 (deprecated)
(All HS* protocol requirements for clients)
Link=1-3 (deprecated)
LinkAuth=1 (obsolete)
Relay=1 (obsolete)
Make it possible to specify multiple ConsensusParams torrc
lines.
Now directory authority operators can for example put the
main ConsensusParams config in one torrc file and then add to it
from a different torrc file.
Closes ticket 40164.
When calling `circpad_send_padding_cell_for_callback()`, the flag
`is_padding_timer_scheduled` was not resetted to 0 which caused an issue
in the circpad simulator.
This commit fixes this problem.
Fixes#32671.
Cons=1 is the old format of consensuses, without ed25519 keys. It
is no longer required or recommended.
Cons=2 is the new format of consensuses, with ed25519 keys. It
is now required.
(Similarly for Desc=1,2 and Microdesc=1,2)
No supported client or relay versions should be affected by this
change, since these versions are supported by clients and relays
running 0.2.9 and later. It will only take effect once enough
authorities vote for it.
Closes ticket 40162.
In brief: we go through a lot of gymnastics to handle huge protover
numbers, but after years of development we're not even close to 10
for any of our current versions. We also have a convenient
workaround available in case we ever run out of protocols: if (for
example) we someday need Link=64, we can just add Link2=0 or
something.
This patch is a minimal patch to change tor's behavior; it doesn't
take advantage of the new restrictions.
Implements #40133 and proposal 318.
Tor has a feature to preserve unrecognized state file entries in
order to maintain forward compatibility. But this feature, along
with some unused code that we never actually removed, led to us
keeping items that were of no use to the user, other than at worst
to preserve ancient information about them.
This commit adds a feature to remove obsolete entries when we load
the file.
Closes ticket 40137.
If at least one service is configured as a version 2, a log warning is emitted
once and only once.
Closes#40003
Signed-off-by: David Goulet <dgoulet@torproject.org>
First, we introduce a flag to teach src/test/test to split its work
into chunks. Then we replace our invocation of src/test/test in our
"make check" target with a set of 8 scripts that invoke the first
8th of the tests, the second 8th, and so on.
This change makes our "make -kj4 check" target in our hardened
gitlab build more than twice as fast, since src/test/test was taking
the longest to finish.
Closes 40098.
This patch adds support for exposing the environment variables
`TOR_PT_OUTBOUND_BIND_ADDRESS_V4` and `TOR_PT_OUTBOUND_BIND_ADDRESS_V6` to
Pluggable Transport proccesses. These two values will contain the IPv4
and IPv6 address that the user have specified in torrc that they wish
the PT to use for all outgoing IP packets.
It is important to note here that it is up to the indvidual Pluggable
Transport if they are willing to honor these values or ignore them
completely.
One can test this feature using the following dummy PT written in POSIX
shell script:
#!/bin/sh
echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv4: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V4}\""
echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv6: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V6}\""
while true ; do
sleep 1
done
with the following entries in your torrc:
OutboundBindAddressPT 203.0.113.4
OutboundBindAddress 203.0.113.5
OutboundBindAddressPT 2001:db8::4
OutboundBindAddress 2001:db8::5
See: https://bugs.torproject.org/5304
[This is a squashed patch for ticket 7193, based on taking a "git
diff" for the original branch, then applying it with "git apply
-3". I earlier attempted to squash the branch with "git rebase",
but there were too many conflicts. --nickm]
The option `--enable-all-bugs-are-fatal` when used with
`--disable-module-relay` caused GCC to warn about functions that
it thought should be labeled noreturn.
I've tried a couple of approaches, but disabling the warning on
these functions seems to be the best approach.
Fixed#40129; bugfix on 0.4.4.1-alpha.
We set this flag if we've launched the connection in order to
satisfy an origin circuit, or when we decide the connection _would_
satisfy an origin circuit. These are the only or_connections we
want to consider for bootstrapping: other or_connections are opened
because of client EXTEND requests, and they may succeed or fail
because of the clients' confusion or misconfiguration.
Closes#25061.
The rend_cache/entry_free was missing the rend cache allocation increment
before freeing the object.
Without it, it had an underflow bug:
Sep 17 08:40:13.845 [warn] rend_cache_decrement_allocation(): Bug: Underflow
in rend_cache_decrement_allocation (on Tor 0.4.5.0-alpha-dev
7eef9ced61)
Fixes#40125
Signed-off-by: David Goulet <dgoulet@torproject.org>
Our code was using [01] as for the key type of signed->link certs,
which was incorrect. The value should be [03], to indicate that the
value as the SHA256 of an x.509 cert.
Fortunately, nothing cares about this value, so there shouldn't be
compatibility issues.
Fixes bug 40124; bugfix on 0.2.7.2-alpha.
tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.
When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.
For this to happen, the cell first passes through command_process_relay_cell()
which normally does the statistics counting. However because the `rend_circ`
circuit was not flagged with `circuit_carries_hs_traffic_stats` in
rend_mid_rendezvous(), the cell is not counted there.
Then the cell goes to circuit_receive_relay_cell() which has a special code
block based on `rend_splice` specifically for rendezvous cells, and the cell
gets directly passed to `rend_circ` via a direct call to
circuit_receive_relay_cell(). The cell never passes through
command_process_relay_cell() ever again and hence is never counted by our
rephist module.
The fix here is to flag the `rend_circ` circuit with
`circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
hits command_process_relay_cell().
Furthermore we avoid double-counting cells since the special code block of
circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
the RP and not as they exit it.
Fixes#40117.
tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.
When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.
For this to happen, the cell first passes through command_process_relay_cell()
which normally does the statistics counting. However because the `rend_circ`
circuit was not flagged with `circuit_carries_hs_traffic_stats` in
rend_mid_rendezvous(), the cell is not counted there.
Then the cell goes to circuit_receive_relay_cell() which has a special code
block based on `rend_splice` specifically for rendezvous cells, and the cell
gets directly passed to `rend_circ` via a direct call to
circuit_receive_relay_cell(). The cell never passes through
command_process_relay_cell() ever again and hence is never counted by our
rephist module.
The fix here is to flag the `rend_circ` circuit with
`circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
hits command_process_relay_cell().
Furthermore we avoid double-counting cells since the special code block of
circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
the RP and not as they exit it.
Fixes#40117.
Opening a new listener connection can fail in many ways like a bind()
permission denied on a low port for instance.
And thus, we should expect to handle an error when creating a new one instead
of assert() on it.
To hit the removed assert:
ORPort 80
KeepBindCapabilities 0
Start tor. Then edit torrc:
ORPort <some-IP>:80
HUP tor and the assert is hit.
Fixes#40073
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, we would treat *any* incoming circuit on a non-local
channel as meaning that our ORPort was reachable. With this patch,
we make sure that the address that the peer _says_ we have is the
same as the one we're trying to advertise right now.
Closes 20165. Bugfix on 4f5192b280 in 0.1.0.1-rc, when
reachability self-tests were first introduced.
Turns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.
This means that a service operator can still enable the defenses but as soon
as the intro point relay would get a new consensus, they would be overwritten.
And at this commit, the network is entirely disabling DoS defenses.
Fix this by introducing an "explicit" flag that indicate if the
ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
using the consenus at once.
We are not bumping the protover HSIntro value for this because 0.4.2.x series
is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
are confident that a backport and then upgrade path to the latest 0.4.4.x
stable coming up soon is enough to mitigate this problem in the coming months.
It avoids the upgrade path on the service side by keeping the requirement for
protover HSIntro=5.
Fixes#40109
Signed-off-by: David Goulet <dgoulet@torproject.org>
First, we introduce a flag to teach src/test/test to split its work
into chunks. Then we replace our invocation of src/test/test in our
"make check" target with a set of 8 scripts that invoke the first
8th of the tests, the second 8th, and so on.
This change makes our "make -kj4 check" target in our hardened
gitlab build more than twice as fast, since src/test/test was taking
the longest to finish.
Closes 40098.
Previous message would say "N messages in the last T seconds", but
would give an inaccurate number for N.
We now give an accurate number, rounded up to the nearest 60 seconds.
Closes#19431.
This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes#40081.
We found this in #40076, after we started using buf_move_all() in
more places. Fixes bug #40076; bugfix on 0.3.3.1-alpha. As far as
I know, the crash only affects master, but I think this warrants a
backport, "just in case".
Without this fix, if an PT forgets to send a USERADDR command, that
results in a connection getting treated as local for the purposes of
rate-limiting.
If the PT _does_ use USERADDR, we still believe it.
Closes ticket 33747.
Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.
Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we don't warn at all when we have
fewer than 25 connections total.
Fixes bug 33880, which seems to have been provoked by our #17592
change in 0.3.5.
This commit makes it that if the ORPort is set with a single port, it will
bind to both global listen IPv4 and IPv6 addresses.
To pin an "ORPort <PORT>" to be IPv4 or IPv6, the IPv4Only/IPv6Only flags are
honored thus this will _only_ bind on IPv6 for that port value:
ORPort 9050 IPv6Only
Results in: [::]:9050
ORPort 9051 IPv4Only
Results in: [0.0.0.0]:9051
Attempting to configure an explicit IPv4 address with IPv6Only flag is an
error and vice versa.
Closes#33246
Signed-off-by: David Goulet <dgoulet@torproject.org>
The need for casting negative syscall arguments depends on the
glibc version. This affects the rules for the openat syscall which
uses the constant AT_FDCWD that is defined as a negative number.
This commit adds logic to only apply the cast when necessary, on
glibc versions from 2.27 onwards.
Different versions of glibc use either open or openat for the
opendir function. This commit adds logic to use the correct rule
for each glibc version, namely:
- Until 2.14 open is used
- From 2.15 to to 2.21 openat is used
- From 2.22 to 2.26 open is used
- From 2.27 onwards openat is used
The need for casting negative syscall arguments depends on the
glibc version. This affects the rules for the openat syscall which
uses the constant AT_FDCWD that is defined as a negative number.
This commit adds logic to only apply the cast when necessary, on
glibc versions from 2.27 onwards.
Instead of replacing connection_t.{addr,port} with a canonical
orport, and tracking the truth in real_addr, we now leave
connection_t.addr alone, and put the canonical address in
canonical_orport.
Closes#40042Closes#33898
(This is not fully general yet: we only pick randomly among
_supported_ addresses, and each extendinfo contains at most one IPv4
address and at most one IPv6 address, no matter what the extend cell
had.)
This change will help dual-stack relays do IPv6 reachability tests,
in theory, by having them sometimes do IPv4 connections and
sometimes do ipv6 connections.
Closes ticket 33220.
Create a doc/tracing/ directory to contain a top level README.md which is the
previously named Tracing.md and add the EventsCircuit.md which describes the
circuit subsystem tracing events in depth.
Closes#40036
Signed-off-by: David Goulet <dgoulet@torproject.org>
This patch ensures that we strip "\r" characters on both Windows as well
as Unix when we read text files. This should prevent the issue where
some Tor state files have been moved from a Windows machine, and thus
contains CRLF line ending, to a Unix machine where only \n is needed.
We add a test-case to ensure that we handle this properly on all our
platforms.
See: https://bugs.torproject.org/tpo/core/tor/33781
This changes a LOT of code but in the end, behavior is the same.
Unfortunately, many functions had to be changed to accomodate but in majority
of cases, to become simpler.
Functions are also removed specifically those that were there to convert an
IPv4 as a host format to a tor_addr_t. Those are not needed anymore.
The IPv4 address field has been standardized to "ipv4_addr", the ORPort to
"ipv4_orport" (currently IPv6 uses ipv6_orport) and DirPort to "ipv4_dirport".
This is related to Sponsor 55 work that adds IPv6 support for relays and this
work is needed in order to have a common interface between IPv4 and IPv6.
Closes#40043.
Signed-off-by: David Goulet <dgoulet@torproject.org>
check-cocci is still a good idea -- perhaps as a cron job? But
doing it as part of our regular tests has just been confusing,
especially to volunteers who shouldn't have to become coccinelle
experts in order to get their patches through our CI.
Closes#40030.
When receiving an introduction NACK, the client either decides to close or
re-extend the circuit to another intro point.
In order to do this, the service descriptor needs to exists but it is possible
that it gets removed from the cache between the establishement of the
introduction circuit and the reception of the (N)ACK.
For that reason, the BUG(desc == NULL) is removed because it is a possible
normal use case. Tor recovers gracefully already.
Fixes#34087
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit modifies the behavior of `parse_extended_address` in such a way
that if it fails, it will always return a `BAD_HOSTNAME` value, which is then
used to return the 0xF6 extended error code. This way, in any case that is
not a valid v2 address, we return the 0xF6 error code, which is the expected
behavior.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This reverts commit bf2a399fc0.
Don't set by default the prefer IPv6 feature on client ports because it breaks
the torsocks use case. The SOCKS resolve command is lacking a mechanism to ask
for a specific address family (v4 or v6) thus prioritizing IPv6 when an IPv4
address is asked on the resolve SOCKS interface resulting in a failure.
Tor Browser explicitly set PreferIPv6 so this should not affect the majority
of our users.
Closes#33796
Signed-off-by: David Goulet <dgoulet@torproject.org>
If no Address statement are found in the configuration file, attempt to learn
our address by looking at the ORPort address if any. Specifying an address is
optional so if we can't find one, it is fine, we move on to the next discovery
mechanism.
Note that specifying a hostname on the ORPort is not yet supported at this
commit.
Closes#33236
Signed-off-by: David Goulet <dgoulet@torproject.org>
For some reasons, Appveyor started to use the stdio printf format for 64 bit
values (PRIu64, ...). Mingw doesn't like that so force it to use the Windows
specific macros by setting D__USE_MINGW_ANSI_STDIO=0.
Fixes#40026
This patch fixes an out-of-bound memory read in
`tor_tls_cert_matches_key()` when Tor is compiled to use Mozilla's NSS
instead of OpenSSL.
The NSS library stores some length fields in bits instead of bytes, but
the comparison function found in `SECITEM_ItemsAreEqual()` needs the
length to be encoded in bytes. This means that for a 140-byte,
DER-encoded, SubjectPublicKeyInfo struct (with a 1024-bit RSA public key
in it), we would ask `SECITEM_ItemsAreEqual()` to compare the first 1120
bytes instead of 140 (140bytes * 8bits = 1120bits).
This patch fixes the issue by converting from bits to bytes before
calling `SECITEM_ItemsAreEqual()` and convert the `len`-fields back to
bits before we leave the function.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
If at least one service is configured as a version 2, a log warning is emitted
once and only once.
Closes#40003
Signed-off-by: David Goulet <dgoulet@torproject.org>
