Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:05:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21215Lower the directory overhead for low-bandwidth clients2020-06-13T15:05:26ZNick MathewsonLower the directory overhead for low-bandwidth clientsThis is a parent ticket for the actual implementation work of sponsor4. As we complete measurement (#21205) and design (#21209), we'll add child tickets here for the particular work we are going to accomplish.This is a parent ticket for the actual implementation work of sponsor4. As we complete measurement (#21205) and design (#21209), we'll add child tickets here for the particular work we are going to accomplish.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21209Write, revise, analyze proposals for ways to use less directory bandwidth2020-06-13T15:05:23ZNick MathewsonWrite, revise, analyze proposals for ways to use less directory bandwidthWe have a bunch of ideas about how to use less bandwidth for directory stuff. But most of them need to be expanded into proposals, and some of the the ones that *are* proposals need better analysis -- informed in part by the information ...We have a bunch of ideas about how to use less bandwidth for directory stuff. But most of them need to be expanded into proposals, and some of the the ones that *are* proposals need better analysis -- informed in part by the information we hope to get from #21205.
This is a parent ticket. Each child ticket will be for one particular proposal.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21205Instrument clients to measure directory usage2020-06-13T15:05:21ZNick MathewsonInstrument clients to measure directory usageWe want to reduce the directory overhead needed for low-bandwidth clients. To do this well, we should make it so a client can measure how much stuff it downloads, and how much of what kind of traffic it uses to download it.
In general,...We want to reduce the directory overhead needed for low-bandwidth clients. To do this well, we should make it so a client can measure how much stuff it downloads, and how much of what kind of traffic it uses to download it.
In general, this should be local-only measurements for use while testing: there's no reason we need a complex infrastructure for this one, since the results should be pretty uniform given the same client software in the same circumstances.
Here are some strawman scenarios for client usage which we might want to think about:
* Client is completely unused.
* Client is completely unused, but restarted or HUPed once every N hours.
* Client is used to fetch a .onion website once every N hours.
* Client is used to fetch a http website once every N hours.
* Client is turned on, and connected to (say) IRC all the time.
The relevant values of "N" are probably something like: .5 hours, 1 hour, 4 hours, 8 hours, ... up to a week?
This is a parent-ticket. Child tickets will focus on particular measurements we want.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20872option to build non-standard code paths on x862020-06-13T15:03:58Zweasel (Peter Palfrader)option to build non-standard code paths on x86#20868 is a case where one code path gets almost always built on x86, and another is used everywhere else.
This means that we don't notice build or test failures on that other code path.
Should we have options to use the alternate path...#20868 is a case where one code path gets almost always built on x86, and another is used everywhere else.
This means that we don't notice build or test failures on that other code path.
Should we have options to use the alternate path even on x86, so we can build and run tests on our CI using fast machines?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20822Follow-up tasks for prop271 (new guard API) implementation2020-06-13T15:03:42ZNick MathewsonFollow-up tasks for prop271 (new guard API) implementationThis is a parent ticket to capture follow-up tasks that we (might) want to do in order to improve QOI, usability, security, etc, for our new guard algorithm.This is a parent ticket to capture follow-up tasks that we (might) want to do in order to improve QOI, usability, security, etc, for our new guard algorithm.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19380Hand-audit compiler warning results which we wouldn't want to have on-by-defa...2020-06-13T14:58:38ZNick MathewsonHand-audit compiler warning results which we wouldn't want to have on-by-default.These warnings aren't definitely indicative of bugs in our code, and don't seem to be possible for us to fix in all cases. Still, it might be worth auditing all the cases where these warnings trigger, since they _might_ indicate bugs or...These warnings aren't definitely indicative of bugs in our code, and don't seem to be possible for us to fix in all cases. Still, it might be worth auditing all the cases where these warnings trigger, since they _might_ indicate bugs or possible areas of improvement.
```
strict-overflow=3...5 (4.2)
Behaves pretty differently on different GCC versions.
We get warnings for just about every case where we have pointer
math in an addition. That seems nutty.
padded (3)
Not a mistake. Worth looking over for hand-audit purposes, but mostly
harmless.
unsafe-loop-optimizations (4.1)
Worth hand-auditing, but triggers on every kind of interesting for loop.
covered-switch-default
Usually this is defensive programming, but it could be a mistake
in some cases, or could cover up future mistakes?
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19379Consider adding even more compiler warnings, even when they require code chan...2020-06-13T14:58:37ZNick MathewsonConsider adding even more compiler warnings, even when they require code changes.Some of these warnings _might_ be worth adding, either globally or selectively, but they would require a significant amount of effort to modify our code. (I already got the easy cases with #19180, I think.)
```
cast-qual (4.6)
...Some of these warnings _might_ be worth adding, either globally or selectively, but they would require a significant amount of effort to modify our code. (I already got the easy cases with #19180, I think.)
```
cast-qual (4.6)
Rationale: triggers everywhere, even in some pretty normal C. Would
be nice to have it trigger less, but would need to blow up a bunch
of API things. Bigger project.
conversion (4.6)
Rationale: triggers all over. Probably wrong code in some
cases, but careful thought needed in most Bigger project.
sign-conversion (4.6)
Triggers ALL OVER. Quite possibly a bug in some cases, though.
Bigger project.
cast-align (3)
We already do this safely. Need to re-test on a system with
stronger-than-intel alignment rules, though.
shadow (3)
mistake; worth fixing.
switch-default (3)
Not sure this is a good idea; someof these look like mistakes,
but some don't.
assign-enum (clang)
triggers all over; worth fixing.
conditional-uninitialized (clang)
triggers all over; not sure whether this is worth fixing.
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18857Add a soft-deprecation mechanism for configuration options2020-06-13T14:56:35ZNick MathewsonAdd a soft-deprecation mechanism for configuration optionsI'd like to have a way to flag configuration options as "dubious but still supported", and warn users that those options might go away completely unless they explain to us that no, somebody is still using them.
There's a ticket about ki...I'd like to have a way to flag configuration options as "dubious but still supported", and warn users that those options might go away completely unless they explain to us that no, somebody is still using them.
There's a ticket about killing off old options that nobody is using (can't find it, though), and I've started nominating options for my own person sadness at https://docs.google.com/spreadsheets/d/1Np1vBm0jSvUqxwaQdhkqDmYWxe4E3RO0R5RoRMtpkQQ/edit?usp=sharing .
But unless we have a way to mark an option as "warn if set", then we won't have a nice way to do transitions here.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18803Tools to manage Tor's intermodule callgraph, and help cut it down to size2020-06-13T14:56:18ZNick MathewsonTools to manage Tor's intermodule callgraph, and help cut it down to sizeThere's a set of scripts in my module_scripts branch to do this, combining two older projects I'd been calling chopfyt and cgenforcer. It builds callgraphs by looking at .o files, and figures out how to move code around based on a set o...There's a set of scripts in my module_scripts branch to do this, combining two older projects I'd been calling chopfyt and cgenforcer. It builds callgraphs by looking at .o files, and figures out how to move code around based on a set of doxygen instructions.
Doing these should help us make our code even more testable in the future by decoupling the modules.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18636Write sub-proposals for each part of prop257: Refactoring authorities. Implem...2020-06-13T14:55:34ZNick MathewsonWrite sub-proposals for each part of prop257: Refactoring authorities. Implement as appropriate.Proposal 257 outlines a pretty large amount of stuff to do, but each part of it probably needs its own proposal. Let's get cracking on that !Proposal 257 outlines a pretty large amount of stuff to do, but each part of it probably needs its own proposal. Let's get cracking on that !Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18635Make a design for circuit- migration in the event of DoS2020-06-13T14:55:33ZNick MathewsonMake a design for circuit- migration in the event of DoSI'm not saying we should **build** this, but I do think we should come up with a design:
Right now if you DoS a single server in a circuit you observe, you can tell that the circuit went down. Wouldn't it be cool if instead circuits co...I'm not saying we should **build** this, but I do think we should come up with a design:
Right now if you DoS a single server in a circuit you observe, you can tell that the circuit went down. Wouldn't it be cool if instead circuits could migrate and withstand crashes in some subset of their nodes?
This is especially important for introduction circuits and rendezvous circuits, I bet.
This would mean major design changes, and is probably best done with a few researchers and a bunch of whiteboards.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18345Fix all doxygen "X is not documented" warnings2020-06-13T14:54:31ZteorFix all doxygen "X is not documented" warningsQuoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentione...Quoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentioned by `<b>parameter</b>` (with the markup) in the doxygen
comment... we would end up with a lot of complaints.
We could fix this by placing `<b></b>` around documented parameters, and by documented undocumented parameters.
There might even be a way to semi-automatically do this using a script, and then clean up any mismatches.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17295Route-selection and guard-selection logic completely replaced2020-06-13T14:50:22ZNick MathewsonRoute-selection and guard-selection logic completely replacedBy Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier.By Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17294Complete users manuals for low-level layers in tor-guts2020-06-13T14:50:21ZNick MathewsonComplete users manuals for low-level layers in tor-gutsOur tor-guts code (or our doxygen or whatever) should contain a complete users manual for src/common.
At the very least, we have deliverables for the crypto layer and the compat/util layer. But we should overdeliver here. This is a de...Our tor-guts code (or our doxygen or whatever) should contain a complete users manual for src/common.
At the very least, we have deliverables for the crypto layer and the compat/util layer. But we should overdeliver here. This is a deliverable for November 2016Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17293Multiple new anti-DoS designs implemented since Oct 20152020-06-13T14:50:21ZNick MathewsonMultiple new anti-DoS designs implemented since Oct 2015This is a deliverable for November 2016This is a deliverable for November 2016Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17291Module isolation in-use in Tor2020-06-13T14:50:19ZNick MathewsonModule isolation in-use in TorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17289Overall Tor test coverage very high... over 75%?2020-06-13T14:50:18ZNick MathewsonOverall Tor test coverage very high... over 75%?Right now the overall test coverage (stem, network, unit) is something like 69%. We have committed to raise it as high as possible ... over 75%?
This is a deliverable for October 2016.Right now the overall test coverage (stem, network, unit) is something like 69%. We have committed to raise it as high as possible ... over 75%?
This is a deliverable for October 2016.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17288High-priority areas of Tor have test coverage > 80%2020-06-13T14:50:17ZNick MathewsonHigh-priority areas of Tor have test coverage > 80%We'd like the unit test coverage on the highest-priority areas of Tor to be very high indeed. This is a deliverable for October 2016.We'd like the unit test coverage on the highest-priority areas of Tor to be very high indeed. This is a deliverable for October 2016.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17284Implement multiple new testing-focused controller features2020-06-13T14:50:15ZNick MathewsonImplement multiple new testing-focused controller featuresSee https://lists.torproject.org/pipermail/tor-dev/2015-March/008502.html for a big pile of ideas; we should try to implement as many as possible.
Due April 2016.See https://lists.torproject.org/pipermail/tor-dev/2015-March/008502.html for a big pile of ideas; we should try to implement as many as possible.
Due April 2016.Tor: unspecifiedYawning AngelYawning Angelhttps://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 Mathewson