Tor Specifications issueshttps://gitlab.torproject.org/tpo/core/torspec/-/issues2023-01-05T18:14:59Zhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/177Create Style Guides2023-01-05T18:14:59ZMatthew FinkelCreate Style GuidesFollowing legacy/trac#26184, we should document our coding style preferences. We should consider documenting all Tor Browser-related projects.Following legacy/trac#26184, we should document our coding style preferences. We should consider documenting all Tor Browser-related projects.https://gitlab.torproject.org/tpo/core/torspec/-/issues/163We should make HSv3 desc upload less frequent2022-10-17T19:28:01ZGeorge KadianakisWe should make HSv3 desc upload less frequentWithout checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOA...Without checking the source code right now, HSDirs are supposed to cache HS descriptors for the inscribed lifetime (3 hours), and HSv3s are supposed to upload descriptors at a random time between 1 and 2 hours (see `HS_SERVICE_NEXT_UPLOAD_TIME_MIN`).
This makes HSv3s upload descriptors more frequently than needed. For example, we could increase this to upload descriptors between 2 and 2.9 hours, to make HSv3s less intense on the network.
Someone should double check the above logic and make sure it won't cause issues, and implement it.https://gitlab.torproject.org/tpo/core/torspec/-/issues/83Padding, Keepalive and Drop cells should have random payloads2022-03-17T19:41:21ZteorPadding, Keepalive and Drop cells should have random payloadstor-spec says:
```
Link padding can be created by sending PADDING or VPADDING cells
along the connection; relay cells of type "DROP" can be used for
long-range padding. The contents of a PADDING, VPADDING, or DROP
cell SHOUL...tor-spec says:
```
Link padding can be created by sending PADDING or VPADDING cells
along the connection; relay cells of type "DROP" can be used for
long-range padding. The contents of a PADDING, VPADDING, or DROP
cell SHOULD be chosen randomly, and MUST be ignored.
```
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534
But padding cells sent by channelpadding_send_padding_cell_for_callback() and keepalive cells sent by run_connection_housekeeping() have a payload of all zero bytes.
I don't know if this is a security issue or not. It is probably ok, unless Tor has compression enabled on its TLS connections. If compression is enabled, all the padding data size calculations will be wrong.https://gitlab.torproject.org/tpo/core/torspec/-/issues/15CIRC_BW is only for origin circuits2022-02-21T19:13:04ZteorCIRC_BW is only for origin circuitsThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/21Control spec is ambiguous whether a GETCONF error message is specified2022-02-21T19:13:04ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.https://gitlab.torproject.org/tpo/core/torspec/-/issues/26torspec references UTC, but tor uses unix time (leap second handling)2022-02-21T19:13:04Zteortorspec references UTC, but tor uses unix time (leap second handling)When the various torspec documents specify time, they refer to UTC. But the implementations used by at least Linux, *BSD and OS X are based on the Unix time epoch.
This makes a difference to how leap seconds are handled: UTC includes le...When the various torspec documents specify time, they refer to UTC. But the implementations used by at least Linux, *BSD and OS X are based on the Unix time epoch.
This makes a difference to how leap seconds are handled: UTC includes leap seconds, but unix time excludes them.
We should:
* ensure that none of the security properties of tor depend on leap seconds either being present or absent, either individually or in aggregate:
* every minute is not 60 seconds long (and equivalently for hour, day, week)
* some epoch times can repeat or be missing
* UTC and Unix time differ by approximately 30 seconds
* check how the current Linux, BSD, Windows and OS X implementations handle leap seconds (in roughly that order of priority)
* consider and document tor's handling of leap seconds
See:
* https://en.wikipedia.org/wiki/Leap_second
* https://en.wikipedia.org/wiki/Unix_timehttps://gitlab.torproject.org/tpo/core/torspec/-/issues/22Replace ArgumentCharValue with ValueChar in dir-spec and bandwidth-file-spec2022-02-21T19:13:04ZteorReplace ArgumentCharValue with ValueChar in dir-spec and bandwidth-file-specHaving ArgumentChar and ArgumentCharValue is confusing, see:
https://trac.torproject.org/projects/tor/ticket/26541#comment:15Having ArgumentChar and ArgumentCharValue is confusing, see:
https://trac.torproject.org/projects/tor/ticket/26541#comment:15