Commit Graph

10011 Commits

Author SHA1 Message Date
Alexander Færøy
bab2b29f89 Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-25 13:25:23 +00:00
Alexander Færøy
4a7379b80a Merge branch 'maint-0.4.4' into maint-0.4.5 2021-05-25 13:25:23 +00:00
Alexander Færøy
11c7e65730 Merge branch 'maint-0.3.5' into maint-0.4.4 2021-05-25 13:25:23 +00:00
Nick Mathewson
42ba87d964 Remove the function tor_tls_assert_renegotiation_unblocked.
It was used nowhere outside its own unit tests, and it was causing
compilation issues with recent OpenSSL 3.0.0 alphas.

Closes ticket 40399.
2021-05-25 07:38:31 -04:00
Nick Mathewson
debede5e50 Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-17 09:09:49 -04:00
Nick Mathewson
97b61e21a9 Merge remote-tracking branch 'tor-gitlab/mr/387' into maint-0.4.5 2021-05-17 09:09:42 -04:00
Nick Mathewson
fbd47a5078 Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-17 09:04:22 -04:00
Daniel Pinto
e0a8454691 Make SAVECONF keep only one backup and add sandbox rules for it. #40317
When seccomp sandbox is active, SAVECONF failed because it was not
able to save the backup files for torrc. This commit simplifies
the implementation of SAVECONF and sandbox by making it keep only
one backup of the configuration file.
2021-05-17 13:50:19 +02:00
David Goulet
5f009a59da conn: MetricsPort listener is a listener port
The connection type for the listener part was missing from the "is
connection a listener" function.

This lead to our periodic event that retries our listeners to keep
trying to bind() again on an already opened MetricsPort.

Closes #40370

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-05-12 15:13:50 -04:00
Nick Mathewson
8851861ff0 Merge branch 'ticket40374_046' into maint-0.4.6 2021-05-10 14:30:00 -04:00
Nick Mathewson
e4f2b52deb Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-07 13:08:25 -04:00
Nick Mathewson
f5acfe6723 Add a sandbox workaround for Glibc 2.33
This change permits the newfstatat() system call, and fixes issues
40382 (and 40381).

This isn't a free change.  From the commit:

    // Libc 2.33 uses this syscall to implement both fstat() and stat().
    //
    // The trouble is that to implement fstat(fd, &st), it calls:
    //     newfstatat(fs, "", &st, AT_EMPTY_PATH)
    // We can't detect this usage in particular, because "" is a pointer
    // we don't control.  And we can't just look for AT_EMPTY_PATH, since
    // AT_EMPTY_PATH only has effect when the path string is empty.
    //
    // So our only solution seems to be allowing all fstatat calls, which
    // means that an attacker can stat() anything on the filesystem. That's
    // not a great solution, but I can't find a better one.
2021-05-07 12:12:11 -04:00
Nick Mathewson
5acf18bfaa Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-07 10:41:34 -04:00
Nick Mathewson
7c86f34340 Merge branch 'maint-0.4.4' into maint-0.4.5 2021-05-07 10:41:34 -04:00
Nick Mathewson
48dd87933d Merge branch 'maint-0.3.5' into maint-0.4.4 2021-05-07 10:41:33 -04:00
Nick Mathewson
e2c1ac214c Reindent a few lines to fix a GCC warning.
As of GCC 11.1.1, the compiler warns us about code like this:

     if (a)
         b;
         c;

and that's a good thing: we wouldn't want to "goto fail".  But we
had an instance if this in circuituse.c, which was making our
compilation sad.

Fixes bug 40380; bugfix on 0.3.0.1-alpha.
2021-05-07 10:39:20 -04:00
Nick Mathewson
0397a9cb49 Merge branch 'maint-0.4.5' into maint-0.4.6 2021-05-07 09:53:58 -04:00
Nick Mathewson
7fe819c951 Merge branch 'maint-0.4.4' into maint-0.4.5 2021-05-07 09:53:58 -04:00
Nick Mathewson
f68aeda549 Merge branch 'maint-0.3.5' into maint-0.4.4 2021-05-07 09:53:57 -04:00
Nick Mathewson
621f8a304a Update geoip files to match ipfire location db, 2021/05/07. 2021-05-07 09:53:46 -04:00
George Kadianakis
80c404c4b7 Log warning when connecting to soon-to-be-deprecated v2 onions. 2021-05-07 08:44:36 -04:00
George Kadianakis
5e836eb80c Add warning when trying to connect to deprecated v2 onions. 2021-05-07 08:41:46 -04:00
David Goulet
cf6e72b702 hs: Fix ADD_ONION with client authorization
Turns out that passing client authorization keys to ADD_ONION for v3 was
not working because we were not setting the "is_client_auth_enabled"
flag to true once the clients were configured. This lead to the
descriptor being encoded without the clients.

