| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
This will help resolve some dependencies in our graph.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This crate's API is loosely based on some of tokio's functions,
and its implementation strategy is loosely based on
futures::io::copy.
It's designed to be generally useful outside of the arti ecosystem.
Should help with the original challenge of #786.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| | |
Add comment about why we need a manual "resolver" entry.
See merge request tpo/core/arti!3202
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit lays the initial groundwork for the `tor-dirserver` crate,
a crate that shall implement functionality for dirmirros and dirauths.
For now, the current crate consists of three bare bone modules:
* lib.rs
* err.rs
* mirror.rs
All of which contain mostly boilerplate code for now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit initializes the `tor-dircommon` crate: A crate serving the
purpose to form an umbrella for the lowest common denominator primitives
found across crates implementing (parts of) the directory specification.
For now, the only such primitive is the found within the `authority`
module, which has been refactored from `tor-dirmgr` into this crate,
alongside additional getter functions due to the lack of `pub(crate)` in
this context.
In the future, we may move further primitives away from `tor-dirmgr`
into `tor-dircommon`.
|
| |\
| |
| |
| |
| |
| |
| | |
Use the v3 dependency resolver.
Closes #2135
See merge request tpo/core/arti!3183
|
| | |
| |
| |
| |
| |
| | |
(This is the default for Rust 2024.)
Closes #2135.
|
| |/
|
|
|
|
|
|
|
| |
Make it "dev with a bit more optimization" instead of "release with a
bit less optimization". The biggest change here is to keep dev-related
behavior changes such as debug assertions. It also means less
optimization, which means faster build time but slower runtime
performance. The runtime performance should still be adequate for
testing purposes.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This directory had to be renamed because otherwise it would cause conflicts with the actual hyper crate in the CI pipeline.
|
| |
|
|
|
| |
This example directory had a separate directory for each example. We can
simplify this by using binaries.
|
| |
|
|
|
| |
This example demonstrates how to create a custom connector which can be injected
into a hyper client, to use hyper for Tor requests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(Previously, it was optimized for size, leading to problems like
\#1336.)
For any purposes that need the old optimize-for-size behavior,
I've added a new "release-small" target. I've also moved the
"strip=debuginfo" behavior from maint/binary_size to this new target,
since cargo started supporting "strip" in 1.59.
Closes #1954.
|
| |
|
|
| |
Fixes #1519
|
| | |
|
| | |
|
| |
|
|
|
| |
Now `tor-hscrypto` depends on `tor-key-forge`, so we need to update
their ordering in `Cargo.toml`.
|
| |
|
|
|
| |
`tor-key-forge` now depends on `tor-cert` so we need to reorder the deps
in `Cargo.toml` to satisfy `maint/check_toposort`.
|
| |
|
|
| |
See doc/dev/rpc-book/src/rpc-connect-sketch.md for details.
|
| | |
|
| |\
| |
| |
| |
| | |
Extract general::SocketAddr and its unix friends to their own crate.
See merge request tpo/core/arti!2592
|
| | |
| |
| |
| | |
This is mostly code motion.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My previous strategy here was to try and centralize hspow in one crate,
writing it like a self-contained feature. That introduced friction in
the data types, prompting the use of simplistic types at the netdoc/cell
layers and full-featured types in the optional modules.
This changes tactics, dissolving the low-level parts of tor-hspow into
tor-hscrypto and the high-level parts into hsclient/hsservice. Full
featured types are used everywhere now, but the tradeoff is that
compile-time configurability is a lot more pervasive. Anything that
knows about PoW types at all needs to be fully configured out. I took
this opportunity to try a more complete set of crate features, allowing
users to configure individual PoW schemes.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
| |
We're going to need this to use tor-memquota.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new crate called tor-relay-crypto which is responsible for
declaring the relay keys and certificate that will be used by a relay
and stored in a KeyMgr.
This is in its own crate and considered pretty low level so other crates
can use it to access the relay keys, like tor-proto, for cryptographic
actions like channel authentication or descriptor signing.
The lower level cryptographic keys are wrapped in a higher level object
in this crate, using tor-key-forge crate, so we can have proper semantic
and strong type check on those keys so they are not misused or confused
with other keys.
At this point, the key declaration might change once the KeyMgr supports
attaching a certificate to a key. We are likely going to see more code
related to certificate creation in this crate in the future.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Everything copied in the previous commits to tor-keys is now removed and
tor-keys crate is used accross the code.
Minor changes to tor-keys to accomodate this change.
Part of #1137
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The derive ed25519 keypair macro now implements the keymgr trait so the
key wrapper can now be used with a keystore without needing to specify
it in the tor-keymgr crate.
For this to work, a slight change to the KeygenRng trait was needed as
in to expect the CryptoRngCore trait which is what ed25519-dalek
requires.
And also, the removal of the Sealed trait since now it is accepted to
implement these traits outside tor-keymgr.
Fixes #1137
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
At this commit, we also add a derive-deftly macro for ed25519 keypair
along a helper macro that can define a wrapper around a lower-level
ed25519::Keypair.
Part of #1137
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| |
|
|
| |
This is needed to satisfy `maint/check_toposort`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This crate works as a drop-in replacement for
the generational arena types
`slotmap::{SlotMap, DenseSlotMap, HopSlotMap}`,
and is implemented a set of wrappers around those types.
The wrappers guarantee that slot versions numbers can never wrap
around by marking as unusable any slot whose version number
would otherwise get too high. (We add some leeway between our max
allowed version number and the largest possible version number,
so that we can detect bugs.)
The code relies on the serde encoding of slotmap key versions.
For notes on stability and (surprisingly good) performance,
see the comments.
Test coverage is around 98% for the lib.rs file; it's lower in
key_data.rs, since the error cases are unreachable given
slotmap's current behavior.
Open questions:
* What further testing is a good idea?
* Will slotmap ever upstream something like this?
See "# Limitations" comment for the parts of slotmap that are not
implemented; I hope that we don't need them.
|
| | |
|
| |
|
|
|
|
| |
This has been obsolete for a very long time.
We have already published a version with a "won't be updated" warning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Add the optional non default feature flag "relay" that will be used to
enable relay support of arti.
This commit also adds the "relay" subcommand to arti binary conditionnal
on the feature flag in order to have a place holder starting point.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|