| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2814276
Change names and comments and docs everywhere.
|
| | |
| |
| |
| |
| | |
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813567
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813565
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Nothing geenrates config updates yet.
|
| | |
| |
| |
| | |
Nothing calls this yet.
|
| | |
| |
| |
| | |
It turns out that we are going to want this.
|
| | |
| |
| |
| |
| | |
We're about to split the main new() function off so write a separate
test for new_disabled().
|
| |/
|
|
| |
chanmgr is going to want to make one of these from a NetDir.
|
| |\
| |
| |
| |
| | |
Use impl_standard_builder more and remove manual Default/builder impls
See merge request tpo/core/arti!594
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Add "full" and "experimental" features to arti, arti-client, and below.
Closes #499
See merge request tpo/core/arti!584
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
The "full" feature is a catch-all for all features, _except_:
* Those that select a particular implementation (like
tor-llcrypto/with-openssl) or build flag (like "static")
* Those that are experimental or unstable (like "experimental-api")
* Those that are testing-only.
|
| |/
|
|
|
| |
There is not, apparently, an eprintln equivalent for
allow-dbg-in-tests.
|
| |\
| |
| |
| |
| | |
Have channel reactor able to send channel padding
See merge request tpo/core/arti!574
|
| | | |
|
| | |
| |
| |
| | |
There aren't very many.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
Plumb a SleepProvider (now Clone + ....) into Channel
See merge request tpo/core/arti!569
|
| | | |
|
| | |
| |
| |
| |
| | |
The channel reactor is going to want to be able to sleep so that it
can do padding, so it needs a SleepProvider.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| | |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
lints: Make lint blocks consistent and ensure they stay that way
Closes #469
See merge request tpo/core/arti!557
|
| | |
| |
| |
| |
| |
| | |
This was the result of:
maint/add_warning crates/*/src/{lib,main}.rs
and then manually curating the results.
|
| |/
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
Utilize cargo-sort: https://github.com/DevinR528/cargo-sort
Signed-off-by: Orhun Parmaksız <[email protected]>
|
| |
|
|
|
|
|
| |
This commit was made by reverting the previous commit, then
re-running the script I used to generate it. In theory there should
be no semantic changes: only changes due to improved formatting from
cargo edit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed the following procedure to make these changes:
* I used maint/changed_crates to find out which crates had changed
since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
topological (dependency) order.
* I looked through semver_status to find which crates were listed as
having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no changes. For those crates, I incremented their patch-level
version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
having breaking changes.
* I identified crates that depend on crates that have changed, even
if they have not changed themselves, and identified them as having
a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
$STATUS` (where `STATUS` is `patch` or `minor`) to update the
versions, and the depended-upon versions.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a general-purpose implementation of the ad-hoc approach
currently taken in (eg) crates/tor-proto/src/channel/reactor.rs,
with an API intended to defned against the more obvious mistakes.
This allows us to separate the two concerns: the channel reactor can
focus on handling channel cells and control messages and is over 2.5x
shorter.
The complexity of the manual sink implementation, and the machinery
needed to avoid having to suspend while holding an item, are dealt
with separately. That separate implemenation now has proper
documentation. (Tests are in the nest commit to avoid this one being
even more unwieldy.)
We use `extend` to define this as an extension trait. A competitor is
`ext` but in my personal projects I have found `extend` slightly
better.
|
| |\
| |
| |
| | |
# Conflicts:
# doc/semver_status.md
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The type of ret.map_err(codec_err_to_chan)? is (). ISTM that
writing `let () = ` makes it clear that there is nothing there,
but the lint forbids this.
This lint is warn by default and trips here for me on current nightly.
It seems wrong to me. We should be able to make it clear to the
reader that there is nothing here - note how this differs from the
lines below where Ready contains msg. A let () binding is a good way
to do that.
I think the lint allow ought to be added everywhere, but that doesn't
seem easy right now - see this issue about maint/add_warning:
https://gitlab.torproject.org/tpo/core/arti/-/issues/469
|
| |/
|
|
|
| |
I need this so that I can expose the skew time for the directory
that a circuit will use, when I only have the circuit.
|
| |
|
|
| |
* Except for safelog and fs-mistrust, which are new.
|
| | |
|
| |
|
|
|
|
|
|
| |
Now that we require Rust 1.56, we can upgrade to AES 0.8. This
forces us to have some slight API changes.
We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has
compatibility issues with Rust 1.56.
|