| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
|
|
|
| |
This adds PowManager, as described in doc/dev/notes/service-side-pow.md,
hooks it into IptManager and Publisher, and adds code to publish and
rotate seeds, and to keep a updated list of Verifier instances for
currently active seeds.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
These are now unused.
Part of #1166
|
| |
|
|
|
|
|
|
|
|
|
|
| |
#1155 was happening because we couldn't compute the offset of the
current time from the start of the _next_ TP
(`TimePeriod::offset_within_period` expected `when` to come after the
start of the TP). `TimePeriod::offset_within_period` now returns an
offset of 0 for timestamps that come before the start of the TP, to
support computing revision counters for the descriptors uploaded to
the HsDirs from the ring associated with the next TP.
Fixes #1155
|
| |
|
|
|
|
|
|
|
|
|
| |
periods.
Hidden services can have multiple "active" time periods for which they
generate descriptors. We need to be able to compute the offset of a
timestamp from the start of a given time period, even if that timestamp
falls within the "next" time period (for example, when publishing
descriptors for the "previous" time period, the `when` timestamp will
fall outside the `(start, end)` range of the "previous" time period).
|
| |
|
|
|
|
| |
This is the approach from appendix F.2 in rend-spec.
Part of #1053.
|
| | |
|
| |
|
|
|
|
| |
This renaming aims to make it clearer that this offset is _not_ the time
between start of the epoch and the start of this time period, but rather
the delta between our epoch and the Unix epoch, in seconds.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* Return a more informative error type (instead of Option)
* Check that time periods are an integer number of seconds
* Decide not to change the semantics of an argument.
|
| |
|
|
|
| |
We updated and clarified the spec in arti!107, and noted the
remaining infelicities in proposal 342.
|
| |
|
|
|
|
| |
Locally, the only functional effect is that now we refuse to handle
non-whole-number-of-minutes lengths - but since the consensus
parameter can't represent those, there's no overall functional change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This logic is a bit tricky, so I've tried to document it and add
fairly good tests. The silver lining is that the external API for
all of this logic will make it invisible and hidden.
There are some cases where I added functions that I think might
eventually get lowered into MdConsensus: But I don't want to lower
too much right now, since the convention for our netdoc accessors is
that they are fairly unsophisticated, and they show you the document
as it is.
Closes #686
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Previously, the offset was set to 12 hours unconditionally (like the
spec says). But based on a conversation on tor-dev, it seems that
the offset should actually be 12 times the voting interval.
I'm also opening an MR to change the spec.
|
| |
|
|
|
|
| |
(I have squashed the fixes for these warnings into the earlier
commits in this branch, so it will look like I did everything right
the first time.)
|
| |
|
|
|
| |
This implementation was made based on the specification, and then
validated against itself, and against C Tor.
|
| |
|
|
|
| |
This required some API tweaks, which is probably to be expected;
these time periods are a wonky kind of thing.
|
| |
|
|
|
| |
The important addition here is the Copy derives, which affect API
design. I'm applying them to the types that are 32 byte or smaller.
|
|
|
This module has types and operations needed in multiple places
for an onion service implementation. There are a bunch of
TODO hs-crypto comments that we'll need to fill in.
|
