| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
| |
Formerly we required the caller for push_cert_body to specify the
type of the cert that they were pushing. But in nearly every case,
the certificate object that the caller is holding knows what its
own type is! This makes the tor_proto build_certs_cell function
a bit less error-prone, since we don't have to worry about mismatch.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We documented our SystemTime-to-expiry conversion as always rounding
_up_, but we did not account for fractional seconds when doing so.
Therefore, if the requested expiration was set partway through the
first second of an hour, the conversion would round down.
This patch fixes that, and adds a regression test. I've confirmed
that the test fails without this patch.
Closes #2407
|
| |
|
|
|
|
|
| |
These certificates use a weird expiration format: counting hours
since the unix epoch. Previously we had it implemented in two
different places. This patch centralizes it, since we are about to
become slightly more complicated.
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| | |
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
| |
Closes #2197.
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
|
|
|
|
|
| |
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
|
| | |
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This commit makes a trait function use another currently unused trait
function, thereby increasing the test coverage, as well as being
potentially more correct from a semantic point of view.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| |
|
|
|
|
|
| |
I am not sure why we wrote these comments, but they are incorrect:
I've investigated the C code and found only 3 key types. The
"unimplemented" types that the TODO comment here complains about are
in fact certificate types.
|
| | |
|
| |
|
|
| |
Closes #759
|
| |
|
|
|
|
|
| |
These should have a cleaner API than check_key, and be easier to
understand.
Part of #759
|
| | |
|
| |\
| |
| |
| |
| | |
Apply restricted_msg to ChanMsg parts of tor-proto
See merge request tpo/core/arti!1013
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Actually, to avoid making a breaking change, I'm deprecating
BadMessage and creating a new InvalidMessage variant that takes a
Cow. This way I don't need to track every crate that re-exposes
tor_bytes::Error and call this a breaking change in those.
Making this change will allow tor_bytes errors to be much more
helpful.
|
| |/
|
|
|
|
|
|
|
| |
Generated with perl:
s/K([PS])_hs_intro_tid/K$1_hs_ipt_sid/g;
s/K([PS])_onion_ntor/K$1_ntor/g;
s/K([PS])_hs_intro_ntor/K$1_hss_ntor/g;
s/K([PS])_hs_desc_ephem/K$1_hss_desc_enc/g;
|
| |
|
|
|
| |
Also, explain why a few of these certificates aren't actually useful
as certificates. (This issue is also documented in torspec!110)
|
| |
|
|
|
| |
This allows us to run `is_valid_at` and friends on the certificate
itself, which we will use soon in hsdesc validity checks.
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| | |
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| | |
|
| |
|
|
|
|
|
| |
Apparently cargo fmt doesn't like these, which my perl rune didn't
delete.
This commit is precisely the result of `cargo fmt`.
|
| |
|
|
|
|
|
|
| |
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
|
| | |
|
| |
|
|
| |
and propagate to other affected crates
|
| | |
|
| |
|
|
| |
This lets us remove a few TODOs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is behind a feature flag, since it isn't needed for pure
clients: only onion services and relays need this.
I've named the object that constructs these certs
`Ed25519CertConstructor` because it doesn't follow the builder
pattern exactly: mainly because you can't get an Ed25519Cert out of
it. _That_ part is necessary because we require that an Ed25519Cert
should only exist if the certificate was found to be well-signed
with the right public key.
Closes #511.
|
| |\
| |
| |
| |
| | |
Fix clippy nightly again
See merge request tpo/core/arti!603
|
| | |
| |
| |
| | |
Update all lint blocks
|
| |/
|
|
|
|
|
|
|
| |
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
|