Commit Graph

36674 Commits

Author SHA1 Message Date
David Goulet
c5817a0daf m4: Change LIBS order of TOR_SEARCH_LIBRARY()
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>
2021-01-13 09:52:10 -05:00
George Kadianakis
c931eae981 Merge branch 'mr/252' into maint-0.4.5 2021-01-13 16:01:11 +02:00
Nick Mathewson
4d6d3b3c05 Remove BUG() when checking TOO_MANY_OUTDATED_DIRSERVERS.
Fixes bug #40234; bugfix on 0.3.2.5-alpha.
2021-01-13 16:00:54 +02:00
Nick Mathewson
01be7cc535 Bump to 0.4.5.3-rc-dev 2021-01-12 16:08:07 -05:00
David Goulet
9b59ede8d3 Merge branch 'ticket40237_044_01' into ticket40237_045_01 2021-01-12 10:55:21 -05:00
David Goulet
b3652f2104 Merge branch 'ticket40237_043_01' into ticket40237_044_01 2021-01-12 10:54:31 -05:00
David Goulet
0485c7ddba tests: Fix unit tests after merge of #40237 2021-01-12 10:50:01 -05:00
David Goulet
60da5d6222 Merge branch 'ticket40237_035_01' into ticket40237_043_01 2021-01-12 10:46:25 -05:00
David Goulet
04b0263974 hs-v3: Require reasonably live consensus
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>
2021-01-12 09:46:35 -05:00
Nick Mathewson
ca6ccd372f Reject obsolete router/extrainfo descs more quietly.
Thanks to proposal 315 / ticket #30132, more fields are now
required in these documents.  But ancient Tors that try to upload
obsolete documents were causing the authorities to log warnings
about missing fields, and to do so very spammily.

We now detect the missing fields before tokenizing, and log at
debug.  This is a bit of ugliness, but it's probably a safer choice
than making _all_ unparseable-desc warnings into debug-level logs.

I'm looking at identity-ed25519 in extrainfos and proto in
routerdescs because they were (I believe) the latest-added fields in
Tor's history: any Tor that lacks them will also lack the other
newly required fields.

Fixes bug #40238; bugfix on 0.4.5.1-alpha.
2021-01-11 14:50:40 -05:00
Nick Mathewson
5a822b462a Merge branch 'maint-0.4.3' into maint-0.4.4 2021-01-11 14:37:29 -05:00
Nick Mathewson
d1f4741606 Merge branch 'maint-0.4.4' into maint-0.4.5 2021-01-11 14:37:29 -05:00
Nick Mathewson
4b39f46a61 Merge branch 'maint-0.3.5' into maint-0.4.3 2021-01-11 14:37:28 -05:00
Nick Mathewson
6c0f15500b Merge branch 'ticket40241_035' into maint-0.3.5 2021-01-11 14:37:14 -05:00
Nick Mathewson
ccdbbae4ec Fix warnings in current debian-hardened CI.
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.
2021-01-11 14:25:56 -05:00
Nick Mathewson
edc9fda4f5 Increment version to 0.4.5.3-rc 2021-01-11 12:48:00 -05:00
David Goulet
aae9a05a01 relay: Log address suggested by directory authorities
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>
2020-12-21 14:41:52 -05:00
Nick Mathewson
ad00da663e Merge branch 'mr_240_squashed' into maint-0.4.5 2020-12-21 13:25:52 -05:00
David Goulet
f4cbcde2da test: Fix memleak in test/load_stats_file
Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-12-21 13:18:20 -05:00
Karsten Loesing
5dd6304f36 Fix timestamp parser in new load_stats_file.
The previous parser only considered stats files _starting_ with the
timestamp tag, not stats files having the timestamp tag in a later
position. While this applies to all current stats files, a future
stats file might look differently. Better to fix the function now than
be surprised in another 9 years from now.

This commit also adds a test case for such future stats, and it fixes
stats file paths in newly added unit tests.
2020-12-21 13:18:20 -05:00
David Goulet
c934fced31 relay: Report the entire content of a stats file
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>
2020-12-21 13:18:20 -05:00
David Goulet
d45354d5ea Merge branch 'tor-gitlab/mr/243' into maint-0.4.5 2020-12-17 08:25:18 -05:00
George Kadianakis
d89974c5c6 Fix Keccak undefined behavior on exotic platforms.
Bug reported and diagnosed in:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977

Fixes bug #40210.
2020-12-17 13:49:17 +02:00
Alexander Færøy
5a2d01ae57 Merge branch 'tor-gitlab/mr/234' into maint-0.4.5 2020-12-16 20:38:23 +00:00
David Goulet
ee6ad0e592 config: Catch missing Bridge for ClientTransportPlugin
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>
2020-12-16 20:37:57 +00:00
Alexander Færøy
b83777f7b2 Merge remote-tracking branch 'tor-gitlab/mr/238' into maint-0.4.5 2020-12-16 20:31:10 +00:00
Alexander Færøy
7998ea2f18 Merge remote-tracking branch 'tor-gitlab/mr/237' into maint-0.4.5 2020-12-16 20:29:03 +00:00
David Goulet
4a77aa6e82 Merge branch 'tor-gitlab/mr/239' into maint-0.4.5 2020-12-15 11:58:13 -05:00
George Kadianakis
c731a4efec Merge remote-tracking branch 'tor-gitlab/mr/205' into maint-0.4.5 2020-12-15 16:28:49 +02:00
Nick Mathewson
c4fe66e342 Socks5: handle truncated client requests correctly
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.
2020-12-14 10:14:03 -05:00
David Goulet
15b0d30a55 configure: Revert back the static libevent path
From c618c4f279, we changed the static
libevent.a path to be able to use the git repository or tarball directly but
that broke the "make install" setup that Tor Browser is using with Android.

