| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
* Remove instructions to sleep
* Explain how to tag
* Remind myself about the workaround for
Fedora's delightful gpg/yubikey configuration.
* Note that we should update "pages" till the blog post is up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I've split this into
"what I do in the days leading up to the release" and
"what I do right before the release".
There's a lot more detail now, including:
* up-to-date invocations for `cargo upgrade`
* up-to-date changelog instructions
* our current version-bumping instructions
* possible side-effects from version bumps.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Remove references to a couple of things
that our CI now does for us
(`cargo_audit` and `check_licenses`).
* Mention ~Blocker issues and MRs.
* Mention that some of our CI steps are allowed-to-fail,
but failures should be examined.
* Mention that some of our tools have exception lists
that should get reviewed.
* Mention `semver-checks` and `fixup-features`.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
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
|