This patch removes that flag and instead adds an inline function that
can be used to check if a given service has client authorization
enabled.

This will be much less error prone of needing to keep in sync the client
list and a flag instead.

Fixes #40378

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-05-04 10:37:26 -04:00
Nick Mathewson
8d0d7a665a Remove NEED_SKEY_1024 parsing.
Only v2 onion services needed this, and they are now gone.

Closes #40374.
2021-04-23 15:55:51 -04:00
George Kadianakis
f0260c4cea Merge branch 'maint-0.4.5' into maint-0.4.6 2021-04-23 13:00:23 +03:00
David Goulet
8c29729916 hs: Fix memory leak in client cache
Fixes #40356

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-21 11:37:46 -04:00
Nick Mathewson
0ceacb5482 Merge branch 'mr_347_squashed' into maint-0.4.6 2021-04-19 11:40:44 -04:00
David Goulet
6281c90885 relay: Emit log warning if Address is internal and can't be used
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-19 11:40:30 -04:00
Nick Mathewson
d162b98548 Merge branch 'maint-0.4.5' into maint-0.4.6 2021-04-19 11:30:00 -04:00
Nick Mathewson
cd75eac743 Tweak changes/ticket40369 to be a bug. 2021-04-19 11:29:46 -04:00
Emery Hemingway
f47c6c3d1b scripts/build/combine_libs: use $AR rather than ar
Using a custom ar at $AR may be necessary for cross-compilation.

Closes #40369

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-19 11:28:20 -04:00
George Kadianakis
461a3c732b Merge branch 'maint-0.4.5' into maint-0.4.6 2021-04-19 17:33:46 +03:00
George Kadianakis
925ec0e0ea Merge remote-tracking branch 'tor-gitlab/mr/355' into maint-0.4.5 2021-04-19 17:32:56 +03:00
Nick Mathewson
33ca927a8e Start a changes file for 0.4.6.2-alpha 2021-04-14 10:58:15 -04:00
Nick Mathewson
2815721243 Merge branch 'maint-0.4.5' 2021-04-13 17:00:56 -04:00
Nick Mathewson
59bc377dce Merge branch 'maint-0.4.4' into maint-0.4.5 2021-04-13 16:59:16 -04:00
Nick Mathewson
59f6248e09 Merge branch 'maint-0.3.5' into maint-0.4.4 2021-04-13 16:59:15 -04:00
David Goulet
ee7c50b8a7 fallbackdir: Renegerate list with 200 relays
Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-13 15:15:58 -04:00
Alexander Færøy
705ea32c6e relay: Move "overload-general" from extra-info to server descriptor.
Fixes #40364

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-13 15:11:03 -04:00
Nick Mathewson
1f21b6e6a7 Merge branch 'maint-0.4.4' into maint-0.4.5 2021-04-13 10:36:01 -04:00
Nick Mathewson
1b48a28a74 Merge branch 'maint-0.4.5' 2021-04-13 10:36:01 -04:00
Nick Mathewson
b323e6b8c2 Merge branch 'maint-0.3.5' into maint-0.4.4 2021-04-13 10:36:00 -04:00
Nick Mathewson
32f5ad7665 Update geoip files to match ipfire location db, 2021/04/13. 2021-04-13 10:35:50 -04:00
Nick Mathewson
0d63b19afa Merge branch 'maint-0.4.5' 2021-04-13 09:41:13 -04:00
David Goulet
218f9f90fb guard: Don't check bridge transport name when selecting eligible guards
This is related to ticket #40360 which found this problem when a Bridge entry
with a transport name (let say obfs4) is set without a fingerprint:

  Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0

(Notice, no fingerprint between PORT and "cert=")

Problem: commit 09c6d03246 added a check in
get_sampled_guard_for_bridge() that would return NULL if the selected bridge
did not have a valid transport name (that is the Bridge transport name that
corresponds to a ClientTransportPlugin).

Unfortuantely, this function is also used when selecting our eligible guards
which is done *before* the transport list is populated and so the added check
for the bridge<->transport name is querying an empty list of transports
resulting in always returning NULL.

