We can treat this case as an EAGAIN (probably because of an
unexpected internal NUL) rather than a crash-worthy problem.
Fixes bug 6225, again. Bug not in any released version of Tor.
Because the string output was no longer equal in length to
HEX_ERRNO_SIZE, the write() call would add some extra spaces and
maybe a NUL, and the NUL would trigger an assert in
get_string_from_pipe.
Fixes bug 6225; bug not in any released version of Tor.
This is a feature removal: we no longer fake any ciphersuite other
than the not-really-standard SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
(0xfeff). This change will let servers rely on our actually
supporting what we claim to support, and thereby let Tor migrate to
better TLS ciphersuites.
As a drawback, Tor instances that use old openssl versions and
openssl builds with ciphers disabled will no longer give the
"firefox" cipher list.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
These include:
- Having a weird in_addr that can't be initialized with {0}
- Needing INVALID_HANDLE_VALUE instead of -1 for file handles.
- Having a weird dependent definition for struct stat.
- pid is signed, not unsigned.
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
It appears that when OpenSSL negotiates a 1.1 or 1.2 connection, and it
decides to renegotiate, the client will send a record with version "1.0"
rather than with the current TLS version. This would cause the
connection to fail whenever both sides had OpenSSL 1.0.1, and the v2 Tor
handshake was in use.
As a workaround, disable TLS 1.1 and TLS 1.2. When a later version of
OpenSSL is released, we can make this conditional on running a fixed
version of OpenSSL.
Alternatively, we could disable TLS 1.1 and TLS 1.2 only on the client
side. But doing it this way for now means that we not only fix TLS with
patched clients; we also fix TLS when the server has this patch and the
client does not. That could be important to keep the network running
well.
Fixes bug 6033.
Conflicts:
src/test/test_util.c
Merge the unit tests; I added some when I did this branch against
0.2.2, and then the test format changed and master added more tests.
Conflicts:
src/common/compat.h
Conflict was between replacement of MS_WINDOWS with _WIN32 in
master, and with removal of file_handle from tor_mmap_t struct in
close_file_mapping branch (for bug 5951 fix).
It turns out that if you set the third argument of
__attribute__(format) to 0, GCC and Clang will check the format
argument without expecting to find variadic arguments. This is the
correct behavior for vsnprintf, vasprintf, and vscanf.
I'm hoping this will fix bug 5969 (a clang warning) by telling clang that
the format argument to tor_vasprintf is indeed a format string.
The parent of "/foo" is "/"; and "/" is its own parent.
This would cause Tor to fail if you tried to have a PF_UNIX control
socket in the root directory. That would be a stupid thing to do
for other reasons, but there's no reason to fail like _this_.
Bug found by Esteban Manchado Velázquez. Fix for bug 5089; bugfix on
Tor 0.2.2.26-beta. Unit test included.
* It seems parse_http_time wasn't parsing correctly any date with commas (RFCs
1123 and 850). Fix that.
* It seems parse_http_time was reporting the wrong month (they start at 0, not
1). Fix that.
* Add some tests for parse_http_time, covering all three formats.
