| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
This is the result of:
```
for crate in $( ./maint/list_crates |grep '^\(tor\|arti-\)' ); do
cargo set-version -p $crate 0.21.0
done
```
|
| | |
|
| |
|
|
|
| |
This warning complains when we say `where T: SomeTrait + ?Sized`
when `SomeTrait` is inherently Sized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug in `ArtiNativeKeystore`'s `Keystore::contains()`
implementation: previously, it called Path::exists() on the relative
path (built by concatenating the key specifier and the extension), so
unless your current directory happened to be the root of the keystore,
`contains()` would always return `false`.
`KeyMgr::generate` uses `Keystore::contains()` under the hood, so it
was affected by this bug too: if called `overwrite = false`, it would
misbehave and overwrite any existing keys.
Internally, we call `KeyMgr::generate` in a couple of places:
* `tor-hsservice/src/lib.rs`, to generate the `hsid` if it doesn't
already exist. This callsite is not affected by the bug, because
`KeyMgr::generate` is only called if `KeyMgr::get` returns `None`
* `tor-hsservice/src/ipt_mgr.rs`, to generate `KS_hss_ntor` and
`KS_hs_ipt_sid` keys for intro point establishment. This callsite is
also not affected (because it too calls `get()` before attempting to
`generate()`)
The bug affects any downstream users that use `KeyMgr::generate`
with a key manager backed by `ArtiNativeKeystore`.
------
`KeyMgr::get_or_generate` is not affected, even though it calls
`Keymgr::generate` (it performs a separate extra check before calling
`generate()`). (Both suffer from a known TOCTOU race, but that's a
separate matter.) As an aside, I'd like to somehow unify
`KeyMgr::get_or_generate` and `KeyMgr::get` (I've had some attempts in
the past but ended up abandoning them because the result was more
unergonomic than the existing APIs).
Part of #1492
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This new assertion fails, because the implementation of
`ArtiNativeKeystore::contains()` is buggy: it calls Path::exists() on
the relative path built by concatenating the key specifier and the
extension (so unless your current directory happens to be the root of
the keystore, contains() is always going to return false).
Part of #1492
|
| | |
|
| |\
| |
| |
| |
| | |
tor-keymgr: Use collect_tuple in TimePeriod::from_slug.
See merge request tpo/core/arti!2248
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The previous approach was buggy: collecting the parts of the time period
into an `ArrayVec` of length 3 would panic if the number of parts was
greater than 3.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This test currently fails because we have a bug in `TimePeriod`'s
`from_slug()` implementation. `TimePeriod::from_slug()` splits the slug
by `_`, and attempts to collect the parts into an `ArrayVec` of length
3. This is wrong, because the `collect()` will panic if there are more
than 3 parts.
|
| |/
|
|
|
| |
This removes the deprecated syntaxes. Updating now will prevent us
re-introducing the old syntaxes, which we updated in arti!2209.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nailing-cargo -uE set-version -p arti-client 0.20.0
nailing-cargo -uE set-version -p arti-relay 0.20.0
nailing-cargo -uE set-version -p arti-rpcserver 0.20.0
nailing-cargo -uE set-version -p tor-async-utils 0.20.0
nailing-cargo -uE set-version -p tor-basic-utils 0.20.0
nailing-cargo -uE set-version -p tor-bytes 0.20.0
nailing-cargo -uE set-version -p tor-cell 0.20.0
nailing-cargo -uE set-version -p tor-cert 0.20.0
nailing-cargo -uE set-version -p tor-chanmgr 0.20.0
nailing-cargo -uE set-version -p tor-checkable 0.20.0
nailing-cargo -uE set-version -p tor-circmgr 0.20.0
nailing-cargo -uE set-version -p tor-config 0.20.0
nailing-cargo -uE set-version -p tor-consdiff 0.20.0
nailing-cargo -uE set-version -p tor-dirclient 0.20.0
nailing-cargo -uE set-version -p tor-dirmgr 0.20.0
nailing-cargo -uE set-version -p tor-error 0.20.0
nailing-cargo -uE set-version -p tor-geoip 0.20.0
nailing-cargo -uE set-version -p tor-guardmgr 0.20.0
nailing-cargo -uE set-version -p tor-hsclient 0.20.0
nailing-cargo -uE set-version -p tor-hscrypto 0.20.0
nailing-cargo -uE set-version -p tor-hsrproxy 0.20.0
nailing-cargo -uE set-version -p tor-hsservice 0.20.0
nailing-cargo -uE set-version -p tor-keymgr 0.20.0
nailing-cargo -uE set-version -p tor-linkspec 0.20.0
nailing-cargo -uE set-version -p tor-llcrypto 0.20.0
nailing-cargo -uE set-version -p tor-log-ratelim 0.20.0
nailing-cargo -uE set-version -p tor-memquota 0.20.0
nailing-cargo -uE set-version -p tor-netdir 0.20.0
nailing-cargo -uE set-version -p tor-netdoc 0.20.0
nailing-cargo -uE set-version -p tor-persist 0.20.0
nailing-cargo -uE set-version -p tor-proto 0.20.0
nailing-cargo -uE set-version -p tor-protover 0.20.0
nailing-cargo -uE set-version -p tor-ptmgr 0.20.0
nailing-cargo -uE set-version -p tor-relay-selection 0.20.0
nailing-cargo -uE set-version -p tor-rpcbase 0.20.0
nailing-cargo -uE set-version -p tor-rtcompat 0.20.0
nailing-cargo -uE set-version -p tor-rtmock 0.20.0
nailing-cargo -uE set-version -p tor-socksproto 0.20.0
nailing-cargo -uE set-version -p tor-units 0.20.0
Each of which runs a rune like
cargo set-version --offline -p tor-units 0.20.0
|
| |
|
|
|
|
|
| |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p itertools
|
| |
|
|
|
|
|
| |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p derive-deftly
|
| |
|
|
|
|
|
|
|
|
|
| |
* Change `pub` to `export`
* Change the `=` in define to `:`
* Change `pub_template_semver_check` to `template_export_semver_check`
Right now, 0.12.1 supports both syntaxes. I have verified this branch
also compiles with
https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/merge_requests/402
ee171ffaf56d7dcb7d75584054921153fe19b222
|
| |
|
|
|
|
| |
* Bump in Cargo.toml
* Deal with `${Xmeta as ...}` incompatible change, by
always specifying an `as`, and changing `as tokens`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The unstable crates are:
- tor-error
- tor-config
- tor-units
- tor-geoip
- tor-rtcompat
- tor-rtmock
- tor-log-ratelim
- tor-rpcbase
- tor-memquota
- tor-llcrypto
- tor-protover
- tor-bytes
- tor-hscrypto
- tor-socksproto
- tor-checkable
- tor-cert
- tor-linkspec
- tor-cell
- tor-proto
- tor-netdoc
- tor-consdiff
- tor-netdir
- tor-relay-selection
- tor-persist
- tor-chanmgr
- tor-ptmgr
- tor-guardmgr
- tor-circmgr
- tor-dirclient
- tor-dirmgr
- tor-keymgr
- tor-hsclient
- tor-hsservice
- tor-hsrproxy
- arti-client
- arti-rpcserver
- arti-hyper
- tor-basic-utils
- tor-async-utils
Done using
```
for p in "${unstable[@]}"; do cargo set-version -p $p 0.19; done
```
where `unstable` contains the list above
|
| |
|
|
|
| |
The keys generated in this commit are reproducible using the
`maint/keygen-openssh-test/generate` script.
|
| |
|
|
|
|
|
| |
This commit contains a new set of `tor-keymgr/testdata` keys,
generated using ./maint/keygen-openssh-test/generate.sh`.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2121#note_3025369
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
`tor-keymgr/testdata` contains a bunch of OpenSSH keys used for testing.
I meant to share the script I generated them with, but somehow never got
around to it.
Note: the OpenSSH keys generated by this script are going to look
slightly different than the ones that are checked into the repo. This is
because some of those original key files were generated ad-hoc (I
manually modified them a while ago, but I forgot exactly how
|
| |
|
|
| |
This is a follow-up from !2131
|
| |\
| |
| |
| |
| |
| |
| | |
tor-keymgr: Refactor code shared between ArtiNativeKeystore and ArtiEphemeralKeystore
Closes #1362 and #1367
See merge request tpo/core/arti!2131
|
| | |
| |
| |
| | |
This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77.
|
| | |
| |
| |
| | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This updates the keymgr tests to be slightly more robust.
These tests attach some metadata to each key, such as the "nickname" of
the key (which only exists for testing purposes), whether the key was
auto-generated, and the keystore ID of the keystore from which the key
was retrieved.
Previously, the metadata was encoded in the key "material" itself (the
test "keys" were actually just `String`s with a hacky `EncodableKey`
implementation that abused the "encrypted" variant of `KeypairData`).
This was only possible because we had access to the key internals
(through `SshKeyData::Public`/`SshKeyData::Private`), but since the
internals are inaccessible now, the tests need to be updated.
|
| | |
| |
| |
| |
| |
| | |
This helps prevent external users from creating `SshKeyData` out of
unsupported types of `ssh_key::public::KeyData` and
`ssh_key::private::KeypairData`.
|
| | |
| |
| |
| | |
KeyData/KeypairData.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As explained in the docs, this trait should not be implementable outside
of the `tor-keymgr` crate. The `SshKeyData::into_erased` and
`UnparsedOpensshKey::parse_ssh_format_erased` impls assume the types
implementing `EncodableKey` form a statically known closed set.
If we later decide to make the supported key types an open set, we
should make this trait implementable outside of `tor-keymgr` too.
External types wanting to create custom "key types" for use in the
keymgr should use the non-sealed `ToEncodableKey` trait, which specifies
the `EncodableKey` type to use.
This trait is mainly used to create `SshKeyData` IMO, we should make
`SshKeyData` opaque, since it's not meant to be constructed through
other means (`SshKeyData` is currently a public enum, so its variants
and the `ssh_key` types they wrap are public). A future commit will make
it opaque.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The `ssh_algorithm()` function was only meant for use in the
ArtiNativeKeystore, for extracting the `KeyType` given the
`SshAlgorithm` of a key read from disk, so it really shouldn't be
crate-public.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some of the types and impls from `key_type/ssh.rs` (such as
`UnparsedOpenSshKey`) have nothing to do with `KeyType`, and are only
used by the `ArtiNativeKeystore`, so I'm moving them to the `arti`
keystore module.
The shared ssh-related stuff now lives in the top-level `ssh.rs`.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Inserting a key that has the wrong key type no longer fails, because we
now store the `KeyData` as-is, without attempting to parse it as a
specific kind of SSH key.
|
| | |
| |
| |
| | |
Closes #1362 #1367
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds an `SshKeyData::into_erased` function that returns the
`SshKeyData` as a type-erased concrete key type (e.g. a type-erased
`ed25519::Keypair`).
This commit duplicates all of the `convert_*` functions from
`key_type/ssh.rs`. A future commit will rewrite the code from
`key_type/ssh.rs` to use `SshKeyData::into_erased`, and to remove the
duplicate functions.
Previously, `EncodableKey` returned an encoded `SshKeyData`, which
doesn't implement `EncodableKey`. This was rather inconvenient for
`Keystore` implementers. For instance, for the in-memory keystore we
ended up working around this limitation by serializing and deserializing
`EncodableKey`s to and from `String`. For the full context,
see https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2076#note_3016460
Needed for #1362 #1367
|
| | | |
|
| | |
| |
| |
| |
| | |
I think it makes more sense for parse_ssh_format_erased to be a function
of the key than of `KeyType`.
|
| | |
| |
| |
| |
| |
| | |
We're about to need it in the `UnparsedOpenSshKey` impl.
This commit is just code motion and has no functional changes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`UnparsedOpenSshKey` was originally only meant to be used for the
`ArtiNativeKeystore`.
I am about to make it private to the arti module, so I'm updating the
ephemeral keystore tests to not use it.
Part of #1362
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
add_warning/CI: New strategy to avoid "unexpected-cfgs" warning
Closes #1395
See merge request tpo/core/arti!2129
|
| | |
| |
| |
| | |
This commit is automatically generated.
|
| | |
| |
| |
| |
| |
| |
| | |
This doesn't need to be public anymore now that the test keys are
exported from `test_utils`.
Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2076#note_3016577
|
| | |
| |
| |
| |
| |
| |
| | |
This is used by `ArtiNativeKeystore` and the `EphemeralKeystore`.
Moving it to test_utils means `EphemeralKeystore` no longer needs to
import test helpers from the arti module.
|