| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
All of this is now documented in the lib.rs.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This sentence is very important piece of overall explanation, but
didn't make it into the crate level docs.
|
| | | | |
| | | |
| | | |
| | | | |
All of this is now implemented. Delete the obsolete sketch.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-keymgr: add disk-related docs to `ArtiEphemeralKeystore`
See merge request tpo/core/arti!2424
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Bump MSRV from 1.70 to 1.75.
See merge request tpo/core/arti!2421
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
arti: Add subcommand for generating service identity keys
Closes #1621
See merge request tpo/core/arti!2419
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `hss get-key` functionality was folded into `hss onion-name`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `hss get-key` subcommand is now folded into `onion-name`, which
takes a `--generate` argument which specifies whether to generate the
key if missing.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2419#note_3078068
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This adds a new `hss get-key` subcommand for retrieving and generating
service identity keys. The existing `hss onion-name` is now a
convenience alias for `hss get-key --generate=no --key-type=onion-name`.
Note: I am calling this new subcommand `get-key` for consistency with
its client counterpart (`hsc get-key`).
Closes #1621
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is needed because we'll soon add an `hss get-key` subcommand for
getting and/or generating a service identity key alongside `hss
onion-name` (`hss onion-name` will become a convenience around `hss
get-key --key-type=onion-name`).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This splits `onion_name` into multiple functions (which will be
repurposed for the future `hss get-key` implementation).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`hss` will soon sprout another subcommand, so I am preemptively
refactoring the `hss onion-name` implementation out of `hss::run()`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The tests were added in !2275
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This also reexports `HsId` from the `tor-hsservice` crate.
|
| | | | | | | |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We will soon add a new `OnionService` function for generating an HsId
for the service without launching it (#1621).
This new API will be implemented using `maybe_generate_hsid`, which will
need to take the user-provided keystore selector as an argument.
(the selector exists for future-proofing reasons; we're not yet exposing
it in the CLI, but it will be part of the new `OnionService` API)
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Update s101 numbers for Q2 2024
See merge request tpo/core/arti!2245
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Bug 1612: Allow programmatic launching of onion-service with user-provided HsIdKeypair
Closes #1612
See merge request tpo/core/arti!2402
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
HsIdKeypair
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
tor-hsservice: Do not generate the HsId until the service is launched.
See merge request tpo/core/arti!2417
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This defers generating an HsId until `OnionService::launch`, enabling us
to use APIs like `OnionService::onion_name` to e.g. check for the
existence of an HsId (previously, you couldn't do that because creating
an `OnionService` would auto-generate the `HsId`).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per #1247, we decided to stick with the current name.
As for the docs, they were added in !1946
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
This has been deprecated since 1.2.6, so let's remove it.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Implement and user Reader::take_all_but()
Closes #1620
See merge request tpo/core/arti!2415
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
rpc: Simplify handling of fatal Json read errors.
Closes #1591
See merge request tpo/core/arti!2400
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
(This will make the next commit easier to read.)
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Per suggestion from @diziet.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Instead of classifying errors and complicating our behavior _early_
in our loop, instead we just decide whether an error indicates an
EOF immediately before we return it.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Make it more clear than the previous match statement
that once we get an Err() from request_stream.next(),
we aren't going to continue the loop.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, after determining that an error on an RPC connection
was fatal, we would:
1. Determine whether it was a "clean" close or one
that needed to be logged.
2. In exactly one case (specifically, when the inbound Json stream
contained a Value that was not an Object) , we would send back a
message to the client.
3. Exit the connection with Ok() or Err(e).
We no longer do step "2" above.
Additionally, we document:
- Why it's important to exit immediately on syntax errors.
- A better way to tolerate non-Object Json Values,
if we decide someday to do so.
Closes #1591.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
tor-circmgr: Remove AbstractSpec and FakeSpec.
See merge request tpo/core/arti!2412
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This tests that when requesting preemptive circuits, they are not given
out when a insufficient number of circuits are in the CircList, but that
they are given out once the required number of circuits has been
reached.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
AbstractSpec and FakeSpec actually make testing more difficult, since
they prevent using FakeBuilder in code that relies on the concrete
TargetCircUsage and SupportedCircUsage types. Removing them means
FakeBuilder can be used in more places, and also means that the test
code is closer to the real code, since TargetCircUsage and
SupportedCircUsage are now exercised directly in more tests.
This did require making one change to a test, which I think was
previously testing behaviour that was true for FakeSpec but not for the
real code:
The mgr::test::isolated test previously asserted that, in the case where
three circuits were requested, two with isolation and one without, the
non-isolated circuit would be shared with one of the isolated circuits.
This was allowed by the FakeSpec::supports function. However, in the
actual code, the path is as follows:
* AbstractCircMgr::get_or_launch
* AbstractCircMgr::prepare_action
* CircList::find_open
* AbstractSpec::find_supported
* abstract_spec_find_supported
* OpenEntry::supports
* SupportedCircUsage::supports
* StreamIsolation::compatible_same_type
StreamIsolation::compatible_same_type checks owner_type, which is
always zero for non-isolated streams and always non-zero for isolated
streams, meaning that a isolated stream will never be compatible with a
non-isolated stream. The seems like desirable behaviour, so I simply
modified the test to make four connections, two isolated and two not,
and checked that the isolated streams never share any circuits, and that
the two non-isolated streams use the same circuit. As far as I can tell,
this is the intended behaviour in the existing code.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
arti: Move proxy subcommand to a separate module.
See merge request tpo/core/arti!2416
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
No functional changes, this is just code motion.
This helps organize the code in `arti/src/lib.rs` a bit. It now only
contains the argument parsing and various other setup, and all the
subcommands are contained in separate modules.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
No functional changes, this is just code motion.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
The implementation for `arti proxy` will soon be relocated to this new
module.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-chanmgr: add experimental `ChanMgr::handle_incoming`
See merge request tpo/core/arti!2389
|