For completion, the logic is: Pick eligible guards (use bridge(s) if need be)
then for those, initiate a connection to the pluggable transport proxy and
then populate the transport list once we've connected.

Back to get_sampled_guard_for_bridge(). As said earlier, it is used when
selecting our eligible guards in a way that prevents us from selecting
duplicates. In other words, if that function returns non-NULL, the selection
continues considering the bridge was sampled before. But if it returns NULL,
the relay is added to the eligible list.

This bug made it that our eligible guard list was populated with the *same*
bridge 3 times like so (remember no fingerprint):

  [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is:
  [info] entry_guards_update_primary():   1/3: [bridge] ($0000000000000000000000000000000000000000)
  [info] entry_guards_update_primary():   2/3: [bridge] ($0000000000000000000000000000000000000000)
  [info] entry_guards_update_primary():   3/3: [bridge] ($0000000000000000000000000000000000000000)

When tor starts, it will find the bridge fingerprint by connecting to it and
will then update the primary guard list by calling
entry_guard_learned_bridge_identity() which then goes and update only 1 single
entry resulting in this list:

  [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed.
  [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.
  [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.

And here lies the problem, now tor is stuck attempting to wait for a valid
descriptor for at least 2 guards where the second one is a bunch of zeroes and
thus tor will never fully bootstraps:

  [info] I learned some more directory information, but not enough to build a
  circuit: We're missing descriptors for 1/2 of our primary entry guards
  (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing
  descriptors soon.

Now, why passing the fingerprint then works? This is because the list of
guards contains 3 times the same bridge but they all have a fingerprint and so
the descriptor can be found and tor can bootstraps.

The solution here is to entirely remove the transport name check in
get_sampled_guard_for_bridge() since the transport_list is empty at that
point. That way, the eligible guard list only gets 1 entry, the bridge, and
can then go on to bootstrap properly.

It is OK to do so since when launching a bridge descriptor fetch, we validate
that the bridge transport name is OK and thus avoid connecting to a bridge
without a ClientTransportPlugin. If we wanted to keep the check in place, we
would need to populate the transport_list much earlier and this would require
a much bigger refactoring.

Fixes #40360

Signed-off-by: David Goulet <dgoulet@torproject.org>
2021-04-08 14:08:28 -04:00
George Kadianakis
62614f0b3f Merge remote-tracking branch 'tor-gitlab/mr/354' 2021-04-08 14:37:30 +03:00
George Kadianakis
e0b8a79b2e Merge branch 'maint-0.4.5' 2021-04-08 14:29:08 +03:00
George Kadianakis
b07ed22cbb Merge remote-tracking branch 'tor-gitlab/mr/273' 2021-04-08 14:20:53 +03:00
Nick Mathewson
02816d6059 Try making our configure.ac script build with AC 2.70.
In versions <=2.69, according to the autoconf docs, AC_PROG_CC_C99
is needed with some compilers, if they require extra arguments to
build C99 programs.  In versions >=2.70, AC_PROG_CC checks for these
compilers automatically, and so the AC_PROG_CC_C99 macro is
obsolete.

So, what can you do if you want your script to work right with both
autoconf versions?  IIUC, neither including AC_PROG_CC_C99 macro nor
leaving it out will give you the right behavior with both versions.
It looks like you need to look at the autoconf version explicitly.

(Now, the autoconf manual implies that it's "against autoconf
philosophy" to look at the autoconf version rather than trying the
behavior to see if it works, but they don't actually tell you how to
detect recoverably at autoconf-time whether a macro is obsolete or
not, and I can't find a way to do that.)

So, is it safe to use m4_version_prereq, like I do here?  It isn't
listed in the autoconf 2.63 manual (which is the oldest version we
support).  But a mailing list message [1] (which added the
documentation back in 2008) implies that m4_version_prereq has been
there since "at least back to autoconf 2.59".

https://lists.gnu.org/archive/html/autoconf-patches/2008-12/msg00025.html

So I think this will work.

I am basing this patch against Tor 0.3.5 since, if autoconf 2.70
becomes widespread before 0.3.5 is unsupported, we might need this
patch to continue 0.3.5 development.  But I don't think we should
backport farther than 0.4.5 until/unless that actually happens.

This is part of a fix for #40355.
2021-04-07 10:18:44 -04:00
Daniel Pinto
ce60454afd Add long format name --torrc-file for command line option -f. #40324 2021-03-28 03:56:31 +01:00