| Age | Commit message (Collapse) | Author |
|---|
|
(Our link protocol assumes that the link cert certifies the TLS key,
and there is an RSA->Ed25519 crosscert)
|
|
Also, have testing-level options to set the lifetimes and
expiration-tolerances of all key types, plus a non-testing-level
option to set the lifetime of any auto-generated signing key.
|
|
# The first commit's message is:
Regenerate ed25519 keys when they will expire soon.
Also, have testing-level options to set the lifetimes and
expiration-tolerances of all key types, plus a non-testing-level
option to set the lifetime of any auto-generated signing key.
# The 2nd commit message will be skipped:
# fixup! Regenerate ed25519 keys when they will expire soon.
|
|
|
|
This is a new collator type that follows proposal 220 for deciding
which identities to include. The rule is (approximately):
If a <ed,rsa> identity is listed by more than half of authorities,
include it. And include all <rsa> votes about that node as
matching.
Otherwise, if an <*,rsa> or <rsa> identity is listed by more than
half of the authorities, and no <ed,rsa> has been listed, include
it.
|
|
This makes 'routerstatus collation' into a first-class concept, so
we can change how that works for prop220.
|
|
* Include ed25519 identities in votes
* Include "no ed25519 identity" in votes
* Include some commented-out code about identity voting. (This
will disappear.)
* Include some functions for identity voting (These will disappear.)
* Enforce uniqueness in ed25519 keys within a vote
|
|
In particular, they have to list the same ed25519 certificate, and
the SHA256 digest of the ei needs to match.
|
|
Extrainfo documents are now ed-signed just as are router
descriptors, according to proposal 220. This patch also includes
some more tests for successful/failing parsing, and fixes a crash
bug in ed25519 descriptor parsing.
|
|
Also, add a trivial ed25519-signed routerinfo to the tests.
|
|
Unit tests still pass.
|
|
|
|
|
|
An earlier version of these tests was broken; now they're a nicer,
more robust, more black-box set of tests. The key is to have each
test check a handshake message that is wrong in _one_ way.
|
|
This includes the link handshake variations for proposal220.
We'll use this for testing first, and then use it to extend our
current code to support prop220.
|
|
|
|
When there are annotations on a router descriptor, the
ed25519-identity element won't be at position 0 or 1; it will be at
router+1 or router-1.
This patch also adds a missing smartlist function to search a list for
an item with a particular pointer.
|
|
With this patch:
* Authorities load the key-pinning log at startup.
* Authorities open a key-pinning log for writing at startup.
* Authorities reject any router with an ed25519 key where they have
previously seen that ed25519 key with a different RSA key, or vice
versa.
* Authorities warn about, but *do not* reject, RSA-only descriptors
when the RSA key has previously gone along with an Ed25519 key.
(We should make this a 'reject' too, but we can't do that until we're
sure there's no legit reason to downgrade to 0.2.5.)
|
|
This module implements a key-pinning mechanism to ensure that it's
safe to use RSA keys as identitifers even as we migrate to Ed25519
keys. It remembers, for every Ed25519 key we've seen, what the
associated Ed25519 key is. This way, if we see a different Ed25519
key with that RSA key, we'll know that there's a mismatch.
We persist these entries to disk using a simple format, where each
line has a base64-encoded RSA SHA1 hash, then a base64-endoded
Ed25519 key. Empty lines, misformed lines, and lines beginning with
a # are ignored. Lines beginning with @ are reserved for future
extensions.
|
|
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
|
|
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
|
|
Now that we have ed25519 keys, we can sign descriptors with them
and check those signatures as documented in proposal 220.
|
|
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
|
|
|
|
|
|
|
|
|
|
|
|
Report errors if the notification fails; report success only if it
succeeds; and if we are not notifying systemd because we aren't
running with systemd, don't log at notice.
|
|
|
|
|
|
Fixes #15012; bug not in any released Tor
|
|
|
|
|
|
|
|
|
|
Fixes bug 15003; bugfix on 0.2.6.3-alpha.
|
|
We had a regression in 0.2.6.3-alpha when we stopped saying
IPPROTO_TCP to socket(). Fixes bug 14989, bugfix on 0.2.6.3-alpha.
|
|
|
|
|
|
|
|
|
|
Since resolve_my_address() yields IP address in host order there is
no need to use byteorder functions for conversion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
