aboutsummaryrefslogtreecommitdiff
path: root/Cargo.toml
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* Start on a lower-level tor-rpccmd crate.Nick Mathewson2023-04-121-0/+1
| | | | | This crate will hold the backend pieces of RPC interaction that different parts of Arti get to implement.
* rpc: Implement json message types for serde.Nick Mathewson2023-04-121-1/+1
|
* Make a new empty tor-async-utils crate.Nick Mathewson2023-03-291-0/+1
|
* Sketch an API for onion services.Nick Mathewson2023-01-241-0/+1
|
* Add a new stub hsclient module to connect to onion services.Nick Mathewson2023-01-241-0/+1
|
* Fix typosDimitris Apostolou2023-01-071-1/+1
|
* Merge branch 'build_profiles' into 'main'Nick Mathewson2023-01-061-0/+11
|\ | | | | | | | | | | | | Add a new "light" build profile between "dev" and "release". Closes #639 See merge request tpo/core/arti!960
| * Add a new "quicktest" build profile between "dev" and "release".Nick Mathewson2023-01-061-0/+11
| | | | | | | | | | | | | | | | "quicktest" is meant to build faster than our (tuned for size above all) release profile, while having enough optimization to perform reasonably well when used for testing. Closes #639.
* | Create a new tor-hscrypto crate.Nick Mathewson2023-01-061-0/+1
|/ | | | | | This module has types and operations needed in multiple places for an onion service implementation. There are a bunch of TODO hs-crypto comments that we'll need to fill in.
* Add the skeleton of a tor-ptmgr crateNick Mathewson2022-09-231-0/+1
| | | | | When complete, this crate will handle launching and using pluggable transports on demand.
* tor-congestion: implement the RTT estimation algorithm from prop#324eta2022-08-111-0/+1
| | | | | | | | | | | This commit implements the round-trip-time estimation algorithm from Tor proposal 324, validating the implementation against the test vectors found in C tor. (Note that at the time of writing, the new test vectors may not be committed to C tor yet, but they will be soon.) This also adds the necessary consensus parameters to `NetParameters`. Some of them have been renamed in order to (hopefully) make them more understandable.
* Revert toplevel part of "Lexically sort Cargo.toml dependencies"Ian Jackson2022-06-081-26/+26
| | | | This reverts one file from commit bfd41ddb5fefe8808c33669c508dde4325808e35.
* Lexically sort Cargo.toml dependenciesOrhun Parmaksız2022-05-281-26/+26
| | | | | | Utilize cargo-sort: https://github.com/DevinR528/cargo-sort Signed-off-by: Orhun Parmaksız <[email protected]>
* Implement a safe-logging facility.Nick Mathewson2022-05-061-0/+1
| | | | | | This is a rough first-cut of an API that I think might help us with keeping limited categories of sensitive information out of our logs. I'll refine it based on experiences with using it.
* Merge branch 'fs-mistrust-v2' into 'main'Nick Mathewson2022-05-031-0/+1
|\ | | | | | | | | Second cut at a fs-mistrust crate. See merge request tpo/core/arti!468
| * Second cut at a fs-mistrust crate.Nick Mathewson2022-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This crate is meant to solve #315 by giving a way to make sure that a file or directory is only accessible by trusted users. I've tried to explain carefully (in comments and documentation) what this crate is doing and why, under the assumption that it will someday be read by another person like me who does _not_ live and breathe unix file permissions. The crate is still missing some key features, noted in the TODO section. It differs from the first version of the crate by taking a more principled approach to directory checking: it emulates the path lookup process (reading symlinks and all) one path change at a time, thus ensuring that we check every directory which could enable an untrusted user to get to our target file, _or_ which could enable them to get to any symlink that would get them to the target file. The API is also slightly different: It separates the `Mistrust` object (where you configure what you do or do not trust) from the `Verifier` (where you set up a check that you want to perform on a single object). Verifiers are set up to be a bit ephemeral, so that it is hard to accidentally declare that _every_ object is meant to be readable when you only mean that _some_ objects may be readable.
* | Merge branch 'derive-builder-git-fixup' into 'main'eta2022-04-271-8/+0
|\ \ | | | | | | | | | | | | derive_builder: Use git dep everywhere, rather than cargo patch See merge request tpo/core/arti!477
| * | derive_builder: Use git dep everywhere, rather than cargo patchIan Jackson2022-04-271-8/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `[patch]` approach causes the tree not to build when used as a dependency, unless the `[patch]` is replicated into the depending project. Instead, replace our `derive_builer =` dependencies with a reference to a specific git commit: perl -i~ -pe 'next unless m/^derive_builder/; s#"(0\.11\.2)"#{ version = "$1", git = "https://github.com/ijackson/rust-derive-builder", rev = "ba0c1a5311bd9f93ddf5f5b8ec2a5f6f03b22fbe" }#' crates/*/Cargo.toml Note that the commitid has changed. This is because derive_builder is in fact a workspace of 4 crates. 3 of them are of interest to arti itself (the 4th exists only for testing). So the same "add git revision" treatment had to be done to the `derive_builder` and `derive_builder_macro` crates. Each dependency edge involves a new commit in the derive_builder workspace, since we can't create a git commit containing its own commitid. (We want to use commits, rather than a branch, so that what we are depending on is actually properly defined, and not subject to the whims of my personal github namespace.) There are no actual code changes in derive_builder.
* / Fix grammar and typosSamanta Navarro2022-04-271-2/+2
|/
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 17:05:45 +0000