| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1429#note_2924483
|
| |/ /
| |
| |
| |
| |
| | |
Discussions here:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1429#note_2924481
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1429#note_2924495
|
| |\ \
| | |
| | |
| | |
| | | |
Fix typos
See merge request tpo/core/arti!1436
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
fixes deadlock in TorClient::reconfigure
See merge request tpo/core/arti!1432
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | | |
dev notes: Draft IPT algorithm
See merge request tpo/core/arti!1429
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Initial notes about onion service structs and APIs
See merge request tpo/core/arti!1422
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
keymgr-doc: Document the list of keys the keymgr needs to generate.
See merge request tpo/core/arti!1413
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add `doc/safer_build.md` to explain path anonymization
Closes #957
See merge request tpo/core/arti!1435
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise our default build instructions will lead people
to build binaries that include their home directory.
Closes #957 for now.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Run cargo +nightly fmt to format many let ... else ...
See merge request tpo/core/arti!1434
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
rustfmt has grown opinions about how let ... else ... ought to be
formatted. They don't always agree with our previous manual
decisions.
I think our policy is to always insist on rustfmt. When that version
of rustfmt hits stable, our CI will start to fail for everyone.
(Right now this discrepancy just causes trouble for contributors who
are using nightly by default.)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix typos
See merge request tpo/core/arti!1431
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
keymgr: API updates and other improvements
Closes #903
See merge request tpo/core/arti!1421
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Keymgr api updates minor fixes
See merge request gabi-250/arti!1
|
| | | | | | | |
|
| | | | | | | |
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | | |
Address review comments
See merge request gabi-250/arti!5
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
keys from." (fmt)
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
keys from."
This reverts commit 38a6c74c7894dc96b16c9039cacc2a4023977b05.
This also updates some tests to make them compile with the reverted
version of the code.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As with `KeyMgr::insert`, only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We'll need this to implement `Keystore::insert`.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The caller uses `KeystoreSelector` to specify which keystore to insert
the new key into (only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported for `insert`).
The ability to insert keys in a particular keystore will come in handy
when we implement the key management CLI (the CLI will have an option
for specifying the keystore to access/modify).
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This error will be returned by `KeyMgr` if the caller tries to access a
keystore that does not exist, or if the requested `KeystoreSelector`
cannot be applied.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be used by `KeyMgr::insert` after we add an additional
argument to `insert` for specifying the keystore it should be using.
|