| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\
| |
| |
| |
| | |
dev docs: key-management.md updates and clarifications
See merge request tpo/core/arti!1185
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
There are several places where he `KeyType` isn't needed anymore.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dirs.
This also moves the `extension` function out of `KeyType` because for
the C Tor key store, a key's file extension depends on the role/user of
the key, which isn't known by `KeyType` (`KeyType` is a tor-agnostic key
type such as `Ed25519Private`).
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This renames `KeyIdentity` to `KeySpecifier` so it doesn't get confused
with the concept of an "identity key". `HsClientIdentity` is also
renamed for consistency.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
Add a sketch for our FFI/RPC architecture
See merge request tpo/core/arti!1005
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
I think that this might be the way forward, depending on our current
requirements and our users' current needs. I've traced out some
challenges that would imply.
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
We decided against using it.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The key manager needs to be flexible enough to support loading keys from
one of several key stores. This is because when we add support for smart
cards, users will want to be able to store some keys on the smart card,
and others in one of the disk key stores (for example).
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first draft of the key manager API.
I don't expect this to be the final version of the API, and I'm sure
there are plenty of improvements to be made. This is mostly a request
for comments.
Closes #834
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
| |
| |
| | |
Closes #822
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
RPC: Terminology and error-handling conformance
Closes #826 and #825
See merge request tpo/core/arti!1136
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now instead of hoping that buggy clients will detect a magic `id`,
we can simply tell them that they will get no `id` at all. If they
can't handle that case, no major harm is done: the connection will
get closed anyway.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Always "method", never "command".
Always "authentication scheme", never "authentication method".
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Document some properties of semver
See merge request tpo/core/arti!1129
|
| | | |
| | |
| | |
| | |
| | | |
Discussion
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1129#note_2895839
|
| | | |
| | |
| | |
| | |
| | | |
Discussion
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1129#note_2895837
|
| | | |
| | |
| | |
| | |
| | | |
Discussion
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1129#note_2895835
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1129#note_2895834
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
I think we've bedded in the new process.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Update s101 values.
See merge request tpo/core/arti!1128
|
| | |/ / |
|