When a SOCKS5 client sends a RESOLVE_PTR request, it must include
either an IPv4 or IPv6 address. In the past this was required to be a
binary address (address types 1 or 4), but since the refactoring of
SOCKS5 support in Tor 0.3.5.1-alpha, strings (address type 3) are also
allowed if they represent an IPv4 or IPv6 literal.
However, when a binary IPv6 address is provided,
parse_socks5_client_request converts it into a string enclosed in
brackets. This doesn't match what string_is_valid_ipv6_address
expects, so this would fail with the error "socks5 received
RESOLVE_PTR command with hostname type. Rejecting."
By replacing string_is_valid_ipv4_address/string_is_valid_ipv6_address
with tor_addr_parse, we accept strings both with and without brackets.
This fixes the handling of binary addresses, and also improves
symmetry with CONNECT and RESOLVE requests.
Fixes bug 32315.
Install the mingw OpenSSL package in Appveyor. This makes sure that
the OpenSSL headers and libraries match in Tor's Appveyor builds.
(This bug was triggered by an Appveyor image update.)
Fixes bug 32449; bugfix on 0.3.5.6-rc.
It no longer warns, and is now defined in terms of an "IGNORE" type.
(The "IGNORE" type is the same as "OBSOLETE", except that it is not
reported as obsolete. It should be useful for disabled modules.)
Closes ticket 32404.
When we are failing because of a lack of a _required_ engine, note
that the engine was "required".
When engines are disabled, any required engine should cause a
failure.
We still interpret "AccelName" as turning on the "HardwareAccel"
feature, but we no longer modify the user's options here.
Fixes bug 32382; bugfix on 0.2.2.1-alpha when we added openssl
engine support.
In our old design, we had to declare configuration structures (like
or_options_t) and variable tables (like option_vars_) separately,
and we used some magic to enforce their consistency (see
conftesting.h).
With this design, we write a single definition for the configuration
object and its fields, and use C macros to expand it either into a
structure, or a variable table. Since they are both made from the
same source, they can't become inconsistent.
The two designs can coexist happily, and we can migrate from one to
the other at our convenience.
This file is a workaround for the issue that if you say `a ## b` to
create a token that is the name of a macro, the C preprocessor won't
expand that macro. So you can't say this:
#define FOO__SQUARE(x) ((x)*(x))
#define FOO__CUBE(x) ((x)*(x)*(x))
#define FOO(func, x) FOO__##func(x)
Instead, the standard C trick is to add a layer of indirection:
#define PASTE(a,b) PASTE__(a,b)
#define PASTE__(a,b) a ## b
#define FOO__SQUARE(x) ((x)*(x))
#define FOO__CUBE(x) ((x)*(x)*(x))
#define FOO(func, x) PASTE(FOO__, func)(x)
We should use this kind of trick sparingly, since it gets confusing.
