Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:52:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16774Add fallback directories to GETINFO2020-06-13T14:52:17ZteorAdd fallback directories to GETINFOIn #15775, we add a list of ~100 fallback directories to the Tor codebase.
Do want to add these to `GETINFO config/defaults` if not already present, or to a separate `GETINFO config/fallback_directories`?In #15775, we add a list of ~100 fallback directories to the Tor codebase.
Do want to add these to `GETINFO config/defaults` if not already present, or to a separate `GETINFO config/fallback_directories`?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16804Add more chutney networks to "make test-network" or such2020-06-13T13:29:24ZNick MathewsonAdd more chutney networks to "make test-network" or suchThe tor 'make test-network' script runs some chutney tests and makes sure they work.
We could get improved integration testing by including hidden services and pluggable transports and bridges, and IPv6 and mixed networks, etc etc, for ...The tor 'make test-network' script runs some chutney tests and makes sure they work.
We could get improved integration testing by including hidden services and pluggable transports and bridges, and IPv6 and mixed networks, etc etc, for instance. Some of these are available now, some would require chutney extensions.Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16794All cryptography unit test coverage should be over 95%; all should have test ...2020-06-13T14:57:00ZNick MathewsonAll cryptography unit test coverage should be over 95%; all should have test vectorsIt's high, but it's not there yet:
```
x/crypto.c.gcov 204 738 78.34
x/crypto_curve25519.c.gcov 8 74 90.24
x/crypto_ed25519.c.gcov 17 95 84.82
x/crypto_format.c.gcov 5 95 95.00
x/crypto_pwbox.c.gcov 2 59 96.72
x/crypto_s2k.c.gcov 14 152...It's high, but it's not there yet:
```
x/crypto.c.gcov 204 738 78.34
x/crypto_curve25519.c.gcov 8 74 90.24
x/crypto_ed25519.c.gcov 17 95 84.82
x/crypto_format.c.gcov 5 95 95.00
x/crypto_pwbox.c.gcov 2 59 96.72
x/crypto_s2k.c.gcov 14 152 91.57
x/aes.c.gcov 0 17 100.00
TOTAL 250 1230 83.11
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17285Alpha version of module-isolation framework2020-06-13T14:50:15ZNick MathewsonAlpha version of module-isolation frameworkSee #17273 for design component of this. Does not need to be merged into 0.2.8, but needs to be done on a similar timeframe.
Due April 2016See #17273 for design component of this. Does not need to be merged into 0.2.8, but needs to be done on a similar timeframe.
Due April 2016Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16825client with explicit EntryNodes, no cached-* files never finds its entrynodes2020-06-13T14:48:15Zstarlightclient with explicit EntryNodes, no cached-* files never finds its entrynodesClient-only 'tor' with explicit guard
nodes configured will stall forever at
Bootstrapped 80% or 85% on cold-start
with cached-* files removed.
Shutdown and fresh start of daemon
required to clear state.Client-only 'tor' with explicit guard
nodes configured will stall forever at
Bootstrapped 80% or 85% on cold-start
with cached-* files removed.
Shutdown and fresh start of daemon
required to clear state.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17273Complete a design for isolating Tor modules2020-06-13T14:50:08ZNick MathewsonComplete a design for isolating Tor modulesWe've been kicking this around for a while; we should actually commit to something in a text file so we can argue about it. December is a good target.We've been kicking this around for a while; we should actually commit to something in a text file so we can argue about it. December is a good target.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16081Document status code consistency for multiple lines in a single reply2020-06-13T14:46:20ZTracDocument status code consistency for multiple lines in a single reply(Opening ticket after discussion in #tor-dev)
The tor control service sends replies in multiple lines from Tor to the controller, each line starting with a status code. The documentation, however, says nothing about the consistency guar...(Opening ticket after discussion in #tor-dev)
The tor control service sends replies in multiple lines from Tor to the controller, each line starting with a status code. The documentation, however, says nothing about the consistency guarantees of these status codes over multiple lines.
If it is indeed correct that these status codes are not supposed to change within a single reply from Tor to controller, the documentation at https://gitweb.torproject.org/torspec.git/tree/control-spec.txt should be improved.
**Trac**:
**Username**: solatisTor: 0.2.8.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16227Document which descriptor lines can have extra fields.2020-06-13T14:46:37ZDamian JohnsonDocument which descriptor lines can have extra fields.Hi, DocTor checks just notified me of an invalid extrainfo descriptor from a tor relay running Tor 0.2.7.1-alpha-dev...
```
router Truie 198.50.156.78 9001 0 9030
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABhWIAZTz0r0KRagr6X9SHfm...Hi, DocTor checks just notified me of an invalid extrainfo descriptor from a tor relay running Tor 0.2.7.1-alpha-dev...
```
router Truie 198.50.156.78 9001 0 9030
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABhWIAZTz0r0KRagr6X9SHfm4oiIuMLVhJQQmNchtkBuR5SuFAQAgBAAVkw7m
0YJgO/A8VMioco097sIOutDiM7UqqPvoIyKErk1akOm3f6VAO/juOzxEeAgzgfA7
DiRsSjeVjp0xUdE43bXhK/8Uh+SPMwYKj47drjgTHGgzjTmlY9B/jFJ1Wgs=
-----END ED25519 CERT-----
platform Tor 0.2.7.1-alpha-dev on Linux
protocols Link 1 2 Circuit 1
published 2015-05-28 15:44:47
fingerprint A692 21A7 EC74 98D2 F88A 0FB7 9526 1013 FA36 CAAE
uptime 61
bandwidth 1073741824 1073741824 9506816
extra-info-digest 0879DB7B765218D7B3AE7557669D20307BB21CAA V609l+N6ActBveebfNbH5lQ6wHDNstDkFgyqEhBHwtA
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALbTpnPvhaGET+2ACtLdG6jhQXN8uVJ0iF9RwMh2hwu351yp3eVPt7os
ditUF6w7KV+6emkvLu9EBpNN7vWrpDAhRNOGTOZhZKLnGFaxp+eGNX6+5AhmiWYt
/+w+f6dvVKEjsaX3XZsMqcTBjw2hzVpHxh/AjgDx/b9mJKC85vENAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALDSt2G+Zjl20a59HZsuag913ONdnnNa/uVMRbsZZkbnNRONf2aXBGgu
wrW7XtPLeAKl+d0d5g9XnePVvefcEdKvoKNCFv6s8s3S2KB/CEkeyE7Lxx1Pc6Qx
f/jgS3T3TFHUlvtZvHLZ/3WaXMyuTTRlGadpzDkQx5oWR6aNn065AgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
TCcCIv38fGcSzUO+DKxudFme2XBRuDkf5FjEr+6UbtDyuDjvjJDFYagN+zMJf/4K
RyBScjyKYK6MVMxAmf25QjAGx3KHV00ozVSzlN3WDAS2iicuKYvBsehG9g/tr6mI
luS5EoSKJIlmM2jOhN1QyR+Rpi37z/E6VTksk/bd69A=
-----END CROSSCERT-----
ntor-onion-key-crosscert 0
-----BEGIN ED25519 CERT-----
AQoABhNgARWTDubRgmA78DxUyKhyjT3uwg660OIztSqo++gjIoSuAEW8gwMcFUSD
mfkijKN6KyZxHloENGcgJMeJsR9kvfYp/u7O+VoPQ1kTxaw1lajTrnGQF+PV1MlK
niid4Nq5ZgM=
-----END ED25519 CERT-----
hidden-service-dir
contact 0x11F48D36 David Goulet <dgoulet AT ev0ke dot net>
ntor-onion-key qDcuoDpDD36bIapIbXBVhkIoiuMIXD9jNfjF1+7Vaks=
reject *:*
router-sig-ed25519 AxqrLz7QL/e+xGhhihs/rNzWsBW0Qla7Cwru1q88A5i+pcQBgfzfECiecptqYbDAsUPXMtwFsLp7Ls2BMOzvCQ
router-signature
-----BEGIN SIGNATURE-----
mSkveaqx79vzXLc6yC2+x8yZMQPe74ihw9tZJDdSOK5VqhzZOKHFM+JoD12noxQd
wgxa+IX0RG65KlguYE7NEZ7M6JOwr6r0zK/pWSZE8ZeHyt7FDx9ygc3k2ybQ6RWE
Hd7QXPiyVgs9cIgnvGFVt/5vzjMV+BELpOtehBrUJbs=
-----END SIGNATURE-----
```
I'm not sure if Truie is just doing something funky. identity-ed25519? router-sig-ed25519? None of these are things in the dir-spec, and its extra-info-digest line is invalid too.
Regardless of how this is being generated, seems like the DirAuths should be balking at such invalid content. Stem certainly doesn't like it when validation is enabled.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17270Evaluate non-C tor implementations for hackability2020-06-13T14:50:07ZNick MathewsonEvaluate non-C tor implementations for hackabilityFor testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for ma...For testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for making a bunch of stub test client/servers.
(It's okay if the client answer and the server answer aren't the same)Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17264Finish "WritingTests.txt" document2020-06-13T14:50:04ZNick MathewsonFinish "WritingTests.txt" documentThis is mostly done, and has been useful to some folks in its nascent form. I'd better finish it up and put it to bed. (Due by end of october)This is mostly done, and has been useful to some folks in its nascent form. I'd better finish it up and put it to bed. (Due by end of october)Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17267Finish first draft of tor-guts (overview of structure of codebase)2020-06-13T14:50:05ZNick MathewsonFinish first draft of tor-guts (overview of structure of codebase)I should finish my main writeup of tor-guts. By end-of-octI should finish my main writeup of tor-guts. By end-of-octTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17266Finish quick-start part of doc/HACKING2020-06-13T14:50:05ZNick MathewsonFinish quick-start part of doc/HACKINGThis needs a substantial revision, but shouldnt' need too much additional effort.
Due by end-of-month.This needs a substantial revision, but shouldnt' need too much additional effort.
Due by end-of-month.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17261Formalize our best-guess guard algorithm2020-06-13T14:50:02ZNick MathewsonFormalize our best-guess guard algorithmWe've made lots of progress in this area but final conclusions seem to elude us. Goal: Figure out what our very best idea is now, and write it down in a single document. Due: end of october.We've made lots of progress in this area but final conclusions seem to elude us. Goal: Figure out what our very best idea is now, and write it down in a single document. Due: end of october.Tor: 0.2.8.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/13989Freak out if we pick too many new guards in too short a time2020-06-13T14:41:13ZNick MathewsonFreak out if we pick too many new guards in too short a timeAccording to the sniper attack paper, we should never really have to pick more than 5 new guards in a 4 week period (I think that's the number). If we do, our network is probably down or filtered or our guards are under attack.
This is...According to the sniper attack paper, we should never really have to pick more than 5 new guards in a 4 week period (I think that's the number). If we do, our network is probably down or filtered or our guards are under attack.
This is going to have some tricky issues. For example, what should we do if we hit this threshold? We could decline to pick circuits until some node we've been willing to use as a guard comes up again, unless the user explicitly tells us to, I guess.
As another issue, we don't currently store exactly when we added a guard, but a randomized version of that. So perhaps we need a fuzzier version of this test.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17280Have a suite of >3 anti-dos proposals2020-06-13T14:50:12ZNick MathewsonHave a suite of >3 anti-dos proposalsWe're funded to work on making the network less DoS-prone, so we should really get a pile of proposals together here.
Target date: februaryWe're funded to work on making the network less DoS-prone, so we should really get a pile of proposals together here.
Target date: februaryTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4483If k of n authorities are down, k/n bootstrapping clients are delayed for min...2020-06-13T14:56:19ZRoger DingledineIf k of n authorities are down, k/n bootstrapping clients are delayed for minutesWhen an authority is down, a client bootstrapping into the network might pick it to learn the consensus, and then have to wait until that attempt times out.
We should try to improve the robustness of the authorities. Fine, but easier sa...When an authority is down, a client bootstrapping into the network might pick it to learn the consensus, and then have to wait until that attempt times out.
We should try to improve the robustness of the authorities. Fine, but easier said than done.
At the same time, we should explore letting clients time out more quickly during critical-path directory requests.
We should make sure not to screw it up for clients that are on genuinely slow and high-latency connections. The goal is to improve time-to-bootstrap for the average case while not harming it (much) for the already bad cases.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15935Implement an advisory-only request to stop for old clients2020-06-13T14:45:50ZteorImplement an advisory-only request to stop for old clientsIn #15233, we want to kill off 0.2.2 and 0.2.3 clients, but we want to make sure they won't increase their request rate to the directory authorities if we stop answering them.
We face this issue every time we kill off old client version...In #15233, we want to kill off 0.2.2 and 0.2.3 clients, but we want to make sure they won't increase their request rate to the directory authorities if we stop answering them.
We face this issue every time we kill off old client versions.
#15228 will change the scope of this issue, as it may affect the fallback directories, as well as the directory authorities.
We don't want to have many of our best directories overloaded with rapid requests from obsolete clients.
I suggest, at a minimum:
1. A advisory request to stop for old clients (which can be disabled on compilation or configuration) as part of a valid, signed consensus:
* a permitted-but-not-recommended client versions list, and every version not on that list should stop? The problem with this is that new dev versions and custom versions would stop.
* an obsoleted client version list, every version on that list should stop? It would be a long list, and custom versions wouldn't be asked to stop.
2. Every request in tor should be random-exponential-backoff, which would resolve repeated-connection overloading issues in general. (split to another ticket #15943)
3. How do we deal with botnets that don't use the full tor code? They need not obey the consensus, or use exponential backoff.
Edit: split #15943, clarify "kill switch" languageTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17199Implement non-adaptive padding negotiation primitives2020-06-13T14:49:44ZMike PerryImplement non-adaptive padding negotiation primitivesThis ticket is to cover the pieces of proposal 254 (https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt) other than the adaptive padding state machine (#7028).
These will be needed for netflow padding (#...This ticket is to cover the pieces of proposal 254 (https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt) other than the adaptive padding state machine (#7028).
These will be needed for netflow padding (#16861) and hidden service circuit setup fingerprinting.Tor: 0.2.8.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/16846Include sizeof(void *) in your extrainfo.2020-06-13T14:48:21ZYawning AngelInclude sizeof(void *) in your extrainfo.From #16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it saf...From #16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it safely.https://gitlab.torproject.org/legacy/trac/-/issues/16801Increase torgzip coverage as high as possible2020-06-13T14:48:07ZNick MathewsonIncrease torgzip coverage as high as possibleWe've actually had bugs in this one that caused needless bandwidth wastage. (eg #11824 and #11787.) Let's see if there are any more!
```
x/torgzip.c.gcov 88 136 60.71
```We've actually had bugs in this one that caused needless bandwidth wastage. (eg #11824 and #11787.) Let's see if there are any more!
```
x/torgzip.c.gcov 88 136 60.71
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewson