aboutsummaryrefslogtreecommitdiff
path: root/Cargo.toml
Commit message (Collapse)AuthorAgeFilesLines
* Add new tor-conig-shared crate.Wesley Aptekar-Cassels2026-08-101-0/+1
| | | | | This contains configuration types that are shared between arti and arti-rely.
* Split OTLP exporter into separate crate.Wesley Aptekar-Cassels2026-08-101-0/+1
| | | | | This will allow this code to be shared between arti and arti-relay, and will also likely be useful for others in the ecosystem.
* arti-dirauth: New crate, emptyIan Jackson2026-06-221-0/+1
| | | | Let's start this now.
* tor-dirauth: New crate, emptyIan Jackson2026-06-221-0/+1
|
* Merge branch 'publish' into 'main'Nick Mathewson2026-05-121-0/+1
|\ | | | | | | | | | | | | Add a generic `tor-dirpublish` for documents that have to be uploaded to multiple places Closes #2499 See merge request tpo/core/arti!3924
| * New `tor-dirpublish` crate to handle uploading documents.Nick Mathewson2026-05-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This crate is a generalization of the logic for uploading we currently have in tor-hsservice to handle uploading a (possibly changing) document to a (possibly changing) list of targets. It supports different kinds of documents, different kinds of document targets, and different ways to upload. Currently only direct HTTP uploads are supported; we can add others in the future (and we'll have to, for bridges and onion services.) Closes #2499.
* | Always optimize num-bigint-dig, even in `dev` profiles.Nick Mathewson2026-05-111-0/+10
|/ | | | | | | | The `num-bigint-dig` crate is the backend for rsa 0.9, and without it, key generation is slooooow. Some of our relay test cases now generate RSA keys. Making this change, for me, speeds up our _former_ slowest testcase by a factor of about 20, thereby speeding up our tests overall.
* Introduce maint/dependencies-bodge crateIan Jackson2026-03-311-0/+1
|
* Add a new web-time-compat crate.Nick Mathewson2026-03-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This crate provides a compatibility layer in front of web-time, which will serve three purposes: 1. Saving us from having to build web_time when we don't need it. (This is mainly aesthetic.) 2. Allowing us to continue to use std::time::SystemTime to represent our wall-clock times and dates. This is fairly valuable, since we use a bunch of external crates that expect std::time::SystemTime inputs and don't want a web_time::SystemTime. 3. Add extension methods to web_time::Instant and std::time::Instant so that we can enforce the use of web_time::Instant by disallowing std::time::Instant::now(). (We can't just use the same trick as in (2) to use std::time::Instant everywhere, since there is no way to convert a web_time::Instant to a std::time::Instant.)
* Cargo.toml: Re-order crates so that tor-rtcompat can depend on tor-certNick Mathewson2026-02-021-3/+3
|
* memquota: Extract HasMemoryCost and derive to new crate.Nick Mathewson2026-02-021-0/+1
| | | | This will help resolve some dependencies in our graph.
* cert: Extract x509 code into new tor-cert-x509 crate.Nick Mathewson2026-02-021-0/+1
|
* Add integration test suite for `hsc ctor-migrate` subcommandhjrgrn2026-02-021-0/+1
|
* New futures-copy crate to replace copy_interactive.Nick Mathewson2025-10-281-0/+1
| | | | | | | | | | 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.
* relay: Move crate around Cargo.toml for check_toposortDavid Goulet2025-10-231-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* Merge branch 'note-about-resolver' into 'main'Nick Mathewson2025-09-111-0/+4
|\ | | | | | | | | Add comment about why we need a manual "resolver" entry. See merge request tpo/core/arti!3202
| * Add comment about why we need a manual "resolver" entry.Nick Mathewson2025-09-111-0/+4
| |
* | Move `FallbackDir` into `tor-dircommon`Clara Engler2025-09-111-1/+1
|/
* tor-dirserver: Initial commitClara Engler2025-09-041-0/+1
| | | | | | | | | | | | 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
* tor-dircommon: Initial commitClara Engler2025-09-021-0/+1
| | | | | | | | | | | | | | 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`.
* Merge branch 'newer-resolver' into 'main'Nick Mathewson2025-08-281-1/+1
|\ | | | | | | | | | | | | Use the v3 dependency resolver. Closes #2135 See merge request tpo/core/arti!3183
| * Use the v3 dependency resolver.Nick Mathewson2025-08-261-1/+1
| | | | | | | | | | | | (This is the default for Rust 2024.) Closes #2135.
* | change quicktest build to be based on devJim Newsome2025-08-261-5/+6
|/ | | | | | | | | 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.
* cargo: Make it that tor-keymgr is required for tor-chanmgrDavid Goulet2025-08-201-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* hyper-examples: Rename example directorynield2025-07-201-1/+1
| | | | This directory had to be renamed because otherwise it would cause conflicts with the actual hyper crate in the CI pipeline.
* hyper-examples: Remove subdirectories from examplenield2025-07-201-3/+1
| | | | | This example directory had a separate directory for each example. We can simplify this by using binaries.
* hyper-examples: Example creating custom ArtiHttpConnector for hypernield2025-07-201-0/+1
| | | | | This example demonstrates how to create a custom connector which can be injected into a hyper client, to use hyper for Tor requests.
* Fix topological sort order of Cargo.toml.Nick Mathewson2025-05-071-1/+1
|
* Correct description of lto.Nick Mathewson2025-04-281-1/+1
|
* Change "release" to optimize for peformance.Nick Mathewson2025-04-241-3/+18
| | | | | | | | | | | | (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.
* arti-ureq: New library which integrates with ureqnield2025-04-091-0/+2
| | | | Fixes #1519
* tor-congestion: remove crateSteven Engler2025-03-031-1/+0
|
* Rewrite download manager exampletidely2025-02-041-0/+1
|
* check_toposort: Topologically sort the dependency.Gabriela Moldovan2024-12-111-1/+1
| | | | | Now `tor-hscrypto` depends on `tor-key-forge`, so we need to update their ordering in `Cargo.toml`.
* Cargo.toml: Sort dependencies.Gabriela Moldovan2024-12-041-2/+2
| | | | | `tor-key-forge` now depends on `tor-cert` so we need to reorder the deps in `Cargo.toml` to satisfy `maint/check_toposort`.
* tor-connect-point: new crate to manage RPC connect pointsNick Mathewson2024-11-191-0/+1
| | | | See doc/dev/rpc-book/src/rpc-connect-sketch.md for details.
* cargo: reorder workspace membersSteven Engler2024-11-041-1/+2
|
* Merge branch 'tor-genaddr' into 'main'Nick Mathewson2024-10-291-0/+1
|\ | | | | | | | | Extract general::SocketAddr and its unix friends to their own crate. See merge request tpo/core/arti!2592
| * Extract general::SocketAddr and its unix friends to their own crate.Nick Mathewson2024-10-291-0/+1
| | | | | | | | This is mostly code motion.
* | tor-config-path: added empty packageSteven Engler2024-10-291-0/+1
|/
* tor-hspow: Big refactor, dissolve this crateWesley Aptekar-Cassels2024-10-091-1/+0
| | | | | | | | | | | | | | | | | 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]>
* Bump tor-units up the crate stackIan Jackson2024-10-021-1/+1
| | | | We're going to need this to use tor-memquota.
* add example: axum router as onion servicetidely2024-09-241-1/+2
|
* relay-crypto: Initial import of new tor-relay-crypto crateDavid Goulet2024-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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]>
* Rename tor-keys crate to tor-key-forgeDavid Goulet2024-09-041-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* tor-keymgr: Use tor-keys crate and remove dead codeDavid Goulet2024-09-041-1/+1
| | | | | | | | | | | 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]>
* tor-keys: Automatically implement keymgr traitDavid Goulet2024-09-041-1/+1
| | | | | | | | | | | | | | | | | 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]>
* tor-keys: New crate for Tor key declarationDavid Goulet2024-09-041-0/+1
| | | | | | | | | | 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]>
* Move stream_peek into tor-async-utilsJim Newsome2024-08-291-1/+1
|
* extract tor_async_utils::oneshot into ::oneshot-fused-workaroundJim Newsome2024-08-281-0/+1
| | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 20:06:56 +0000