mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.7 2024-08-28T13:00:31Z 2024-08-28T13:00:31Z Nick Mathewson nickm@torproject.org 2024-08-27T17:16:15Z urn:sha1:ebbece794a2b11ff8d90af61be56a460d74255cd (This is a bit trickier than I would like, but it ensures that we never return a "not initialized yet" code.) 2024-08-28T13:00:31Z Nick Mathewson nickm@torproject.org 2024-08-22T14:38:33Z urn:sha1:5a79d84df763867ac5f22a81ddbc594ca0b7b939 We'll need this for our rpc-library code to meaningfully open SOCKS connections. Closes #1523. 2024-08-28T13:00:31Z Nick Mathewson nickm@torproject.org 2024-08-22T12:46:32Z urn:sha1:657aa2e4d5dff83fadedec7a0be0e5413a27d8f3 This type exists in the `arti` crate. It wraps and delegates to `arti_rpcserver::RpcSession`. Subsequent commits will use it to expose information from the `arti` crate to the RPC system; right now it does nothing. 2024-08-05T16:41:15Z Gabriela Moldovan gabi@torproject.org 2024-07-24T14:42:52Z urn:sha1:db1aaef64cdcf7e6d3a6aff3a3a8aa6f21a07296 We can just used `build_for_arti()` here. 2024-07-30T14:20:41Z Gabriela Moldovan gabi@torproject.org 2024-07-30T14:19:10Z urn:sha1:454fc1c34507eefa11343e521a33d44e4ac5d679 2024-07-10T14:25:30Z Gabriela Moldovan gabi@torproject.org 2024-07-10T14:25:30Z urn:sha1:1a212998ca5b3e418640471721c5dd3ad78ad49c 2024-07-10T14:25:00Z Gabriela Moldovan gabi@torproject.org 2024-07-10T13:57:02Z urn:sha1:4314bd456e34c4396302e22c83e095d3c048c176 The `arti hsc` subcommand can't run without keymgr support. Previously, it relied on `tor-keymgr/keymgr` being enabled indirectly by its dependencies, via the `experimental` feature. We need to be able to enable this feature in `arti` without relying on `experimental` (because `arti hsc` will eventually be made non-experimental). Part of #1487 2024-06-27T17:13:52Z Gabriela Moldovan gabi@torproject.org 2024-06-17T16:45:10Z urn:sha1:8fc4c063d7076a6e9ffe36f2ee5bf39394fa3113 This adds an experimental `arti hsc` subcommand for managing client state and keys. Currently, it only supports the `prepare-service-discovery-keys` operation described in #1281 and `doc/dev/notes/client-auth.md`. A note on terminology: I am referring to services that encrypt the second layer of their descriptor as running in "restricted discovery" mode (because they can only be discovered, i.e. have their IPT points found out, by a set of authorized clients). The corresponding client "auth" keys, being the keys that enable the client to find out the list of intro points, pow-params etc. of the service, are referred to as service "discovery keys". Alternative names I considered: * extra descriptor encryption: accurate, but overly technical. IMO, the CLI should be accessible to users who aren't familiar with the nitty-gritty of the protocol * shielded mode: good, but slightly misleading. Calling it "shielded mode" makes it sound like a universally desirable "extra protection" that should almost always be enabled (which is not the case). Seeing `shielded_mode = off` in the config might be worry operators that don't fully understand what "extra descriptor encryption" or "shielded mode" means * restricted mode: slightly inaccurate. It implies this mechanism is a good substitute for conventional service-side authentication, which it isn't (because client authorization isn't instantaneous) Closes #1281 2024-06-24T12:41:09Z Nick Mathewson nickm@torproject.org 2024-06-11T15:04:35Z urn:sha1:a3ce2f027cd99bccff0245c4e7ba2662c9dd59a8 2024-06-17T18:15:04Z Gabriela Moldovan gabi@torproject.org 2024-06-17T18:04:35Z urn:sha1:99607b9c8a81ddfff66ba3b97102be6b9df2a000 I propose we move each subcommand implementation to a `subcommand` submodule.