aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | | rng ranges: Provide examples (doctests)Ian Jackson2023-07-101-0/+42
| | | | |
* | | | | rng ranges: Forbid use of panicky Rng::gen_rangeIan Jackson2023-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | Fixes #920
* | | | | rng ranges: Use gen_range_infallible() for Duration::ZERO..=TIan Jackson2023-07-105-7/+9
| | | | |
* | | | | rng ranges: Introduce gen_range_infallibleIan Jackson2023-07-101-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a number of places where we generate random Durations in a range which starts at zero. These call sites currently (i) have to write out Duration::ZERO or equivalent, and (ii) would have to use gen_range_checked and expect the result, even though it can be statically proven to be OK. To make this slightly smoother, provide `GenRangeInfallible` and `gen_range_infallible`.
* | | | | rng ranges: Use gen_range_checked().unwrap() in test caseIan Jackson2023-07-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ideally we would be allowed to use vanilla gen_range() here, but there doesn't seem to be a way to allow a specific clippy-forbidden method using #[allow] and we probably don't want to make a blanket allow.
* | | | | rng ranges: Use gen_range_checked().expect() in obvious cases (fmt)Ian Jackson2023-07-102-3/+5
| | | | |
* | | | | rng ranges: Use gen_range_checked().expect() in obvious casesIan Jackson2023-07-103-5/+9
| | | | | | | | | | | | | | | | | | | | In each of these, it is locally obvious that the range is nonempty.
* | | | | tor-basic-utils: retry: Use and justify gen_range_checkedIan Jackson2023-07-101-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | delay_bounds's implementation ensures the postcondition, so the potential p[anic in next_delay_msec cannot happen.
* | | | | rng ranges: Introduce RngExt and gen_range_checkedIan Jackson2023-07-101-0/+27
| | | | | | | | | | | | | | | | | | | | We will use this in many places instead of gen_range.
* | | | | Merge branch 'keymgr-erased-key' into 'main'gabi-2502023-07-105-10/+22
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | keymgr: Use Box<dyn EncodableKey> instead of Box<dyn Any>. Closes #937 See merge request tpo/core/arti!1398
| * | | | | keymgr: Add semver.md.Gabriela Moldovan2023-07-101-0/+2
| | | | | |
| * | | | | keymgr: Use Box<dyn EncodableKey> instead of Box<dyn Any>.Gabriela Moldovan2023-07-104-10/+20
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701 This will make it harder to accidentally return the wrong value from `Keystore::get` (the returned value is now at least guaranteed to implement `EncodableKey`). Closes #937
* | | | | Merge branch 'conversation' into 'main'Alexander Færøy2023-07-106-132/+233
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Overhaul send_control_message See merge request tpo/core/arti!1367
| * | | | | tor-proto: run rustfmtIan Jackson2023-06-304-9/+21
| | | | | |
| * | | | | tor-proto conversations: semverIan Jackson2023-06-301-0/+1
| | | | | |
| * | | | | tor-proto conversations: Update a TODOIan Jackson2023-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The feature name is wrong now.
| * | | | | tor-proto conversations: Drop a TODOIan Jackson2023-06-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | I think this name is fine.
| * | | | | tor-proto conversation API: Provide ConversationInHandlerIan Jackson2023-06-304-7/+61
| | | | | |
| * | | | | tor-proto circuit: Plumb async Context throughIan Jackson2023-06-302-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | handle_msg is going to want this in a moment.
| * | | | | tor-proto conversation API: Soften a warningIan Jackson2023-06-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the circuit is just being used by us (which is likely, if we're using this API) then the only reactor we're blocking is our own.
| * | | | | tor-proto conversation API: Implement ConversationIan Jackson2023-06-301-89/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now, after you call start_conversation_last_hop, you can send more messages if you like.
| * | | | | tor-proto: Make the handler in SendMsgAndInstallHandler optionalIan Jackson2023-06-302-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to want to do almost-the-same thing but without installing a new handler.
| * | | | | tor-proto conversation API: Return a ConversationIan Jackson2023-06-303-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just a placeholder for now, but it'll be a thing you can send more messages with.
| * | | | | tor-proto conversation API: Rename to start_conversation_last_hopIan Jackson2023-06-304-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | Was send_control_message.
| * | | | | tor-proto conversation API: Make starting message optionalIan Jackson2023-06-303-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to let people start a conversation and either expect to receive first, or send messages ad-hoc later.
| * | | | | tor-proto conversation API: Rename to ConversationFinishedIan Jackson2023-06-302-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Was UninstallHandler. We are going to talk more about conversations and less about handlers (although, the fact of there being a handler will still be visible).
| * | | | | tor-proto circuit: Make reactor::run_once modulae-privateIan Jackson2023-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Nothing else wants this and having it pub(super) is confusing.
* | | | | | Merge branch 'recurse' into 'main'Alexander Færøy2023-07-101-26/+37
|\| | | | | | |/ / / / |/| | | | | | | | | | | | | | tor-hsclient: Mock traits: Work around an async boobytrap See merge request tpo/core/arti!1365
| * | | | tor-hsclient: Mock traits: Work around an async boobytrapIan Jackson2023-06-301-26/+37
| | | | |
* | | | | Merge branch 'clippy-vec' into 'main'Nick Mathewson2023-07-102-3/+3
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Fix new "useless_vec" warning from clippy +nightly See merge request tpo/core/arti!1395
| * | | | | Fix new "useless_vec" warning from clippy +nightlyIan Jackson2023-07-102-3/+3
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explanation at https://rust-lang.github.io/rust-clippy/master/index.html#/useless_vec This is the non-tests subset of the same-named commmit in !1388, (recreated by hand by me, and then checked against that commit; I stole the commit message from Nick's.) This should be uncontroversial I think.
* | | | | Remove some needless into_iter() calls.Nick Mathewson2023-07-102-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clippy nightly now detects when you're calling into_iter() and passing the result into something that accepts an `impl IntoIterator`.
* | | | | Add exceptions for some cases of diverging_sub_expressionNick Mathewson2023-07-104-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See here for documentation on the lint: https://rust-lang.github.io/rust-clippy/master/index.html#/diverging_sub_expression The issue here, from what I can tell, is that the lint triggers whenever you use a diverging expression as a function body within an
* | | | | Add an exception for clippy::arc_with_non_send_sync.Nick Mathewson2023-07-101-0/+1
|/ / / / | | | | | | | | | | | | We're doing this deliberately, I believe.
* | | | Merge branch 'da-task' into 'main'gabi-2502023-07-105-72/+73
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | RFC: tor-rtmock: Use derive-adhoc for composite runtimes See merge request tpo/core/arti!1381
| * | | | tor-rtmock: Use derive-adhoc for composite runtimesIan Jackson2023-07-075-72/+73
| | | | |
* | | | | Update documentation regarding the `onion-service-client` featureKunal Mehta2023-07-072-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | It is no longer experimental, but still not rated for security-sensitive usage per <https://blog.torproject.org/arti_116_released/>.
* | | | | Fix warn_report and error_report macros.Nick Mathewson2023-07-071-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally they didn't check err.kind(), since err.kind() can never increase their severity. We lost that behavior with !1386, and we became dependent on it with arti!1383. Since they both merged at the same time, CI broke. This patch restores their original behavior.
* | | | | Merge branch 'feat' into 'main'Nick Mathewson2023-07-071-1/+10
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arti: Build with HS client support by default Closes #948 See merge request tpo/core/arti!1382
| * | | | | arti: Build with HS client support by defaultIan Jackson2023-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fixes #948
| * | | | | arti Cargo.tomL: wrap default features listIan Jackson2023-07-071-1/+9
| |/ / / /
* | | | | Merge branch 'event_report_everywhere' into 'main'Nick Mathewson2023-07-0726-116/+98
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Throughout: Use event_report!() macros for reporting Errors. Closes #949 See merge request tpo/core/arti!1383
| * | | | | Throughout: Use *_report!() macros for reporting Errors.Nick Mathewson2023-07-0726-116/+98
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I identified the cases to replace by searching for the string `.report()`. There are a few that I didn't change: * A couple of cases that used anyhow::Error, * One case that reported two Errors. * Two cases in `tor_hsclient::err` that just did `error!("Bug: {}")`. I have also not audited the cases in `tor-hsclient` where we're using `tor_error::Report` manually. Nonetheless, closes #949.
* | | | | be more lenient while parsing inner hs desctrinity-1686a2023-07-071-1/+6
| | | | |
* | | | | Merge branch 'report' into 'main'Ian Jackson2023-07-072-92/+55
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | tor-error: tracing module: Use macro to generate macros See merge request tpo/core/arti!1386
| * | | | | tor-error: tracing module: Use macro to generate macrosIan Jackson2023-07-072-91/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This abolishes some quintuplication. The output is identical except that: * The syntax display in the rustdoc output for the resulting macros seems to have somewhat less whitepsace. * The whimsical error messages in the examples are all identical. Ah well.
| * | | | | tor-error: tracing module: Fix link to tracing macroIan Jackson2023-07-071-1/+1
| |/ / / /
* | | | | Merge branch 'inclusive' into 'main'Nick Mathewson2023-07-074-4/+4
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | rng ranges: Use inclusive Duration ranges in several places See merge request tpo/core/arti!1385
| * | | | rng ranges: Use inclusive Duration ranges in several placesIan Jackson2023-07-074-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many of these call sites would panic if, somehow, the upper bound was zero. In most cases it is very complicated to see if whether this could happen. However, there is a better answer: Durations are (conceptually) dense, so picking the closed set (which includes its boundary) rather than the open one (which doesn't) will make little practical difference. So change four call sites to use `..=` instead of just `..`.
* | | | | Merge branch 'report-bugs-v2' into 'main'Nick Mathewson2023-07-079-44/+229
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | Optional tracing support in tor-error for error reporting See merge request tpo/core/arti!1379