| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There's an incorrect comment in compat_time.c that suggests we call
FreeLibrary() before we're done using the library's functions.
See 29642 for background.
Closes ticket 29643.
|
|
|
|
|
|
|
|
|
|
This test was previously written to use the contents of the system
headers to decide whether INHERIT_NONE or INHERIT_ZERO was going to
work. But that won't work across different environments, such as
(for example) when the kernel doesn't match the headers. Instead,
we add a testing-only feature to the code to track which of these
options actually worked, and verify that it behaved as we expected.
Closes ticket 29541; bugfix not on any released version of Tor.
|
|
I'm not removing the weak_rng code itself yet, since it is possible
that we will want to revert one of these.
|
|
|
|
The subsystems API makes this really simple, fortunately.
Closes ticket 29536
|
|
|
|
|
|
|
|
This module is currently implemented to use the same technique as
libottery (later used by the bsds' arc4random replacement), using
AES-CTR-256 as its underlying stream cipher. It's backtracking-
resistant immediately after each call, and prediction-resistant
after a while.
Here's how it works:
We generate psuedorandom bytes using AES-CTR-256. We generate BUFLEN bytes
at a time. When we do this, we keep the first SEED_LEN bytes as the key
and the IV for our next invocation of AES_CTR, and yield the remaining
BUFLEN - SEED_LEN bytes to the user as they invoke the PRNG. As we yield
bytes to the user, we clear them from the buffer.
Every RESEED_AFTER times we refill the buffer, we mix in an additional
SEED_LEN bytes from our strong PRNG into the seed.
If the user ever asks for a huge number of bytes at once, we pull SEED_LEN
bytes from the PRNG and use them with our stream cipher to fill the user's
request.
|
|
This is the second part of refactoring the random-int-in-range code.
|
|
|
|
|
|
Closes ticket 29026; patch from Mangix.
|
|
Patch from Mangix. Closes part of ticket 29026.
|
|
Some of the code for getting a random value within a range wants to
be shared between crypto_rand() and the new crypto_fast_rng() code.
|
|
I don't know how this got here, but this kind of a wrapper only
belongs in a header file.
|
|
Using an anonymous mmap() is a good way to get pages that we can set
kernel-level flags on, like minherit() or madvise() or mlock().
We're going to use that so that we can make uninheritable locked
pages to store PRNG data.
|
|
|
|
These are ones that happen on windows only.
Fixes bug 29161.
|
|
SO_ACCEPTCONN checks whether socket listening is enabled and is
used ever since 9369152aae9527cc3764 has been merged.
Closes ticket #29150
|
|
|
|
|
|
Motivation:
1. It's convenient.
2. It's all that openssl supports.
Part of 28837.
|
|
Part of 28837.
|
|
|
|
This fixes a typo and also notes that HW_PHYSMEM64 is defined on
NetBSD (not just OpenBSD).
Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
|
|
The code checked for sysctl being available and HW_PHYSMEM being
defined, but HW_USERMEM was actually being used with sysctl instead
of HW_PHYSMEM.
The case for OpenBSD, etc. use HW_PHYSMEM64 (which is obviously a
64-bit variant of HW_PHYSMEM) and the case for OSX uses HW_MEMSIZE
(which appears to be a 64-bit variant of HW_PHYSMEM).
Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
|
|
We log these messages at INFO level, except when we are reading a
private key from a file, in which case we log at WARN.
This fixes a regression from when we re-wrote our PEM code to be
generic between nss and openssl.
Fixes bug 29042, bugfix on 0.3.5.1-alpha.
|
|
|
|
|
|
|
|
|
|
When cleaning up after an error in process_unix_exec, the stdin
pipe was being double closed instead of closing both the stdin
and stdout pipes. This occurred in two places.
Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
|
|
|
|
NOTE: This commit breaks the build, because there was a mistake in an
earlier change of exactly the sort that this is meant to detect! I'm
leaving it broken for illustration.
|
|
|
|
Test exactly what the geometric sampler returns, because that's what
the downstream callers of it are going to use.
While here, also assert that the geometric sampler returns a positive
integer. (Our geometric distribution is the one suported on {1, 2,
3, ...} that returns the number of trials before the first success,
not the one supported on {0, 1, 2, ...} that returns the number of
failures before the first success.)
|
|
See https://github.com/torproject/tor/pull/624#discussion_r246453777
|
|
|
