The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-20T11:07:07Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/894tor-keymgr: CLI for generating HS client keys2024-02-20T11:07:07Zgabi-250tor-keymgr: CLI for generating HS client keysArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/tor/-/issues/40803Cannot write to ClientOnionAuthDir when Sandbox is enabled2023-06-05T16:46:55ZanonymCannot write to ClientOnionAuthDir when Sandbox is enabled### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps ...### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps to reproduce:
1. Configure `tor` with `Sandbox 1`
2. Configure `tor` with `ClientOnionAuthDir /some/writable/directory`
3. Use Tor Browser to access an onion service with onion authentication
4. Check the "Remember this key" checkbox when providing the key
### What is the current bug behavior?
The onion auth prompt in Tor Browser reports "Unable to store creds for ...", and no key is written to the `ClientOnionAuthDir` directory.
### What is the expected behavior?
No errors, and the key should be written to the `ClientOnionAuthDir` directory.
### Environment
- Tor version 0.4.7.13
- Tested both on Debian Sid and inside Tails with `tor` installed via `apt`
### Relevant logs and/or screenshots
```
Jun 02 13:04:02.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp (on Tor 0.4.7.13 )
Jun 02 13:00:25.000 [warn] Couldn't open "/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp" (/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private) for writing: Operation not permitted
Jun 02 13:00:25.000 [warn] Failed to write client auth creds file for n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd!
```
### Possible fixes
Update the sandbox rules.Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/core/arti/-/issues/869rpc: Add a general-purpose "destroy" method2023-11-15T18:58:35ZNick Mathewsonrpc: Add a general-purpose "destroy" methodThis comes out of discussion on !1200.
It would be neat to have a general purpose "destroy or shutdown this object" method that multiple objects can receive.
Note that this might require some changes in our method implementation design...This comes out of discussion on !1200.
It would be neat to have a general purpose "destroy or shutdown this object" method that multiple objects can receive.
Note that this might require some changes in our method implementation design, so that it can release _one_ strong ID, but leave the others pointing to a shut-down object. This would require that the method implementation receive the specific object ID that it was sent to (rather than `Arc<Object>`),Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/868rpc: Settle on strong/weak ID semantics and their implications for capability...2024-02-24T18:30:20ZNick Mathewsonrpc: Settle on strong/weak ID semantics and their implications for capability designThis stems from a discussion in !1200.
We can't define a sensible "drop" method for a weak ID, because the weak IDs for an object are automatically deduplicated. Thus, if you remove a weak ID for a given circuit, you're actually removi...This stems from a discussion in !1200.
We can't define a sensible "drop" method for a weak ID, because the weak IDs for an object are automatically deduplicated. Thus, if you remove a weak ID for a given circuit, you're actually removing _every_ weak ID for that circuit.
@diziet has additional thoughts about the situation at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1200#note_2905558 .
Here are some alternatives; there may be more.
* **There are no weak IDs.** (This would make some programs hard to write without making sure that the API user manually drops everything, and would make some APIs hard to provide. Probably not a good idea)
* **Weak IDs do not get deduplicated.** (This would probably lead to OOM conditions if an API user does something that gets it a zillion weak IDs for the same object.)
* **You can't drop weak IDs.** (This is the status quo, but it means that any capability represented by a weak ID is undroppable, unless you can trust yourself to "forget" the ID.)
* **Dropping a weak ID drops _every_ weak ID for the same object.** (This leads to nonlocal behavior issues, since IDs can get invalidated by parts of the API user that don't even have the ID.)
* **As above, but this is a different operation from the regular "drop".** (This mitigates the nonlocality problem a little by making it hard to do by accident, but it does make weak-ID-dropping a risky proposition.)
* **Weak IDs are not capabilities.** (This is potentially hard to design. If we assume "every ID is a capability", then writing a secure API is as simple as "don't give out an ID to something the user shouldn't have access to" and "Don't access anything without an ID." But if we say only strong IDs are a capability, it's not clear what weak IDs can even allow you to do; it seems like we might need additional access control in the objects that do have the strong IDs.)
* **Weak IDs exist within named tables.** (@diziet suggested this in the above-linked comment.)
* **Weak IDs are namespaced relative to strong IDs.** (This may be the same as @diziet's design above. It would imply that every weak ID is somehow seen as a facet of something that you have a strong ID for, such that dropping the strong ID will expire all the weak IDs.)Arti: RPC SupportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/860Write a CLI for generating keys and certificates2024-01-09T17:24:18Zgabi-250Write a CLI for generating keys and certificatesThe CLI will generate keys in the format used by `ArtiNativeKeyStore`.
We might also want:
* the ability to generate keys in `CTorKeyStore` format
* the ability to convert keys in `CTorKeyStore` format to `ArtiNativeKeyStore` format (an...The CLI will generate keys in the format used by `ArtiNativeKeyStore`.
We might also want:
* the ability to generate keys in `CTorKeyStore` format
* the ability to convert keys in `CTorKeyStore` format to `ArtiNativeKeyStore` format (and vice-versa, maybe)Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/858Implement CTorClientKeyStore and CTorServiceKeyStore2024-01-09T17:24:01Zgabi-250Implement CTorClientKeyStore and CTorServiceKeyStore~Implement the `CTorKeyStore` described in [key-management.md](https://gitlab.torproject.org/tpo/core/arti/-/blob/17ff3a6f6a08fe33df1f3fe1630444dfcc976f3a/doc/dev/notes/key-management.md).~
We're likely going to need [multiple types](ht...~Implement the `CTorKeyStore` described in [key-management.md](https://gitlab.torproject.org/tpo/core/arti/-/blob/17ff3a6f6a08fe33df1f3fe1630444dfcc976f3a/doc/dev/notes/key-management.md).~
We're likely going to need [multiple types](https://gitlab.torproject.org/tpo/core/arti/-/issues/853#note_2903655) of "C Tor key store" rather than a single `CTorKeyStore`:
* `CTorClientKeyStore`
* `CTorServiceKeyStore`
* `CTorRelayKeyStore`
* `CTorDirAuthKeyStore`Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/849RPC: Finalize naming for "Handle", "Reference", "ObjectId", etc.2024-02-20T19:44:41ZNick MathewsonRPC: Finalize naming for "Handle", "Reference", "ObjectId", etc.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1160#note_2899769
We should (to the extent possible) get our naming right, and try to have it match in the code and in the spec.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1160#note_2899769
We should (to the extent possible) get our naming right, and try to have it match in the code and in the spec.Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/842RPC: Enforce that updates, success-responses, and request arguments are all j...2024-02-20T19:26:44ZNick MathewsonRPC: Enforce that updates, success-responses, and request arguments are all json ObjectsI have a WIP in a local `rpc-maponly` branch. Making this issue so I don't forget about it.I have a WIP in a local `rpc-maponly` branch. Making this issue so I don't forget about it.Arti: RPC SupportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/42Don't log to logcat, or otherwise redact logs, in production builds2023-05-13T17:45:35ZetaDon't log to logcat, or otherwise redact logs, in production buildsOur logcat logs (from Rust and Java) contain a significant amount of information about what hosts the user is connecting to, etc. This is fine and useful for development, but we should take care to sanitize this before production; otherw...Our logcat logs (from Rust and Java) contain a significant amount of information about what hosts the user is connecting to, etc. This is fine and useful for development, but we should take care to sanitize this before production; otherwise, this is a massive information disclosure problem waiting to happen!
see also https://developer.android.com/topic/security/risks/log-info-disclosureOnionmasq 1.0.0: Initial releaseetaetahttps://gitlab.torproject.org/tpo/core/arti/-/issues/827RPC: Get AF_UNIX terminology right2023-12-12T16:07:20ZNick MathewsonRPC: Get AF_UNIX terminology rightAt and around https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894536 @Diziet asks for correct vocabularity wrt AF_UNIX sockets. This would indeed be a good thing; @Diziet knows how it should go.At and around https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894536 @Diziet asks for correct vocabularity wrt AF_UNIX sockets. This would indeed be a good thing; @Diziet knows how it should go.Arti: RPC SupportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/823RPC: Make sure methods can't accidentally have wrong types of names2024-02-24T18:31:04ZNick MathewsonRPC: Make sure methods can't accidentally have wrong types of namesWe want all of our method names to be `arti:snake_case`, but we need some way to enforce that.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894524We want all of our method names to be `arti:snake_case`, but we need some way to enforce that.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894524Arti: RPC SupportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/818RPC: Decide on exact cancellation semantics, adjust mutexes accordingly2024-02-21T14:50:13ZNick MathewsonRPC: Decide on exact cancellation semantics, adjust mutexes accordinglySee discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894407 :
We need to decide whether it's okay if a call to `cancel()` returns before the request is cancelled (or not).See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894407 :
We need to decide whether it's okay if a call to `cancel()` returns before the request is cancelled (or not).Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/816arti config variable connect_to_onion_services is not ever built, nor honoured2023-06-29T15:09:39ZIan Jacksoniwj@torproject.orgarti config variable connect_to_onion_services is not ever built, nor honouredThe `#[cfg]` is wrong, so this is never compiled it. Also, nothing reads it.
See also !1113 where we're adding a setter for it. I think ideally that setter ought to be available even in non-HS builds. I feel there's some risk of rein...The `#[cfg]` is wrong, so this is never compiled it. Also, nothing reads it.
See also !1113 where we're adding a setter for it. I think ideally that setter ought to be available even in non-HS builds. I feel there's some risk of reintroducing the "we ignore this config setting" bug, eg by mixing up feature names, but I'm not sure how to avoid that in the future.
Perhaps we can make sure we get a dead code warning? And change the type to `()` if we're not building with HS support?Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/813Want way to describe a relay in messages2023-10-10T16:14:31ZIan Jacksoniwj@torproject.orgWant way to describe a relay in messagesGiven a `Relay` (or maybe `HasRelayIds`?) one should be able to print its identity, both in full and redacted form.
Perhaps this should be `Display` and `Redactable` impls on `Relay`? A method on `HasRelayIds`? Perhaps there should be...Given a `Relay` (or maybe `HasRelayIds`?) one should be able to print its identity, both in full and redacted form.
Perhaps this should be `Display` and `Redactable` impls on `Relay`? A method on `HasRelayIds`? Perhaps there should be a dedicated `RelayDescription<'_>` type for this?
C-Tor has `node_describe` and other functions with `describe` in their name. We should consider whether we like their output format and how much to copy it; there would be value for users in continuity or similarity, but perhaps there are defects we want to remedy.
When we have this it should be used in (at least) `tor-hsclient/src/err.rs` for the display string for `DescriptorError` and probably elsewhere.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1118#note_2894465
I'm tagging this for HS milestone but it might be relevant to RPC suport, which will need to describe relays and will want to present both machine-readable and human-readable values.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/793Change tor_circmgr::hspool target pool size dynamically2023-06-23T15:33:25ZNick MathewsonChange tor_circmgr::hspool target pool size dynamicallyRight now we hardcode the desired size of our pool of hs circuits. We should instead let it grow and shrink adaptively.
Step 1 here is to see what Tor does, and see whether that makes sense.Right now we hardcode the desired size of our pool of hs circuits. We should instead let it grow and shrink adaptively.
Step 1 here is to see what Tor does, and see whether that makes sense.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/767Want test cases from C Tor for hs time period calculations2023-10-10T16:14:55ZIan Jacksoniwj@torproject.orgWant test cases from C Tor for hs time period calculationsIn !987 we implemented the HS time period calculations. These are super complicated and confusing.
C Tor has a set of test cases in `src/test/test_hs_common.c` in `test_client_service_hsdir_set_sync` and nearby. We should try to copy ...In !987 we implemented the HS time period calculations. These are super complicated and confusing.
C Tor has a set of test cases in `src/test/test_hs_common.c` in `test_client_service_hsdir_set_sync` and nearby. We should try to copy all these into Arti as test vectors, to make sure we do precisely the same thing as C Tor.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/762Decide what to do about hs descriptor cert expiry etc.2023-04-25T16:06:37ZIan Jacksoniwj@torproject.orgDecide what to do about hs descriptor cert expiry etc.This will probably involve a spec clarification and/or investigation of what C Tor does.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999#note_2874581
```
12:41 <+Diziet> nickm: Re descriptor-signing-key-cert validity p...This will probably involve a spec clarification and/or investigation of what C Tor does.
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999#note_2874581
```
12:41 <+Diziet> nickm: Re descriptor-signing-key-cert validity period.
Obviously every signature needs to have a time-limited validity
period.
12:42 <+Diziet> The outer descriptor is signed by KP_hs_blind_id. Is it enough
that KP_hs_blind_id itself is a key which is only valid for a
particular time period ?
13:07 <+nickm> the outer descriptor is not signed by KP_hs_blind_id; it's
signed by KP_hs_desc_sign, which is in turn signed by
KP_hs_blind_id
13:07 <+Diziet> I think maybe we want a ticket for this question.
13:08 <+nickm> no objection; maybe it is the same ticket as the related
question about the status of the certificates in the inner
document. Maybe not.
```Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/758Use spec names for keys etc., not keyword names2023-04-25T15:25:24ZIan Jacksoniwj@torproject.orgUse spec names for keys etc., not keyword namesWhile reviewing arti!999, I was frequently confused by the discrepancy between netdoc document keywords, and the official names for information (as defined elsewhere in the spec). (Context: torspec#187.)
Because in Rust the names of s...While reviewing arti!999, I was frequently confused by the discrepancy between netdoc document keywords, and the official names for information (as defined elsewhere in the spec). (Context: torspec#187.)
Because in Rust the names of struct fields often end up driving the names of local variables, this meant that cryptographic keys, nonces, protocol elements, and so on, were named in the code after the document keyword rather than after their proper official name.
This is not particularly helpful, especially since the same piece of information is often introduced by *different* netdoc keywords in different contexts.
IMO we should switch to using the official names (`kp_hs_desc_enc`, say) *even in structs representing network documents*, rather than names derived from the netdoc keywords. This would relegate the keyword to the doc comment, sadly. But it would mean that the meat of the code would always be referring to a key by its official name, not by some random phrase that happened to be used by the netdoc spec author for that particular key in that particular place.
I don't think we can do this until @nickm's !999 is merged.Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/745hs descriptor encoder2023-04-25T15:35:52ZIan Jacksoniwj@torproject.orghs descriptor encoderWe need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683We need something to construct hidden service descriptors. These have multiple phases of construction, which use different private key material. This will need some kind of multi-stage API.
Part of #683Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/738Write a proxy-plus-socketpair wrapper for DataStream2024-02-24T18:32:24ZNick MathewsonWrite a proxy-plus-socketpair wrapper for DataStreamIn order to provide FFI for the most general purposes, we'll need to provide real sockets. That implies a socketpair, one side of which we give to the application, and the other side of which is backed by a `DataStream`.
This is necessa...In order to provide FFI for the most general purposes, we'll need to provide real sockets. That implies a socketpair, one side of which we give to the application, and the other side of which is backed by a `DataStream`.
This is necessary for #737
See [`ExportedApiSketch.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/ExportedApiSketch.md) for early thoughts.Arti: RPC Support