summaryrefslogtreecommitdiff
path: root/Cargo.toml
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Add comments explaining purpose of check_toposortJim Newsome2024-08-271-0/+3
|
* Cargo.toml: Sort crate list.Gabriela Moldovan2024-08-211-1/+1
| | | | This is needed to satisfy `maint/check_toposort`.
* New `slotmap-careful` crate to use when we mustn't re-use keys.Nick Mathewson2024-08-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* WIP: Lower and middle levels of Arti rpc core.Nick Mathewson2024-07-161-0/+2
|
* Remove arti-hyperIan Jackson2024-06-251-1/+0
| | | | | | This has been obsolete for a very long time. We have already published a version with a "won't be updated" warning.
* Stop building examples/gsoc2023/download-managerIan Jackson2024-06-251-1/+0
|
* relay: Add relay cargo feature flag and subcommandDavid Goulet2024-06-111-0/+1
| | | | | | | | | | 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]>
* tor-keymgr: Move keygen script to maint.Gabriela Moldovan2024-05-151-1/+1
|
* tor-keymgr: Make keygen crate part of the workspace.Gabriela Moldovan2024-05-151-0/+1
|
* Rename tor-memtrack to tor-memquotaIan Jackson2024-04-291-1/+1
|
* tor-memtrack: Introduce new crate (empty)Ian Jackson2024-04-231-0/+1
| | | | | | | Put it just above tor-rpcbase, which maybe it would want to use for metrics export via RPC? For now we have some dead code `#[allow]`s.
* Create a new empty tor-relay-selection crate.Nick Mathewson2024-03-121-0/+1
|
* fslock-guard: Add unit testsTobias Stoeckmann2024-03-011-1/+1
| | | | | This requires reordering of workspace members due to new internal dev-dependency.
* maint/fixup-features: Make part of the main workspaceIan Jackson2024-02-071-0/+2
| | | | | This ties it into everything, so we run CI on it, have it in our main lockfile, and so on.
* test-temp-dir: New crateIan Jackson2024-01-251-0/+1
| | | | | Introduce the crate, move the code motion, and make minimal necessary changes.
* fslock-guard: sketch implementationNick Mathewson2024-01-211-0/+1
| | | | | | | This is not yet "correct", since it will rely on https://github.com/brunoczim/fslock/pull/15 (Conceivably, it might be better to make the `fslock` crate rm-safe.)
* Examples using hyper v1ramidzkh2024-01-111-0/+2
|
* New tor-log-ratelim crateNick Mathewson2023-11-161-0/+1
| | | | | | | | | This crate is meant to provide rate-limited log messages to tell users about problems that can happen too frequently to log individually. This version is based off an earlier design, and off of conversations with @diziet. It still needs tests.
* Merge branch 'hss_config' into 'main'Nick Mathewson2023-09-071-0/+1
|\ | | | | | | | | Begin working on configuration logic for onion services See merge request tpo/core/arti!1557
| * Create a tor-hsrproxy crate to handle "proxy to local port".Nick Mathewson2023-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | I'm calling this a "reverse proxy" since I think a lot of folks like that terminology, though I'm not personally a huge fan. Calling it "`tor-hsproxy`" would IMO confuse people more about what kind of proxy it was. This is a separate crate from `tor-hsservice` because it's logically at a different level: if you're writing a little embedded onion service, you don't need this code. Right now there is only configuration logic here.
* | Move examples to examples/gsoc2023Nick Mathewson2023-09-051-5/+5
| |
* | fix: add examples to main Cargo.tomlSaksham Mittal2023-09-051-0/+6
|/
* Include debug symbols in "bench" profileMicah Elizabeth Scott2023-07-271-0/+6
| | | | | Including full debug symbols makes the benchmark builds useful for profiling too.
* Start implementing Proposal 327Micah Elizabeth Scott2023-07-271-0/+1
| | | | | | | | | | | | | This adds a new tor-hspow crate with the first layers of support in place for onion service client puzzles as described in Proposal 327. The API here is experimental, and it's currently only implementing the self-contained parts of the client puzzle. So, it can verify and solve puzzles, but it has no event loop integration or nonce replay tracking or prioritization code yet. These things seem like they would eventually live in the same crate. Signed-off-by: Micah Elizabeth Scott <[email protected]>
* Reimplement Equi-X in RustMicah Elizabeth Scott2023-07-271-0/+1
| | | | | | | | | | | This is a new pure Rust implementation of the Equi-X algorithm designed by tevador for Tor's onion service proof of work puzzle v1. Equi-X is an asymmetric puzzle algorithm based on Equihash, with N=60, K=3, the XOR replaced with modular addition, a 16-bit index space, and HashX as the inner hash function. Signed-off-by: Micah Elizabeth Scott <[email protected]>
* Reimplement HashX in RustMicah Elizabeth Scott2023-07-271-0/+1
| | | | | | | | | | | | | | | | | This is a new pure Rust implementation of the HashX algorithm designed by tevador for Tor's onion service proof of work puzzle v1. HashX is a lightweight family of randomly generated hash functions. A seed, via blake2 and siphash, drives a program generation model which randomly selects opcodes and registers while following some constraints that avoid timing stalls or insufficient hash mixing. The execution of these hash funcions can be done using a pure Rust interpreter, or about 20x faster using a very simple just in time compiler based on the dynasm assembler crate. This has been implemented for x86_64 and aarch64. Signed-off-by: Micah Elizabeth Scott <[email protected]>
* Merge branch 'add-tor-geoip' into 'main'Nick Mathewson2023-06-201-0/+1
|\ | | | | | | | | tor-geoip: Add new crate with GeoIP database functionality See merge request tpo/core/arti!1239
| * tor-geoip: Add new crate with GeoIP database functionalityeta2023-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - This adds a new crate, `tor-geoip`, which can parse and perform lookups in the GeoIP database C-tor already uses (generated by a maintenance utility in the C-tor codebase). - We embed a copy of C-tor's databases with the crate and use `include_str!` to ship them with the binary, bloating its size somewhat. - This does, however, solve the problem of figuring out how to distribute these. - The plan is to gate this functionality behind a feature flag anyway, so the cost should be nil unless explicitly opted into. Part of tpo/core/onionmasq#47.
* | keymgr: Move the HS client and service key specifiers out of tor-keymgr.Gabriela Moldovan2023-06-151-1/+1
| | | | | | | | | | | | The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to `tor-hsclient`. The HS service secret key specifier stubs are moved to `tor-hsservice`.
* | keymgr: Add ArtiNativeKeyStore implementation skeleton.Gabriela Moldovan2023-06-151-0/+1
|/ | | | | This adds implementation stubs for `ArtiNativeKeyStore`, and introduces the traits needed to make the `KeyStore` APIs work.
* Rename tor-rpccmd to tor-rpcbase.Nick Mathewson2023-04-121-1/+1
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 19:42:57 +0000