In other words, the git repository and tarball put the "libevent.a" in
".libs/" where "make install" puts it in "lib/".

Using the --with-libevent-dir=..., which is mandatory for static libevent,
autoconf will take the path and use it for the includes (-I) and library (-L)
for which if it finds a "include/" and a "lib/" in the root, it will use
those.

However, with the git repo or tarball, the "lib/" doesn't exists thus autoconf
sets the library search path to be at the root and thus fails to find the
libevent.a in ".libs/".

This is a whole lot more work to make both cases work in our configure.ac thus
I'm reverting the change here to the Tor Browser case works again and the work
around for others is to either symlink the libevent.a at the root or use a
temporary make install directory.

One long term fix here would likely be to ask libevent to symblink the .a into
the root along the .la files and likely do the same for .so. Or, use the
"lib/" structure to contain the .a + .so files. Would be better than doing
ninji-tsu in our configure.ac

Fixes #40225

Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-12-11 09:52:23 -05:00
Nick Mathewson
34baa1bdc3 Tweak the documentation for approved-routers
Document !badexit, and improve the documentation for !invalid.

Closes #40188.
2020-12-09 14:08:55 -05:00
Daniel Pinto
bd0046c9ec Avoid sandbox bug warning when unglobbing patterns #40094
Adds a more user-friendly error message when the configuration is
reloaded and a new %include is added that makes its unglobbing
access files/folders not allowed by the seccomp sandbox.
2020-12-08 15:00:43 -05:00
Nick Mathewson
baef0843a4 Fix a couple of documentation comments related to #40094 2020-12-08 14:59:28 -05:00
David Goulet
e74f168bb4 relay: Avoid log reachability test for bandwidth test circuit
Fixes #40205

Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-12-08 14:51:31 -05:00
David Goulet
c618c4f279 configure: Fix the --enable-static-tor switch
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>
2020-12-08 09:14:49 -05:00
Nick Mathewson
2f87b2ab75 bump to 0.4.5.2-alpha-dev 2020-11-23 14:03:53 -05:00
Nick Mathewson
73fb44dcba Bump to 0.4.5.2-alpha. 2020-11-21 15:09:08 -05:00
Alexander Færøy
b274e46309 Merge branch 'maint-0.4.4' into maint-0.4.5 2020-11-19 17:44:00 +00:00
Alexander Færøy
77bb4b0838 Merge branch 'maint-0.4.3' into maint-0.4.4 2020-11-19 17:43:59 +00:00
Alexander Færøy
2e7cbd7a9c Merge remote-tracking branch 'tor-gitlab/mr/196' into maint-0.4.3 2020-11-19 17:43:44 +00:00
David Goulet
ea52705e4b config: Bridge line with a transport must have a ClientTransportPlugin
Fixes #25528

Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-11-18 11:31:37 -05:00
David Goulet
fcf5bbb59f Merge branch 'tor-gitlab/mr/144' into maint-0.4.5 2020-11-18 11:29:02 -05:00
David Goulet
16351d655d sendme: Turn log warning into debug
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>
2020-11-17 13:23:34 -05:00
David Goulet
07006785fd Merge branch 'tor-gitlab/mr/203' into maint-0.4.5 2020-11-17 12:25:48 -05:00
David Goulet
d04a27bed2 config: Really ignore non ORPorts when removing duplicates
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>
2020-11-17 09:40:16 -05:00
Nick Mathewson
b13f32ee97 Merge branch 'ticket40071_045_01_squashed' into master 2020-11-17 07:58:37 -05:00
David Goulet
9aaac94cc3 changes: Add file for #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-11-17 07:58:26 -05:00
David Goulet
bc5f26ff70 relay: Launch dummy circuit only when descriptor build fails
First, this commit moves the launch_dummy_circuit_as_needed() function into
relay_find_addr.c and renames it to relay_addr_learn_from_dirauth(). This is
an attempt to centralize anything relate with address discovery in the right
module.

Second, when building a descriptor and we fail to discover our address,
immediately launch a dummy circuit to an authority in an attempt to learn our
descriptor.

It is still only done every 20 minutes even though the descriptor build is
done every minute. We ought to avoid load on the authority and if we can't
learn in the first place our address from them, chances are more things are
wrong.

Related to #40071

Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-11-17 07:58:26 -05:00
David Goulet
a5538a3603 relay: Look at our cache when looking for an IP change
Regularly, tor looks if its IP has changed. It does the entire auto discovery
process again. However, it is possible that it does not find anything.

Instead of thinking the IP changed to an unknown address, look at our cache
and see if that value has changed.

The reason for this is because if tor gets its address as a suggestion from a
directory authority, it is because the auto discovery failed and thus that
address should be consider for the IP change check.

Related to #40071

Signed-off-by: David Goulet <dgoulet@torproject.org>
2020-11-17 07:58:26 -05:00