| Commit message (Collapse) | Author | Age |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
It was unclear whether this was βthe epoch at <time>β or
β(X seconds after the epoch) at <time>β.
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes #20481
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
Given the concerns raised in #21059, it seems like the previous wording
was more appropriate (the final behavior remains the same).
This reverts commit 1d00cabe00000eaab515a0ee54a4ecd3e4fcb651.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Authorities still need to generate consensus with a specific order to
maintain consensus consistency, but clients don't need to. Resolves
ticket #21059.
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Defining useful glossary terms
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes #19133
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| |\ \ \ \ |
|
| | | |/ /
| |/| |
| | | |
| | | | |
Fixes #18146.
|
| |\ \ \ \
| |_|/ /
|/| | | |
|
| | |/ /
| | |
| | |
| | | |
Fixes #20014.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Apart from the indentation, the "download/" key for the GETINFO command is
wrong, it's actually "downloads/" so fixing that.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Oops! Thought I pushed this along with the other changes. Multiple new
descriptor fields were added in the wrong order. Reordering them to match what
actually appears in the consensus and votes...
https://trac.torproject.org/projects/tor/ticket/21059
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We had this as a 'MUST' because the directory authorities need to agree upon an
ordering in their votes to derive at a signed consensus. However, this
requirement is turning out to be very error prone...
https://trac.torproject.org/projects/tor/ticket/21059
Got the ordering issues sorted out... I think. However, this has bitten us
three times in a row and clearly will bite us more in the future so loosening
these requirements a little.
|
| |/ /
| |
| |
| |
| |
| | |
Spec doesn't match tor with regard to the ordering of this field either. It was
added way back in 2013 but for Stem's checks I coded against tor's actual
behavior rather than the spec. Hence why it went under the radar.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
(unless i'm wrong and this is a different sebastian)
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
asn spotted this during code review.
|
| | | |
| | |
| | |
| | | |
Specified fix for #20920
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | |/ /
| | |
| | |
| | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Authorized clients need a x25519 key to decrypt the descriptor anyway,
so having username/password method for the intro-layer authorization is
not very helpful, since they will need to remember the x25519 key anyway.
Perhaps in the future we can reinstate the username/password method, by
having x25519/ed25519 keypairs be generated from the low-entropy
username/password pair.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the past prop224 used to embed the client authorization key in the
subcredential. The problem here is that if we wanted to revoke a client,
we would have to change the whole subcredential of the service, which
means that we would have to announce it to all clients.
This patch makes it so that every client has an x25519 and an ed25519
which are used to perform client authorization.
To achieve this on the descriptor level, we change the descriptor format
to a double-layer encryption where the first layer protects against
entities who don't know the public key of the HS, and the second layer
protects against unauthorized clients who don't know the x25519 key.
The intro level authorization remains as is and uses ed25519 for authentication.
Thanks to special for noticing this issue.
Thanks to Nick for sketching out the x25519 descriptor auth scheme.
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| |/ /
| |
| |
| | |
(Spotted by Roger)
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Neat! Turns out tor supports this, just wasn't documented...
https://trac.torproject.org/projects/tor/ticket/20501#comment:5
|