Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:02:20Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20459ewma_cmp_cmux never considers policies different2020-06-13T15:02:20Zpastlyewma_cmp_cmux never considers policies differentLooks like a copy/paste bug from [700d6e75](https://gitweb.torproject.org/tor.git/commit/?id=700d6e75). See [line 502](https://gitweb.torproject.org/tor.git/tree/src/or/circuitmux_ewma.c?id=01482e30ad8a453f3721ef17a4a9633806b90684#n502)....Looks like a copy/paste bug from [700d6e75](https://gitweb.torproject.org/tor.git/commit/?id=700d6e75). See [line 502](https://gitweb.torproject.org/tor.git/tree/src/or/circuitmux_ewma.c?id=01482e30ad8a453f3721ef17a4a9633806b90684#n502).
The earliest branches I see this commit in are {maint,release}-0.2.6.
Branch incoming once I get a ticket number.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20376Do not mark circs for close again after relay_send_command_from_edge()2020-06-13T15:02:05ZtwimDo not mark circs for close again after relay_send_command_from_edge()Since `relay_send_command_from_edge()` already does mark failed circs for close there is no reason to do it again.
Please see the patch attached or branch `duplicate-mark-for-close` at https://gitlab.com/nogoegst/tor.Since `relay_send_command_from_edge()` already does mark failed circs for close there is no reason to do it again.
Please see the patch attached or branch `duplicate-mark-for-close` at https://gitlab.com/nogoegst/tor.Tor: 0.3.0.x-finaltwimtwimhttps://gitlab.torproject.org/legacy/trac/-/issues/20278cert-spec.txt contains incomplete reference / documentation for certificate t...2020-06-13T15:01:53Zpatrickodcert-spec.txt contains incomplete reference / documentation for certificate typesThe cert-spec.txt [document references various Certificate types](https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt#n93) in a section 4.2, but there exists no such complete documentation in any of the -spec.txt files.
The sec...The cert-spec.txt [document references various Certificate types](https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt#n93) in a section 4.2, but there exists no such complete documentation in any of the -spec.txt files.
The section 4.2 that it appears to reference [is in prop 220](https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt#n438) which includes specs for each of the cert types mentioned:
* Link key certificate certified by Ed25519 signing key
* Ed25519 TLS authentication key certified by Ed25519 signing key
* RSA cross-certificate for Ed25519 identity keyTor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20262Onion services startup time always gets revealed2020-06-13T15:01:48ZtwimOnion services startup time always gets revealedDue to dead code in `rend_consider_services_upload()` startup time of onion services always gets revealed.
If service descriptor is not uploaded yet we add random delay from [rendinitialpostdelay;rendinitialpostdelay+rand(2*rendpostper...Due to dead code in `rend_consider_services_upload()` startup time of onion services always gets revealed.
If service descriptor is not uploaded yet we add random delay from [rendinitialpostdelay;rendinitialpostdelay+rand(2*rendpostperiod)] ( [30s;30s+2h] ):
```
if (!service->next_upload_time) {
service->next_upload_time =
now + rendinitialpostdelay + crypto_rand_int(2*rendpostperiod);
```
But this delay is useless when we're checking whether we should upload:
```
if (intro_points_ready &&
(service->next_upload_time < now ||
(service->desc_is_dirty &&
service->desc_is_dirty < now-rendinitialpostdelay))) {
/* Upload */
```
Because descriptor is dirty for never-yet-uploaded services it always gets uploaded after being stable for `rendinitialpostdelay` seconds. `next_upload_time` is further in future than `rendinitialpostdelay` stabilization stuff.
So it goes.
I made a patch to unbork this function to work properly.
But it raised a problem. We got used to expect that descriptors are going to be uploaded pretty soon. But 'now' they will be uploaded with delay up to 2h. That's not okay. Should we make a `torrc` option like `RevealOnionServiceStartupTime` that defaults to 1?Tor: 0.3.0.x-finaltwimtwimhttps://gitlab.torproject.org/legacy/trac/-/issues/17238prop224: Implement HSDir support2020-06-13T15:03:52ZDavid Gouletdgoulet@torproject.orgprop224: Implement HSDir supportThis is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support ...This is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support the new descriptor format. This is only on the relay side.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15055Implement ed25519 link handshake2020-06-13T15:05:30ZNick MathewsonImplement ed25519 link handshakeIn #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.In #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewson