Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33781DocTor chokes on malformed dirreq-stats-end line2020-06-13T15:52:42ZGeorg KoppenDocTor chokes on malformed dirreq-stats-end lineI started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-en...I started to get a bunch of emails going like this:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 04/01/2020 11:35
error: Malformed dirreq-stats-end line: dirreq-stats-end 2020-03-30 21:23:53 (86400 s)
```
Upon inspection it turns out that the lines in question contain an `^M` at the end which is likely to cause the problem.
It's not clear to me where the bug exactly is, meaning where it should get fixed. I thought maybe `stem` is not lenient enough here and teor suggested it's a `tor` bug. Thus, I am filing it here. Attached is the extra info descriptor DocTor is choking on. For some reason not all lines end on a `^M` which is kind of surprising.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33358Update dir-spec for consensus voting improvements2020-06-13T15:51:31ZteorUpdate dir-spec for consensus voting improvementsIn #4631, we change how authorities handle late posted votes. We need to update the dir-spec for this change.In #4631, we change how authorities handle late posted votes. We need to update the dir-spec for this change.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33265Prop 313: 6. Update Directory Spec for IPv6 Stats2020-06-13T15:51:16ZteorProp 313: 6. Update Directory Spec for IPv6 StatsWe want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168We want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33249Prop 312: 4. Update Directory Spec for IPv6 X-Your-Address-Is2020-06-13T15:51:12ZteorProp 312: 4. Update Directory Spec for IPv6 X-Your-Address-IsWe should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we sho...We should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we should look at what relays currently do (in tor 0.3.5 to 0.4.2, as of January 2020).
See proposal 312, section 4, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1432https://gitlab.torproject.org/legacy/trac/-/issues/33227Prop 311: 5.1. Update Tor Spec Relay Subprotocols2020-06-13T15:51:00ZteorProp 311: 5.1. Update Tor Spec Relay SubprotocolsWe propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually ...We propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually recommend
or require support for IPv6 extends on all relays.
For the draft text, see proposal 311, section 5.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n608Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33164Update torspec reindex.py for Python 32020-06-13T15:50:43ZteorUpdate torspec reindex.py for Python 3We need to update torspec's proposals/reindex.py for Python 3.
As a consequence, proposal must be encoded in UTF-8.We need to update torspec's proposals/reindex.py for Python 3.
As a consequence, proposal must be encoded in UTF-8.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32627deploy torspec as HTML to GitLab Pages2020-06-13T15:48:42Zeighthavedeploy torspec as HTML to GitLab Pageshttps://github.com/torproject/torspec/pull/96 will deploy torspec in HTML to any GitLab fork setup with CI and Pages (default on gitlab.com). it only adds one file: _.gitlab-ci.yml_
Once merged, the site will show up automatically on ht...https://github.com/torproject/torspec/pull/96 will deploy torspec in HTML to any GitLab fork setup with CI and Pages (default on gitlab.com). it only adds one file: _.gitlab-ci.yml_
Once merged, the site will show up automatically on https://torproject.gitlab.io/torspec, and it'll sync every commit from the canonical repo and automatically rebuild the HTML.
The sed regexps in _.gitlab-ci.yml_ could be used as the beginnings of a conversion to Markdown format, as needed.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32619fix syntax errors in torspec documents2020-06-13T15:48:38Zeighthavefix syntax errors in torspec documentshttps://github.com/torproject/torspec/pull/95 fixes a handful of errors in the syntax of things like the title line and the section names. That makes these files much more machine readable. All of the changes here are trivial.
With th...https://github.com/torproject/torspec/pull/95 fixes a handful of errors in the syntax of things like the title line and the section names. That makes these files much more machine readable. All of the changes here are trivial.
With these changes, then a script can convert these files to a nice collection of HTML pages in a CI job that takes less than a minute to run:
* https://gitlab.com/eighthave/torspec/-/jobs/362125193
* https://eighthave.gitlab.io/torspec/
This provides nice features like links to sections based on the section name:
* https://eighthave.gitlab.io/torspec/control-spec.html#hsfetch
* https://eighthave.gitlab.io/torspec/control-spec.html#circuit-status-changed
* https://eighthave.gitlab.io/torspec/tor-spec.html#tls-security-considerations
Using GitLab CI, this could easily rsync the result to any webserver.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29079Minor bandwidth file spec updates2020-06-13T15:36:47ZteorMinor bandwidth file spec updatesThe terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28359Specify bandwidth-file-hash in torspec2020-06-13T15:33:53ZteorSpecify bandwidth-file-hash in torspecWe need to update the spec for #26698We need to update the spec for #26698Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26829torspec: bandwidth file generators should write the file atomically2020-06-13T15:28:12Zteortorspec: bandwidth file generators should write the file atomicallyGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathGenerators should either:
* write the file to a temporary location, then rename it to the final path, or
* write the file to an archival location, then symlink it to the final pathTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26827torspec: DirAuths should only read the V3BandwidthsFile once per vote2020-06-13T15:28:11Zteortorspec: DirAuths should only read the V3BandwidthsFile once per voteOnce #26797 is implemented, we should document it in the spec.Once #26797 is implemented, we should document it in the spec.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26796Use a consistent name for the bandwidth-file-headers line2020-06-13T15:28:03ZteorUse a consistent name for the bandwidth-file-headers lineWe're calling it bandwidth-file in the spec, and bandwidth-file-headers in the code.
We want to add a bandwidth file hash in #26698, so let's call the headers bandwidth-file-headers.We're calling it bandwidth-file in the spec, and bandwidth-file-headers in the code.
We want to add a bandwidth file hash in #26698, so let's call the headers bandwidth-file-headers.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26702Remind authority operators that bandwidth files should be written atomcally2020-06-13T15:27:46ZteorRemind authority operators that bandwidth files should be written atomcallyTor reads bandwidth files when it's voting, around 50 minutes past every hour, and 20 minutes past hours when the consensus has failed.
We should recommend that authority operators generate and transfer bandwidth files ~~between 5-15 or...Tor reads bandwidth files when it's voting, around 50 minutes past every hour, and 20 minutes past hours when the consensus has failed.
We should recommend that authority operators generate and transfer bandwidth files ~~between 5-15 or 35-45 minutes~~ outside of 15-25 and 45-55 minutes past the hour. ~~The best place for this might be in dir-spec or the bandwidth file spec.~~Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26694dir-spec: DirAuths should expose bwauth bandwidth files2020-06-13T15:27:43Zjugadir-spec: DirAuths should expose bwauth bandwidth filesThis ticket is for changing dir-spec to implement #21377This ticket is for changing dir-spec to implement #21377Tor: 0.4.1.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/26541Fix minor mistakes in the bandwidth-file dir-spec entry2020-06-13T15:27:19ZteorFix minor mistakes in the bandwidth-file dir-spec entryatagar pointed out the following errors in the bandwidth-file dir-spec entry:
The bandwidth-file line appears:
```
[At most once for votes; does not occur in consensuses.]
```
He also suggested that we could change the name to bandwidt...atagar pointed out the following errors in the bandwidth-file dir-spec entry:
The bandwidth-file line appears:
```
[At most once for votes; does not occur in consensuses.]
```
He also suggested that we could change the name to bandwidth-file-headers or bandwidth-headers if we want. I don't mind what we call it, but it has to match #3723.
I also noticed that the definition of Value is wrong, it should be:
```
Value ::= ArgumentCharValue+
ArgumentCharValue ::= any printing ASCII character except NL and SP.
```
We should also add the new file_created and latest_bandwidth header keywords from bandwidth-file-spec.
Edit: file_created and latest_bandwidth were added in #26155 and it has been merged 3 now to master
Edit: previous line is about adding them to dir-specTor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/26457Rewrite the UTF-8 conformity section of prop#2852020-06-13T15:26:59ZteorRewrite the UTF-8 conformity section of prop#285I rewrote the UTF-8 conformity section of prop#285 to be more specific, use terminology from The Unicode Standard, and ban byte-swapped byte order marks.
Please see my branch utf-8-extra on https://github.com/teor2345/torspec.gitI rewrote the UTF-8 conformity section of prop#285 to be more specific, use terminology from The Unicode Standard, and ban byte-swapped byte order marks.
Please see my branch utf-8-extra on https://github.com/teor2345/torspec.gitTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25727Add bool types to Rust coding standards guidelines2020-06-13T15:24:11ZIsis LovecruftAdd bool types to Rust coding standards guidelinesSimilar to #25368, we can once again expand upon which Rust types are safe to send over the FFI boundary without conversion/serialisation/translation, because Rust's `bool` type and C99's `bool` type are directly compatible. (I think thi...Similar to #25368, we can once again expand upon which Rust types are safe to send over the FFI boundary without conversion/serialisation/translation, because Rust's `bool` type and C99's `bool` type are directly compatible. (I think this also makes an even larger argument moving forward for using `bool`s in C wherever it makes sense, since otherwise we need to convert between the libc `uint8_t` type and the native `u8` in Rust.)Tor: unspecifiedTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25544Complete vanguard specification2020-06-13T15:23:16ZGeorge KadianakisComplete vanguard specificationWe should revise the vanguard proposal (prop247) to be less ambitious and more down-to-earth and closer to what mike's vanguard script is going to be doing.We should revise the vanguard proposal (prop247) to be less ambitious and more down-to-earth and closer to what mike's vanguard script is going to be doing.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24854Extract the authority list from config.c2020-06-13T15:20:14ZteorExtract the authority list from config.cThere is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.in...There is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.inc.
We will need to implement two branches for backporting:
* a branch on maint-0.2.9 for 0.2.9 and later. It has IPv6 addresses.
* ~~a branch on maint-0.2.5 for 0.2.5. It has no IPv6 addresses.~~
(Then, after we have moved it into a separate file, we want to automatically generate the file, in a new format. See the rest of the children of #24818.)Tor: 0.3.4.x-final