The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:40:28Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30867Write proxy-go tests to cover existing implementation2020-06-27T13:40:28ZCecylia BocovichWrite proxy-go tests to cover existing implementationCurrently we only have proxy-go tests to test extracting the client's remote IP from the SDP offer.
We should increase test coverage.Currently we only have proxy-go tests to test extracting the client's remote IP from the SDP offer.
We should increase test coverage.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/15522Write Protobufs for any BridgeDB data which must be sent over a network or IP...2020-06-27T13:43:05ZIsis LovecruftWrite Protobufs for any BridgeDB data which must be sent over a network or IPC channelBridgeDB should have [Protobufs](https://developers.google.com/protocol-buffers/docs/overview) for any data structures which must be sent over either network or IPC channels. This includes data such as bridges parsed from Stem (which sho...BridgeDB should have [Protobufs](https://developers.google.com/protocol-buffers/docs/overview) for any data structures which must be sent over either network or IPC channels. This includes data such as bridges parsed from Stem (which should be sent to the database manager from legacy/trac#12031), any data which is going to be exported to CollecTor (e.g. if we were to redesign a new pool "assignments.log" format like for legacy/trac#2755 and exported that), and any data which the client-side Social Distributor (legacy/trac#7520) built into a Tor Browser extension plans to send to BridgeDB and vice-versa.
Protocol buffers have had extensive security reviews, are used extensively in many projects, and would provide automatic code generation for serialisers/marshallers for Python/Java/C++/C/Go, meaning that, for example, both Metrics and BridgeDB could use the same generated code to read the same data format.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5012Write proposals to allow an external program that discovers bridge addresses ...2020-06-27T13:44:08ZKarsten LoesingWrite proposals to allow an external program that discovers bridge addresses to tell Tor about them and start implementing the proposalsThis ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start ...This ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start implementation as needed" part of the deliverable text is vague enough to focus on the design discussion and proposals. If there's time left to implement something, great, but if not, that's fine, too. We can still implement proposals between March and November 2012.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5460Write proposal(s) to implement improved relay/circuit crypto authentication2020-06-27T14:06:36ZMike PerryWrite proposal(s) to implement improved relay/circuit crypto authenticationWe need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it...We need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it, there are two competing possibilities:
1. Self-authenticating crypto (BEAR/LION/LIONESS, others?)
2. Per-hop MAC
The main disadvantage of 1 is that it's likely slow and not very many people use it. The disadvantage of 2 is that it requires us to disclose path length count and position to nodes, as well as have MACs that either grow with increased path length, or become less secure with increased path length.
There are probably other issues. I believe the current plan is to produce both options in one or more proposals and compare and contrast them.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/community/relays/-/issues/71Write proposal to restrict contact information field to email address (and ma...2024-01-23T12:37:46ZGeorg KoppenWrite proposal to restrict contact information field to email address (and make it mandatory)We should write a proposal to make sure `ContactInfo` is really just an email address. We could add a second step where we want to enforce it actually. Tor's man page says:
```
ContactInfo email_address
Administrative c...We should write a proposal to make sure `ContactInfo` is really just an email address. We could add a second step where we want to enforce it actually. Tor's man page says:
```
ContactInfo email_address
Administrative contact information for this relay or bridge. This line
can be used to contact you if your relay or bridge is misconfigured or
something else goes wrong. Note that we archive and publish all
descriptors containing these lines and that Google indexes them, so
spammers might also collect them. You may want to obscure the fact that
it’s an email address and/or generate a new address for this purpose.
ContactInfo must be set to a working address if you run more than one
relay or bridge. (Really, everybody running a relay or bridge should
set it.)
```
which is already pretty close to what I plan to propose. This is related to https://gitlab.torproject.org/tpo/core/arti/-/issues/870.
@gus is not done with the meta proposal yet, so I wait for that. Additionally, I am not sure yet how to split this up properly for some potentially needed tor-spec proposal.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9689Write proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE delivery2022-03-22T12:59:28ZMike PerryWrite proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE deliveryTo protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via legacy/trac#572).
The i...To protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via legacy/trac#572).
The idea is that clients could replay some percentage of their circuits' and TLS connections handshakes via independently authenticated cryptographic paths using the directory mirror keys and legacy/trac#5968. If any one handshake replay failed to yield the same session keys from a replayed DH/ECDH/ntor handshake for any subset of the paths, we know the authentication key for that handshake was stolen and one of the client's paths was MITMed, and we could sound the alarm bells.
We'd probably need two cell types for this: a VERIFY cell that included enough information to replay one or both handshakes, and a RELAY_VERIFY cell that instructed a relay to send an enclosed VERIFY cell on behalf of a remote client.
It would be extra neat if we could use this mechanism as the basis for a proper TLS extension, to allow the whole web to do stuff like this.https://gitlab.torproject.org/tpo/network-health/team/-/issues/173Write proposal for rebuilding the metrics website2022-03-14T16:20:56ZGeorg KoppenWrite proposal for rebuilding the metrics websiteThe proposal could continue our joint work with Simply Secure. While having our current metrics website as the target it's important to keep the whole modernization of our Metrics pipeline in mind as well when scoping the work.The proposal could continue our joint work with Simply Secure. While having our current metrics website as the target it's important to keep the whole modernization of our Metrics pipeline in mind as well when scoping the work.Network Health OKRs 2022 Q1-Q2 (Metrics excluded)Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/5392Write proposal for n23 patch behavior2020-07-24T13:17:41ZRoger DingledineWrite proposal for n23 patch behaviorIn legacy/trac#4488 we located and updated the n23 patch from the Defenestrator paper. It's now in branch 'n23-2' in my git repo.
The next step is to refactor connection_or_consider_sending_flowcontrol_cell(). To do that, we need to kno...In legacy/trac#4488 we located and updated the n23 patch from the Defenestrator paper. It's now in branch 'n23-2' in my git repo.
The next step is to refactor connection_or_consider_sending_flowcontrol_cell(). To do that, we need to know what the function is *supposed* to be doing.
Under what circumstances do we send a flowcontrol cell, and how do we pick the values for it? Just as important, in what cases (e.g. if we're a client) do we *not* send flowcontrol cells?
I'm hoping Mashael will do this, with Ian's help.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/221Write proposal for migration to mdbook.2023-10-04T14:03:34ZNick MathewsonWrite proposal for migration to mdbook.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4826Write proposal for improved consensus voting schedules2020-06-27T14:07:02ZRoger DingledineWrite proposal for improved consensus voting schedulesSebastian suggests that we revise the schedule for consensus voting such that there's a cutoff after which we discard votes from the original authority. So phase 1a is to publish your vote to every authority, phase 1b is to ask every aut...Sebastian suggests that we revise the schedule for consensus voting such that there's a cutoff after which we discard votes from the original authority. So phase 1a is to publish your vote to every authority, phase 1b is to ask every authority for votes you're missing, and during phase 1b we won't accept phase 1a votes.
The goal here is to avoid consensus failures that occur when an authority uploads a vote during phase 1b, and some authorities end up thinking everybody knows it, yet some don't know it.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6790Write proposal draft for directory mirrors to accept, aggregate and hand off ...2022-03-22T13:01:48ZMike PerryWrite proposal draft for directory mirrors to accept, aggregate and hand off descriptors to dirauthsIn the event of DoS or braindead client behavior, directory authorities may need to rate limit or restrict connections. See legacy/trac#2665.
Under these conditions, it would be useful if directory mirrors could also accept relay descri...In the event of DoS or braindead client behavior, directory authorities may need to rate limit or restrict connections. See legacy/trac#2665.
Under these conditions, it would be useful if directory mirrors could also accept relay descriptor data, aggregate it, and hand it off to the authorities after eliminating duplicates. This coupled with legacy/trac#572 should allow the dirauths to better handle sudden traffic spikes by rate limiting or firewalling, without degrading the network.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/147-prevoting-opinions.txt has a related idea, but we may want a push method rather than a pull?https://gitlab.torproject.org/tpo/core/tor/-/issues/3785Write proposal 186 to replace 118, and implement it2020-06-27T14:07:53ZLinus Nordberglinus@torproject.orgWrite proposal 186 to replace 118, and implement it- proposal 118 revised/reworked: listen on and advertise multiple
orports; support microdescriptors [oct 1, nickm]
- implementation of prop 118 []- proposal 118 revised/reworked: listen on and advertise multiple
orports; support microdescriptors [oct 1, nickm]
- implementation of prop 118 []Tor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23979Write performance simulator for Prop2472022-06-17T14:14:01ZMike PerryWrite performance simulator for Prop247We need to evaluate the performance consequences of various parameter choices for Prop247. The plan is to make a plan, and use https://github.com/mikeperry-tor/vanguards to do the testing.We need to evaluate the performance consequences of various parameter choices for Prop247. The plan is to make a plan, and use https://github.com/mikeperry-tor/vanguards to do the testing.https://gitlab.torproject.org/tpo/core/tor/-/issues/20834Write patches for all spec-deviations in prop2712020-06-27T13:57:42ZNick MathewsonWrite patches for all spec-deviations in prop271The prop271 implementation I produced is not 100% conformant to the proposal, since in some cases I found gaps or things that the proposal didn't consider. Before we merge legacy/trac#19877, we should be sure that the spec is up-to-date...The prop271 implementation I produced is not 100% conformant to the proposal, since in some cases I found gaps or things that the proposal didn't consider. Before we merge legacy/trac#19877, we should be sure that the spec is up-to-date too.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5915Write patch to make socks handshakes succeed instantly2022-07-20T16:29:47ZRoger DingledineWrite patch to make socks handshakes succeed instantlyIn legacy/trac#3875 Mike suggests we try out the usability of having the Tor in TBB just immediately succeed at all socks handshakes, and hang up if it gets an end cell rather than a connected cell.
We should whip up a Tor patch that do...In legacy/trac#3875 Mike suggests we try out the usability of having the Tor in TBB just immediately succeed at all socks handshakes, and hang up if it gets an end cell rather than a connected cell.
We should whip up a Tor patch that does this behavior, so somebody can try it out.
(We may or may not want to merge it into mainline Tor branches. I guess it depends how complex the patch is and how successful the tests are.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18196Write options_validate tests for RSOS2020-06-27T13:59:42ZteorWrite options_validate tests for RSOSIn legacy/trac#17178, we add RendezvousSingleOnionNonAnonymousServer.
In legacy/trac#17788, I propose to add RendPolicy and RendPolicyRejectPrivate.
But I want to wait for legacy/trac#17076 to be reviewed and merged before writing optio...In legacy/trac#17178, we add RendezvousSingleOnionNonAnonymousServer.
In legacy/trac#17788, I propose to add RendPolicy and RendPolicyRejectPrivate.
But I want to wait for legacy/trac#17076 to be reviewed and merged before writing options_validate unit tests for these options.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/network-health/metrics/exit-scanner/-/issues/33508Write Ops Doc for check service2021-04-08T13:05:49ZirlWrite Ops Doc for check serviceMirroring the format of https://help.torproject.org/metrics/ops/onionoo-ops/ unless anarcat has requests for things to include here.
The sections on deployment and disaster recovery can already be written.
The sections on monitoring wi...Mirroring the format of https://help.torproject.org/metrics/ops/onionoo-ops/ unless anarcat has requests for things to include here.
The sections on deployment and disaster recovery can already be written.
The sections on monitoring will have to wait for monitoring to exist.irlirlhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40421Write on app stores to report bugs to monitored places2022-02-03T19:37:27ZcypherpunksWrite on app stores to report bugs to monitored placesMany, *many* users of the mobile apps write their bugs as a star-review on the app store where they downloaded them. Scrolling through their comments, it's obvious that Tor Project does not regularly monitor the messages on the app store...Many, *many* users of the mobile apps write their bugs as a star-review on the app store where they downloaded them. Scrolling through their comments, it's obvious that Tor Project does not regularly monitor the messages on the app stores. To improve monitoring and reporting, write on the mobile app stores' description pages to tell users to report bugs to monitored places: GitLab, anonymous GitLab, email, blog, IRC, etc. Write it with *emphasis* in **bold** or CAPS in a format and location on the page that is equivalent in response to their immense and persistent use of the reviews to submit their bug reports. In the message, link to the [contact page](https://www.torproject.org/contact/) of torproject.org that contains links to everywhere else.
* https://play.google.com/store/apps/details?id=org.torproject.torbrowser
* https://guardianproject.info/fdroid/
* https://apps.apple.com/us/app/onion-browser/id519296448https://gitlab.torproject.org/tpo/web/support/-/issues/199Write on app stores to report bugs to monitored places2021-04-29T16:57:52ZcypherpunksWrite on app stores to report bugs to monitored placesMany, *many* users of the mobile apps write their bugs as a star-review on the app store where they downloaded them. Scrolling through their comments, it's obvious that Tor Project does not regularly monitor the messages on the app store...Many, *many* users of the mobile apps write their bugs as a star-review on the app store where they downloaded them. Scrolling through their comments, it's obvious that Tor Project does not regularly monitor the messages on the app stores. To improve monitoring and reporting, write on the mobile app stores' description pages to tell users to report bugs to monitored places: GitLab, anonymous GitLab, email, blog, IRC, etc. Write it with *emphasis* in **bold** or CAPS in a format and location on the page that is equivalent in response to their immense and persistent use of the reviews to submit their bug reports. In the message, link to the [contact page](https://www.torproject.org/contact/) of torproject.org that contains links to everywhere else.
* https://play.google.com/store/apps/details?id=org.torproject.torbrowser
* https://guardianproject.info/fdroid/
* https://apps.apple.com/us/app/onion-browser/id519296448https://gitlab.torproject.org/tpo/core/tor/-/issues/3539Write manpage entries for Proposal171 FooPort syntax2020-06-27T14:08:03ZNick MathewsonWrite manpage entries for Proposal171 FooPort syntaxMy prop171 branch implements new syntax for (SOCKS/Trans/DNS/NATD)Port -- this syntax needs to be documented in the manpage.My prop171 branch implements new syntax for (SOCKS/Trans/DNS/NATD)Port -- this syntax needs to be documented in the manpage.Tor: 0.2.3.x-finalNick MathewsonNick Mathewson