Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T12:56:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/11454If two auth certs are both old but were generated nearby in time, we keep both2022-03-22T12:56:36ZRoger DingledineIf two auth certs are both old but were generated nearby in time, we keep bothIn trusted_dirs_remove_old_certs() we check if
```
(cert_published + OLD_CERT_LIFETIME < newest_published)) {
```
when deciding whether to discard an old cert from our cache.
We don't check it at all with respect to current ...In trusted_dirs_remove_old_certs() we check if
```
(cert_published + OLD_CERT_LIFETIME < newest_published)) {
```
when deciding whether to discard an old cert from our cache.
We don't check it at all with respect to current time.
So if an authority generates a signing key in January, and then generates ten more signing keys within a week, and now it's April, we'll still keep all of them until they expire or until a new signing key shows up that's more than 7 days newer than them.
This cannot be the right logic.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8546Make a copy-able connection-config type to limit copy burden of isolation fla...2020-06-13T14:28:23ZNick MathewsonMake a copy-able connection-config type to limit copy burden of isolation flags, etcRight now, an increasingly large number of fields and flags are duplicated between port_cfg_t, listener_connection_t, and (say) entry_connection_t. Every field we add here needs to be added to every one of those types, and needs to be e...Right now, an increasingly large number of fields and flags are duplicated between port_cfg_t, listener_connection_t, and (say) entry_connection_t. Every field we add here needs to be added to every one of those types, and needs to be explicitly copied from each to the next during construction time.
It would make this code much more maintainable if there were a type that we just copied from object to object here.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9729Make bridges publish additional ORPort addresses in their descriptor2020-06-13T14:31:56ZTracMake bridges publish additional ORPort addresses in their descriptorI run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and...I run Tor 0.2.4.17-rc as a bridge configured with multiple IPv4 addresses and one ORPort line for each, like so:
ORPort <n1>:443
ORPort <n2>:443
...
ORPort <nN>:443
When starting tor, the log will show that only <n1> is self-tested and a bridge descriptor is published:
[notice] Now checking whether ORPort <n1>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Tor should publish bridge descriptors for all the available addresses and the bridge authorities should probably put them into pools of different confidentiality levels.
For clarity, the documentation should explain Tor's bandwidth allocation as configured with Relay(Bandwidth|Burst)Rate (per address or total).
**Trac**:
**Username**: sqrt2Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11457Making a signing cert in the future will make everybody discard your real sig...2022-03-22T12:56:36ZRoger DingledineMaking a signing cert in the future will make everybody discard your real signing cert and then want it againRun an authority, with a normal signing authority_certificate. Then move your date into the future (has to be more than one week in the future), and generate and use another signing cert. Relays, clients, and other directory authorities ...Run an authority, with a normal signing authority_certificate. Then move your date into the future (has to be more than one week in the future), and generate and use another signing cert. Relays, clients, and other directory authorities will smoothly upgrade to your new one, and (barring issues like #11454) throw out your old signing cert.
Then throw out your shiny new one, and go back to the one you had been using. Other Tors (dir auths, relays, clients) will say "oh hey, a signature from a cert I don't recognize, let me fetch that". So far so good.
Then 60 seconds later they'll discard this cert, because they know a newer one. Oops.
But this is where is gets good. Your authority discards this older cert too. So do other authorities. And relays.
And then everybody wants a copy and nobody has one, so every 60 seconds everybody asks the next layer up in the dir hierarchy. Everybody's logs are filled with
```
Apr 09 03:44:55.000 [warn] Received http status code 404 ("Not found") from server '127.0.0.1:3002' while fetching "/tor/keys/fp-sk/AD23D263206B997C73AF9B488322E91766748C2C-4335577168B0C0C22AC4A1A0707DD72F41CC8DA6".
```
each minute.Tor: 0.2.6.x-final