Look at the address family of the preferred OR port rather than the
node.ipv6_preferred flag since the logic has changed with new
ClientUseIPv6 config option.
Fixes ticket 6884.
Now that crypto_pk_cmp_keys might return the result of tor_memcmp, there
is no guarantee that it will only return -1, 0, or 1. (It currently does
only return -1, 0, or 1, but that's a lucky accident due to details of the
current implementation of tor_memcmp and the particular input given to it.)
Fortunately, none of crypto_pk_cmp_keys's callers rely on this behaviour,
so changing its documentation is sufficient.
Right-shifting negative values has implementation-defined behavior.
On all the platforms we work on right now, the behavior is to
sign-extend the input. That isn't what we wanted in
auth_type_val = (descriptor_cookie_tmp[16] >> 4) + 1;
Fix for 6861; bugfix on 0.2.1.5-alpha; reported pseudonymously.
The broken behavior didn't actually hurt anything, I think, since the
only way to get sign-extension to happen would be to have the top bit
of descriptor_cookie_tmp[16] set, which would make the value of
descriptor_cookie_tmp[16] >> 4 somewhere between 0b11111111 and
0b11111000 (that is, between -1 and -8). So auth_type_val would be
between -7 and 0. And the immediate next line does:
if (auth_type_val < 1 || auth_type_val > 2) {
So the incorrectly computed auth_type_val would be rejected as
invalid, just as a correctly computed auth_type_val would be.
Still, this stuff shouldn't sit around the codebase.
We were doing (1<<p) to generate a flag at position p, but we should
have been doing (U64_LITERAL(1)<<p).
Fixes bug 6861; bugfix on 0.2.0.3-alpha; reported pseudonymously.
add read_file_to_str_until_eof which is used by read_file_to_str
if the file happens to be a FIFO.
change file_status() to return FN_FILE if st_mode matches S_IFIFO
(on not-windows) so that init_key_from_file() will read from a FIFO.
