This fixes bug 13102 (not on any released Tor) where using the
standard SSIZE_MAX name broke mingw64, and we didn't realize.
I did this with
perl -i -pe 's/SIZE_T_MAX/SIZE_MAX/' src/*/*.[ch] src/*/*/*.[ch]
Otherwise, when we're out of input *and* finalizing, we might report
TOR_ZLIB_OK erroneously and not finalize the buffer.
(I don't believe this can happen in practice, with our code today:
write_to_buf_zlib ensures that we are never trying to write into a
completely empty buffer, and zlib says "Z_OK" if you give it even
one byte to write into.)
Fixes bug 11824; bugfix on 0.1.1.23 (06e09cdd47).
We're calling mallocfn() and reallocfn() in the HT_GENERATE macro
with the result of a product. But that makes any sane analyzer
worry about overflow.
This patch keeps HT_GENERATE having its old semantics, since we
aren't the only project using ht.h. Instead, define a HT_GENERATE2
that takes a reallocarrayfn.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
This commit attempts to satisfy nickm's comment on check_private_dir() permissions:
https://trac.torproject.org/projects/tor/ticket/11291#comment:12
"""check_private_dir() ensures that the directory has bits 0700 if CPD_CHECK_MODE_ONLY is not set. Shouldn't it also ensure that the directory has bits 0050 if CPD_CHECK_MODE_ONLY is not set, and CPD_GROUP_READ is set?"""
Any error when acquiring the CryptoAPI context should get treated as
bad. Also, this one can't happen for the arguments we're giving.
Fixes bug 10816; bugfix on 0.0.2pre26.
Previously, we had done this only in the connection_free() case, but
when we called connection_free_() directly from
connections_free_all(), we didn't free the connections.
Using the *_array() functions here confused coverity, and was actually
a bit longer than we needed. Now we just use macros for the repeated
bits, so that we can mention a file and a suffix-appended version in
one line.
Previously, we had documented it to return -1 or 0, when in fact
lseek returns -1 or the new position in the file.
This is harmless, since we were only checking for negative values
when we used tor_fd_seekend.
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
Found because LibreSSL has OPENSSL_NO_COMP always-on, but this
conflicts with the way that _we_ turn off compression. Patch from
dhill, who attributes it to "OpenBSD". Fixes bug 12602; bugfix on
0.2.1.1-alpha, which introduced this turn-compression-off code.
