Nick Mathewson [Sun, 16 Apr 2017 21:13:39 +0000 (17:13 -0400)]
Remove a checklist item that was already tested
The item referred to the cdm_ht_set_status() case where the item was
not already in the hashtable. But that already happens naturally
when we scan the directory on startup... and we already have a test
for that.
Nick Mathewson [Sun, 16 Apr 2017 15:51:14 +0000 (11:51 -0400)]
consdiffmgr tests: add tests to validate diff lookup/application
This commit adds some helper functions to look up the diff from one
consensus and to make sure that applying it leads to another. Then
we add them throughout the existing test cases. Doing this turned
up a reference-leaking bug in consensus_diff_worker_replyfn.
Nick Mathewson [Sat, 15 Apr 2017 17:23:10 +0000 (13:23 -0400)]
Add a hashtable to consdiffmgr to keep track of diff status
In several places in the old code, we had problems that only an
in-memory index of diff status could solve, including:
* Remembering which diffs were in-progress, so that we didn't
re-launch them.
* Remembering which diffs had failed, so that we didn't try to
recompute them over and over.
* Having a fast way to look up the diff from a given consensus to
the latest consensus of a given flavor.
This patch adds a hashtable mapping from (flavor, source diff), to
solve the problem. It maps to a cache entry handle, rather than to
a cache entry directly, so that it doesn't affect the reference
counts of the cache entries, and so that we don't otherwise need to
worry about lifetime management.
Nick Mathewson [Sat, 15 Apr 2017 15:31:09 +0000 (11:31 -0400)]
Consdiffmgr: use aggressive-release flag on consensuses
This conscache flag tells conscache that it should munmap the
document as soon as reasonably possible, since its usage pattern is
expected to not have a lot of time-locality.
Nick Mathewson [Fri, 14 Apr 2017 16:35:02 +0000 (12:35 -0400)]
Unit tests for consdiffmgr module
Initial tests. These just try adding a few consensuses, looking
them up, and making sure that consensus diffs are generated in a
more or less reasonable-looking way. It's enough for 87% coverage,
but it leaves out a lot of functionality.
Nick Mathewson [Thu, 6 Apr 2017 18:46:45 +0000 (14:46 -0400)]
Add a "Consensus diff manager" module.
This module's job is to remember old consensus documents, to
calculate their diffs on demand, and to .
There are some incomplete points in this code; I've marked them with
"XXXX". I intend to fix them in separate commits, since I believe
doing it in separate commits will make the branch easier to review.
David Goulet [Fri, 21 Apr 2017 15:49:30 +0000 (11:49 -0400)]
control: Wrong check on base16_decode return value
The GETINFO extra-info/digest/<digest> broke in commit 568dc27a19 that
refactored the base16_decode() API to return the decoded length.
Unfortunately, that if() condition should have checked for the correct length
instead of an error which broke the command in tor-0.2.9.1-alpha.
Fixes #22034
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Fri, 21 Apr 2017 15:09:34 +0000 (11:09 -0400)]
hs: Fix a spurious warn in rend_log_intro_limit
We do dump HS stats now at log info everytime the intro circuit creation retry
period limit has been reached. However, the log was upgraded to warning if we
actually were over the elapsed time (plus an extra slop).
It is actually something that will happen in tor in normal case. For instance,
if the network goes down for 10 minutes then back up again making
have_completed_a_circuit() return false which results in never updating that
retry period marker for a service.
Fixes #22032
Signed-off-by: David Goulet <dgoulet@torproject.org>
Sebastian Hahn [Mon, 17 Apr 2017 08:07:31 +0000 (10:07 +0200)]
Fix diff generation with line added at start
The consdiff generation logic would skip over lines added at the start of the
second file, and generate a diff that it would the immediately refuse because
it couldn't be used to reproduce the second file from the first. Fixes #21996.
David Goulet [Thu, 12 Jan 2017 15:46:15 +0000 (10:46 -0500)]
hs: Make the service list pruning function public
The reason for making the temporary list public is to keep it encapsulated in
the rendservice subsystem so the prop224 code does not have direct access to
it and can only affect it through the rendservice pruning function.
It also has been modified to not take list as arguments but rather use the
global lists (main and temporary ones) because prop224 code will call it to
actually prune the rendservice's lists. The function does the needed rotation
of pointers between those lists and then prune if needed.
In order to make the unit test work and not completely horrible, there is a
"impl_" version of the function that doesn't free memory, it simply moves
pointers around. It is directly used in the unit test and two setter functions
for those lists' pointer have been added only for unit test.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Now we have separate getters and setters for service-side and relay-side. I
took this approach over adding arguments to the already existing methods to
have more explicit type-checking, and also because some functions would grow
too large and dirty.
This commit also fixes every callsite to use the new function names which
modifies the legacy HS (v2) and the prop224 (v3) code.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Tue, 11 Apr 2017 17:46:41 +0000 (13:46 -0400)]
hs: Change trunnel prop224 cell's namespace
One of the goals of this change is to have trunnel API/ABI being more explicit
so we namespace them with "trn_*". Furthermore, we can now create
hs_cells.[ch] without having to confuse it with trunnel which used to be
"hs_cell_*" before that change.
Here are the perl line that were used for this rename:
David Goulet [Wed, 5 Apr 2017 20:47:55 +0000 (16:47 -0400)]
config: Warn if EntryNodes and HiddenService are used together
Pinning EntryNodes along with hidden services can be possibly harmful (for
instance #14917 and #21155) so at the very least warn the operator if this is
the case.
Fixes #21155
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Mon, 10 Apr 2017 16:08:31 +0000 (12:08 -0400)]
Fix some no-longer-reasonable unit tests for base64_decode()
These tests tried to use ridiculously large buffer sizes to check
the sanity-checking in the code; but since the sanity-checking
changed, these need to change too.
Taylor Yu [Fri, 7 Apr 2017 22:06:13 +0000 (18:06 -0400)]
Remove SR_COMMIT_LEN workaround
Now that base64_decode() checks the destination buffer length against
the actual number of bytes as they're produced, shared_random.c no
longer needs the "SR_COMMIT_LEN+2" workaround.
Taylor Yu [Fri, 7 Apr 2017 21:54:50 +0000 (17:54 -0400)]
Remove base64_decode_nopad()
Remove base64_decode_nopad() because it is redundant now that
base64_decode() correctly handles both padded and unpadded base64
encodings with "right-sized" output buffers.
Taylor Yu [Fri, 7 Apr 2017 20:33:22 +0000 (16:33 -0400)]
Test odd-sized base64 decodes
Test base64_decode() with odd sized decoded lengths, including
unpadded encodings and padded encodings with "right-sized" output
buffers. Convert calls to base64_decode_nopad() to base64_decode()
because base64_decode_nopad() is redundant.
Taylor Yu [Fri, 7 Apr 2017 20:01:40 +0000 (16:01 -0400)]
Make base64_decode() check actual decoded length
base64_decode() was applying an overly conservative check on the
output buffer length that could incorrectly produce an error if the
input encoding contained padding or newlines. Fix this by checking
the output buffer length against the actual decoded length produced
during decoding.
Nick Mathewson [Fri, 7 Apr 2017 14:47:16 +0000 (10:47 -0400)]
Never read off the end of a buffer in base32_encode()
When we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358
in 0291 it appears that we introduced a bug: The base32_encode
function can read off the end of the input buffer, if the input
buffer size modulo 5 is not equal to 0 or 3.
This is not completely horrible, for two reasons:
* The extra bits that are read are never actually used: so this
is only a crash when asan is enabled, in the worst case. Not a
data leak.
* The input sizes passed to base32_encode are only ever multiples
of 5. They are all either DIGEST_LEN (20), REND_SERVICE_ID_LEN
(10), sizeof(rand_bytes) in addressmap.c (10), or an input in
crypto.c that is forced to a multiple of 5.
So this bug can't actually trigger in today's Tor.
Nick Mathewson [Fri, 7 Apr 2017 13:51:08 +0000 (09:51 -0400)]
Make the warnings about terminating nuls a bit stronger
It looks like 32_encoded_size/64_encode_size APIs are inconsistent
not only in the number of "d"s they have, but also in whether they
count the terminating NUL. Taylor noted this in 86477f4e3fedb316,
but I think we should note the inconsistently more loudly in order
to avoid trouble.
David Goulet [Tue, 14 Feb 2017 15:45:19 +0000 (10:45 -0500)]
prop224: Flag router with HSIntro/HSDir using protover
Note down in the routerstatus_t of a node if the router supports the HSIntro=4
version for the ed25519 authentication key and HSDir=2 version for the v3
descriptor supports.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Thu, 22 Dec 2016 22:01:07 +0000 (17:01 -0500)]
hs: Move common defines to hs_common.h
Some of those defines will be used by the v3 HS protocol so move them to a
common header out of rendservice.c. This is also ground work for prop224
service implementation.
Signed-off-by: David Goulet <dgoulet@torproject.org>