| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This enables us to get rid of the tor-key-forge -> tor-hscrypto
dependency, partially addressing the TODO from `tor_key_forge::traits`.
This commit is mostly code motion. Best reviewed with `--color-moved`.
See also #1778
|
| |
|
|
|
|
|
| |
We can't possibly know the `ErrorKind` of such an error, unless we know
where the unsupported key came from. Since we can't know this, we should
let a higher level crate (like `tor-keymgr`) decide the `ErrorKind`
instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will enable us to store `tor_cert::EncodedEd25519Cert`s in the
keystore.
|
| | |
|
| | |
|
| |
|
|
| |
This will be used by the `Keystore` implementations.
|
| |
|
|
|
| |
This function now returns a `KeystoreItemType`, enabling us to represent
certs as `EncodableItem`s.
|
| |
|
|
|
| |
This enables us to auto-generate tests for all the supported key/cert
file extensions.
|
| |
|
|
|
| |
Items that have an unrecognized file extension now get mapped to
`KeystoreItemType::Unknown`.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is the first step in replacing `EncodableKey` with the new
`EncodableItem` trait (see doc/dev/keymgr-certificates.md).
(this refactoring is split over multiple commits to make reviewing
easier)
|
| |
|
|
|
|
|
| |
The `EncodableKey` trait will soon be extended to support encoding
certificates too (in addition to keys), so we need a type to represent
an object that is either a key or a certificate (in other words, an
encodable *item*).
|
| | |
|
| | |
|
| |
|
|
|
| |
Soon the keystore will be able to store certs too, so we need something
other than `KeyType` to represent the "type" of a keystore entry.
|
| |
|
|
| |
These are new in Rust 1.83.
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.25.0
done
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cargo set-version -p tor-async-utils 0.24.0
cargo set-version -p tor-basic-utils 0.24.0
cargo set-version -p tor-bytes 0.24.0
cargo set-version -p tor-cell 0.24.0
cargo set-version -p tor-cert 0.24.0
cargo set-version -p tor-chanmgr 0.24.0
cargo set-version -p tor-checkable 0.24.0
cargo set-version -p tor-circmgr 0.24.0
cargo set-version -p tor-config 0.24.0
cargo set-version -p tor-config-path 0.24.0
cargo set-version -p tor-consdiff 0.24.0
cargo set-version -p tor-dirclient 0.24.0
cargo set-version -p tor-dirmgr 0.24.0
cargo set-version -p tor-error 0.24.0
cargo set-version -p tor-general-addr 0.24.0
cargo set-version -p tor-geoip 0.24.0
cargo set-version -p tor-guardmgr 0.24.0
cargo set-version -p tor-hsclient 0.24.0
cargo set-version -p tor-hscrypto 0.24.0
cargo set-version -p tor-hsrproxy 0.24.0
cargo set-version -p tor-hsservice 0.24.0
cargo set-version -p tor-key-forge 0.24.0
cargo set-version -p tor-keymgr 0.24.0
cargo set-version -p tor-linkspec 0.24.0
cargo set-version -p tor-llcrypto 0.24.0
cargo set-version -p tor-log-ratelim 0.24.0
cargo set-version -p tor-memquota 0.24.0
cargo set-version -p tor-netdir 0.24.0
cargo set-version -p tor-netdoc 0.24.0
cargo set-version -p tor-persist 0.24.0
cargo set-version -p tor-proto 0.24.0
cargo set-version -p tor-protover 0.24.0
cargo set-version -p tor-ptmgr 0.24.0
cargo set-version -p tor-relay-crypto 0.24.0
cargo set-version -p tor-relay-selection 0.24.0
cargo set-version -p tor-rpcbase 0.24.0
cargo set-version -p tor-rtcompat 0.24.0
cargo set-version -p tor-rtmock 0.24.0
cargo set-version -p tor-socksproto 0.24.0
cargo set-version -p tor-units 0.24.0
cargo set-version -p arti-client 0.24.0
cargo set-version -p arti-relay 0.24.0
cargo set-version -p arti-rpc-client-core 0.24.0
cargo set-version -p arti-rpcserver 0.24.0
|
| | |
|
| |
|
|
|
| |
`KeypairData` is already in scope, so there's no need to fully-qualify
it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Part of #1476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per our policy, every one of these gets a minor bump.
Generated with:
```
for crate in $(./maint/list_crates | grep '^\(tor\|arti\)-' ); do
cargo set-version --bump minor -p $crate;
done
```
(Note the use of `-` at the end end of the grep pattern to prevent
matching the `arti` crate.)
|
| |\
| |
| |
| |
| | |
Upgrade MSRV to 1.77 , and rusqlite to 0.32.1
See merge request tpo/core/arti!2451
|
| | |
| |
| |
| | |
This will allow us to upgrade to the latest version of rusqlite.
|
| |/
|
|
|
|
| |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| |
|
|
|
|
| |
Closes #1619
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
This re-exports the types/traits needed by the `define_ed25519_keypair`
macro so that the macro caller doesn't need to import a bunch of extra
packages in its Cargo.toml that it doesn't use, and so that the caller
doesn't need a `use prelude::*` before invoking the macro. This makes
the macro nicer to use for the caller, and should prevent the macro from
causing "cannot find ... in this scope" errors.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the signature::Signer and Ed25519PublicKey trait so the
ed25519 keypair wrapper can be easily used for certificate creation.
This also adds a to_ed25519_id() so we can get a Ed25519Identity which
is an object used around.
Finally, add a prelude module as the list of imports started to grow a
bit out of control.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This comment adds a second associated type `KeyPair` to ToEncodableKey. For a
`ToEncodableKey` which represents a (secret) KeyPair, this type is Self. For
a `ToEncodableKey` which represents a public key, this is the `ToEncodableKey`
whose `Key` is the pair of which this is the public part.
This is essentially a "type level pointer" from the ToEncodableKey for a
public key to the ToEncodableKey for its secret key.
|
|
|
Signed-off-by: David Goulet <[email protected]>
|