- 13 Jul, 2020 1 commit
-
-
- 09 Jul, 2020 24 commits
-
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
`-s ours` to avoid version bump.
-
Nick Mathewson authored
-
George Kadianakis authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
David Goulet authored
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>
-
David Goulet authored
-
George Kadianakis authored
It now uses the 'goto err' pattern, instead of the fatal_unreached() pattern. The latter pattern is usually used when there is a loop, but there is no loop in this function so it can be simplified easily.
-
George Kadianakis authored
-
- 08 Jul, 2020 4 commits
-
-
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>
-
Alexander Færøy authored
-
Alexander Færøy authored
-
Alexander Færøy authored
-
- 07 Jul, 2020 6 commits
-
-
Nick Mathewson authored
This warning only affects platforms (like win32) with 32-bit time_t. Fixes bug 40028; bugfix on 0.3.2.8-rc.
-
David Goulet authored
This reverts commit bf2a399f. 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>
-
Alexander Færøy authored
-
Alexander Færøy authored
-
Alexander Færøy authored
-
David Goulet authored
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
-
- 06 Jul, 2020 4 commits
-
-
This patch changes our bits-to-bytes conversion logic in the NSS implementation of `tor_tls_cert_matches_key()` from using (x >> 3) to ((x + 7) >> 3) since DER bit-strings are allowed to contain a number of bits that is not a multiple of 8. Additionally, we add a comment on why we cannot use the `DER_ConvertBitString()` macro from NSS, as we would potentially apply the bits-to-bytes conversion logic twice, which would lead to an insignificant amount of bytes being compared in `SECITEM_ItemsAreEqual()` and thus turn the logic into being a prefix match instead of a full match. The `DER_ConvertBitString()` macro is defined in NSS as: /* ** Macro to convert der decoded bit string into a decoded octet ** string. All it needs to do is fiddle with the length code. */ #define DER_ConvertBitString(item) \ { \ (item)->len = ((item)->len + 7) >> 3; \ } Thanks to Taylor Yu for spotting this problem. This patch is part of the fix for TROVE-2020-001. See: https://bugs.torproject.org/33119
-
We add constness to `peer_info_orig_len` and `cert_info_orig_len` in `tor_tls_cert_matches_key` to ensure that we don't accidentally alter the variables. This patch is part of the fix for TROVE-2020-001. See: https://bugs.torproject.org/33119
-
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
-
This patch lifts the `tor_tls_cert_matches_key()` tests out of the OpenSSL specific TLS test suite and moves it into the generic TLS test suite that is executed for both OpenSSL and NSS. This patch is largely a code movement, but we had to rewrite parts of the test to avoid using OpenSSL specific data-types (such as `X509 *`) and replace it with the generic Tor abstraction type (`tor_x509_cert_impl_t *`). This patch is part of the fix for TROVE-2020-001. See: https://bugs.torproject.org/33119
-
- 03 Jul, 2020 1 commit
-
-
George Kadianakis authored
-