summaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge branch 'nonblocking-rpc-part3' into 'main'Nick Mathewson2026-03-057-213/+1007
|\ \ | | | | | | | | | | | | rpc: API for event-driven IO. See merge request tpo/core/arti!3652
| * | rpc: edit and revise EventLoop documentation.Nick Mathewson2026-03-051-7/+8
| | |
| * | rpc: Transpose Results in RpcPoll::poll.Nick Mathewson2026-03-051-7/+5
| | |
| * | rpc: document when try_as_{fd,socket} can fail.Nick Mathewson2026-03-051-1/+11
| | |
| * | rpc: Usage documentation for polling APIIan Jackson2026-03-053-22/+168
| | |
| * | rpc: Propose to transpose a Result<Result<>>Ian Jackson2026-03-051-0/+2
| | |
| * | rpc: Add a question in the form of a TODOIan Jackson2026-03-051-0/+2
| | |
| * | rpc: Fix many long lines in docs and commentsIan Jackson2026-03-054-22/+44
| | |
| * | rpc: Fix two mis-formatted json! blocksIan Jackson2026-03-051-2/+13
| | | | | | | | | | | | | | | | | | rustfmt doesn't like to touch things inside macros. These were misformatted as a result, with long lines and in one case a missing space.
| * | rpc: Remove WantIo and expose wants_to_write().Nick Mathewson2026-03-053-43/+21
| | |
| * | rpc: Change Waker implementation to EventLoop.Nick Mathewson2026-03-056-112/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per discussion, it makes more sense to have the API be one that gets called when our IO interests change. Additionally, this commit removes the try_reading and try_writing booleans, as previously discussed. I've left a couple of XXXX comments where more documentation or thought is likely needed.
| * | rpc: API for event-driven IO.Nick Mathewson2026-03-055-21/+245
| | | | | | | | | | | | | | | | | | | | | This API provides the necessary functionality to use an RpcConn inside a poll-like event loop. This is part of #1856.
| * | RPC: Explain why UserTag is a separate type.Nick Mathewson2026-03-051-0/+8
| | |
| * | RPC: Raname Tag,RequestTag to UserTag.Nick Mathewson2026-03-053-37/+33
| | |
| * | rpc: documentation fixes and clarificationsNick Mathewson2026-02-261-3/+8
| | | | | | | | | (from Diziet)
| * | rpc: Add a paragraph to the connimpl overviewNick Mathewson2026-02-261-0/+3
| | |
| * | rpc: Add overview documentation to connimpl.Nick Mathewson2026-02-261-0/+64
| | | | | | | | | | | | This is based on a pad with input from nickm and Diziet
| * | rpc: Nonblocking request submit API (Rust only)Nick Mathewson2026-02-262-5/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit finally adds a `RpcConn::submit()` method to send a request without having to wait on it specifically, and an `RpcConn::wait()` method to wait for the next response from _any_ such request. Thanks to the previous patches, this is relatively simple! This is part of #1856.
| * | rpc: Backend support for pollable requests.Nick Mathewson2026-02-263-7/+92
| | | | | | | | | | | | | | | | | | In order to implement tagged pollable requests, we need a separate response queue for them, and we need to dispatch requests to that queue as appropriate.
| * | rpc: Add "Tag"s to response queues.Nick Mathewson2026-02-261-25/+49
| | | | | | | | | | | | | | | | | | | | | For pollable requests, we'll want to associate each one with a tag. But we'd rather not carry tags around for _every_ pending request: it would waste space and lead to possible errors. So instead we add a Tag type as a member of QueueId.
| * | rpc: Refactor connimpl in preparation for pollable requests.Nick Mathewson2026-02-263-59/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to implement this part of #1856, we will internally divide requests into two kinds: "Waitable" and "Pollable". Waitable requests are the kind that we have now: They are created with an "execute" method. They each have their own response queue and their own condvar, and in order to see if they have any responses, the caller needs to call some kind of request-specific method. Pollable requests are the ones we will add. They are created with a "submit" method, and associated with a user-provided tag. They all share the same queue and the same condvar. To see if any of them have a response, the caller will run a function that returns tagged responses. In order to support this division, this commit: - turns `RequestState` into an enum, - makes `ResponseQueue` into its own type, - Adds a trait that will be implemented by every type that can identify a response queue.
* | | Merge branch 'upgrade-polyval' into 'main'Nick Mathewson2026-03-052-3/+10
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | proto: Upgrade to latest polyval. Closes #2390 See merge request tpo/core/arti!3747
| * | proto: Upgrade to latest polyval.Nick Mathewson2026-03-042-3/+10
| | | | | | | | | | | | | | | | | | This will improve performance for CGO. Closes #2390.
* | | Merge branch 'signature-rework-rename-signed' into 'main'Clara Engler2026-03-0514-156/+101
|\ \ \ | | | | | | | | | | | | | | | | tor-netdoc parse2: Rename *Signed to *Unverified See merge request tpo/core/arti!3742
| * | | tor-netdoc: Fix typo in docsIan Jackson2026-03-041-1/+1
| | | |
| * | | tor-netdoc: Apply rustfmt churnIan Jackson2026-03-033-11/+5
| | | |
| * | | tor-netdoc: parse2: Lengthen a doc comment slightlyIan Jackson2026-03-031-1/+1
| | | |
| * | | tor-netdoc: parse2: Use eprint for dtraceIan Jackson2026-03-032-5/+8
| | | |
| * | | tor-netdoc: Rename *Signed to *UnverifiedIan Jackson2026-03-0313-60/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was a weird name, and while working in this area it all seemed to make the docs strange. Rename it. This is quite invasive! In theory we could have the macros generate compatibility aliases, but that seems quite complex.
| * | | tor-netdoc: Move NetdocSigned to signatures.rsIan Jackson2026-03-034-34/+36
| | | | | | | | | | | | | | | | | | | | I keep not finding it because all the other signatures stuff is in signatures.rs.
| * | | tor-netdoc: Drop dir_auth_key_cert_signatures test caseIan Jackson2026-03-031-56/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test case constructs a "netdoc" which consists of one dir-key-certification item, and parses it using `AuthCertSignatures as NetdocParseable`. But we're going to split out the parsing trait for signatures sections, so that's not going to work any more. This test tests only corner cases of the derived SignatureItemParseable implementation; but that's unit tested in the parse2 tests. (Once upon a time there was perhaps manual parsing code which needed a specific test.) Remove it.
* | | | Merge branch 'cell-order' into 'main'opara2026-03-047-80/+89
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | Improve error messages during channel handshake See merge request tpo/core/arti!3745
| * | | | tor-cell: rename `RestrictedMsg::restricted_cmds()` to `cmds_for_logging()`Steven Engler2026-03-043-4/+4
| | | | |
| * | | | tor-proto: small code cleanupSteven Engler2026-03-032-18/+6
| | | | |
| * | | | tor-proto: improve error messages using `RestrictedMsg`Steven Engler2026-03-032-35/+17
| | | | |
| * | | | tor-cell: add `RestrictedMsg` traitSteven Engler2026-03-031-0/+35
| | | | |
| * | | | tor-proto: improve error messages during handshakeSteven Engler2026-03-032-5/+7
| | | | |
| * | | | tor-basic-utils: clean up `iter_join`Steven Engler2026-03-031-8/+6
| | | | |
| * | | | tor-basic-utils: move `iter_join` from arti-relaySteven Engler2026-03-034-33/+37
| | | | | | | | | | | | | | | | | | | | Will clean this up in the following commit.
* | | | | Merge branch 'dirclient-empty-successful' into 'main'Clara Engler2026-03-045-6/+39
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | tor-dirclient: Disallow empty successful responses See merge request tpo/core/arti!3650
| * | | | | tor-dirclient: Add semver.mdClara Engler2026-03-041-0/+1
| | | | | |
| * | | | | Rename DirResponse::from_body to from_get_bodyClara Engler2026-03-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reflects that it is expected for an HTTP GET body. It is okay because it is only used in tor-dirmgr, which only performs GET request anyways.
| * | | | | tor-dirclient: Only fail on empty GET responsesClara Engler2026-03-043-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes the previous check to only fail on empty GET responses. For this, it introduces a `method` field into `DirResponse`, which is required to determine the method there. Doing this is reasonable for an HTTP client, as responses have different meanings depending on the request method used.
| * | | | | tor-dirclient: Disallow empty successful responsesClara Engler2026-03-042-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit disallows empty responses with a status code 200. From a pure HTTP level, this is totally valid, but it does not make any sense in the context of the Tor directory protocol, where an empty response only makes sense with a 404. The motivation for this is that a work-in-progress tor_dirclient::send_request wrapper for tor-dirserver passes the response into the parse2 multiple function which returns a Vec<T>. Interfacing code would then always have to check for an empty length and do respective error handling, which should already fail at an earlier level (tor-dirclient) instead.
* | | | | | deps: use the same `rusqlite` version range for all cratesHydroxideUnlaced2026-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Ian Jackson <[email protected]>
* | | | | | Apply 1 suggestion(s) to 1 file(s)HydroxideUnlaced2026-03-041-0/+1
| | | | | | | | | | | | | | | | | | Co-authored-by: Ian Jackson <[email protected]>
* | | | | | deps: relax `libsqlite3-sys` version requirementHydroxideUnlaced2026-03-042-3/+8
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue concerns `libsqlite3-sys` linking to a native library. Cargo cannot handle multiple versions/crates linking to the same native library. This affects both the `tor-dirmgr` and `tor-dirserver` crates, which depend on `rusqlite`. Relaxing the version requirement gives downstream projects flexibility so cargo can select an appropriate `libsqlite3-sys` version without a high chance of conflicts caused by pinning a specific version. The proposed supported version range was determined by testing until encountering a version lacking a feature currently in use (breaking unchange?). Regarding testing, the current CI with minimum-version test only validates the maximum and minimum versions, so breaking changes introduced between them can pass unnoticed. Tools like [Cargo-Bounds](https://github.com/vivax3794/cargo_bounds) can help, but this is out of scope for this MR. Also, supported versions of `rusqlite` for `tor-dirmgr` and `tor-dirserver` differ, so running tests for the whole project (same workspace) causes cargo to pick only overlapping versions, which hides parts of each crate’s supported range. Referencing #754, after this MR, increasing the maximum version or decreasing the minimum version of `rusqlite` shouldn't be a breaking change, but increasing the minimum version could be. Resolves: #1740
* | | / / arti-client: Remove "not as secure as C Tor" text in the README.Nick Mathewson2026-03-041-4/+1
| |_|/ / |/| | | | | | | | | | | | | | | I think we currently have the same security features implemented in Arti as C tor has.
* | | | Bump strum to 0.28Gabriela Moldovan2026-03-0414-14/+14
| | | |
* | | | rtcompat: Bump async-native-tls to 0.6.0Gabriela Moldovan2026-03-041-1/+1
| | | |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 17:44:59 +0000