Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:08:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32220Change letterboxing color when dark theme is enabled2020-06-16T01:08:44ZcypherpunksChange letterboxing color when dark theme is enabledChange letterboxing color when dark theme is enabled
It is very white and should be changed to a dark colorChange letterboxing color when dark theme is enabled
It is very white and should be changed to a dark colorhttps://gitlab.torproject.org/legacy/trac/-/issues/28822re-implement desktop onboarding for ESR 682020-06-16T01:07:19ZMark Smithre-implement desktop onboarding for ESR 68As of Firefox 64, the onboarding extension which we used to implement Tor Browser onboarding has been removed. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1462415
https://bugzilla.mozilla.org/show_bug.cgi?id=1457565
More research ...As of Firefox 64, the onboarding extension which we used to implement Tor Browser onboarding has been removed. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1462415
https://bugzilla.mozilla.org/show_bug.cgi?id=1457565
More research is required, but it looks like Firefox's new onboarding experience is integrated into their "activity stream" interface (aka new tab page).https://gitlab.torproject.org/legacy/trac/-/issues/31607App menu items stop working2020-06-16T01:07:10ZMark SmithApp menu items stop workingIn the ESR68-based Tor Browser on macOS, the App menu items are not working. For example, choosing `Quit` or pressing `Cmd+Q` has no effect. Same for `Preferences` and `Cmd+,`
I observed this problem while testing the es-ES and en-US bu...In the ESR68-based Tor Browser on macOS, the App menu items are not working. For example, choosing `Quit` or pressing `Cmd+Q` has no effect. Same for `Preferences` and `Cmd+,`
I observed this problem while testing the es-ES and en-US builds from the following location on an older macOS 10.11.6 system:
https://people.torproject.org/~gk/builds/9.0a6-build4/
I will re-test on a 10.14.x system to make sure it isn't specific to macOS 10.11.x.https://gitlab.torproject.org/legacy/trac/-/issues/2949Make Intermediate Cert Store Memory-Only for TorBrowser2020-06-15T23:24:36ZMike PerryMake Intermediate Cert Store Memory-Only for TorBrowserUser stored certs as well as the intermediate certificate store should be memory-only by default in TorBrowser. This should be easy for user certs. No so sure about intermediate ones. Need to review the relevant code first.User stored certs as well as the intermediate certificate store should be memory-only by default in TorBrowser. This should be easy for user certs. No so sure about intermediate ones. Need to review the relevant code first.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/28655If a bridge supports obfs4, don't give out its other flavors2020-06-13T18:29:20ZRoger DingledineIf a bridge supports obfs4, don't give out its other flavorsThere's a FOCI 2018 paper looking at blocking of bridges inside China, and one of their conclusions is that China has moved from "block by IP:port" to "block to IP":
https://www.usenix.org/conference/foci18/presentation/dunna
If that is...There's a FOCI 2018 paper looking at blocking of bridges inside China, and one of their conclusions is that China has moved from "block by IP:port" to "block to IP":
https://www.usenix.org/conference/foci18/presentation/dunna
If that is so, it means that when bridgedb gives out the vanilla ORPort of an obfs4 bridge, then some user will get it, try to use it from inside China, trigger the active probing, and get the whole IP address blocked -- including the obfs4 port.
The fix: when bridgedb gets a bridge that supports an active-probing resistant transport (right now that means obfs4), it needs to decide not to give out the other transports for that bridge (vanilla ORPort, obfs3, etc).
(There are two caveats for this plan. First, it means we're prioritizing obfs4 bridges for the China context, since all of these transports will still be useful for countries other than China. I'm ok with that. Second, it assumes that the FOCI paper is actually correct in its conclusions about how China has changed its blocking. I recall in the Q&A at the end of the presentation that some folks questioned the analysis, but I didn't follow it enough to form a solid opinion. But even if China isn't doing its censorship in this new way yet, now is a great time for bridgedb to become able to handle it.)Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22871Implement backend for moat2020-06-13T18:28:49ZIsis LovecruftImplement backend for moatWe'll need to finish #15967 and also the following:
- change BridgeDB to request captchas from the new server
- create an API for handing captchas to Tor LauncherWe'll need to finish #15967 and also the following:
- change BridgeDB to request captchas from the new server
- create an API for handing captchas to Tor LauncherIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/18828Regenerate fallback list for 0.2.92020-06-13T16:05:44ZteorRegenerate fallback list for 0.2.9We need to regenerate the fallback directory mirror list in 0.2.9 in case any of the 0.2.8 fallbacks have changed details or gone down.
This should not require another opt-in mailout, as we had ~70 additional fallbacks in 0.2.8 that wer...We need to regenerate the fallback directory mirror list in 0.2.9 in case any of the 0.2.8 fallbacks have changed details or gone down.
This should not require another opt-in mailout, as we had ~70 additional fallbacks in 0.2.8 that were suitable but not selected.
We should also:
* restore the 120 day stability period and 99% uptime requirement that were reduced in 0.2.8 due to #18050
* check the bandwdith range in the script's generated C comments
* check the IP version, netblock, port, and Exit flag proportions in the script's stderr output
Over the longer term, we could:
* reconsider whether to allow 2 fallbacks per operator (contact, family), while keeping 1 per IP
* decide whether to change to an opt-out system, where we includes fallbacks unless operators specifically opt-outTor: 0.3.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32522Create better tooling for canonical tor header includes2020-06-13T15:49:29ZteorCreate better tooling for canonical tor header includesWhen we fix includes, we could also:
* standardise the whitespace
* sort into a consistent order
* remove duplicates
Eventually, we should try to find unused headers, but that seems like a separate ticket. (But we need to do this task f...When we fix includes, we could also:
* standardise the whitespace
* sort into a consistent order
* remove duplicates
Eventually, we should try to find unused headers, but that seems like a separate ticket. (But we need to do this task first.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30381Provide control port commands to ADD/REMOVE/VIEW v3 client-auth2020-06-13T15:46:25ZGeorge KadianakisProvide control port commands to ADD/REMOVE/VIEW v3 client-authWe need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/29976rework bootstrap reporting to use pubsub2020-06-13T15:40:03ZTaylor Yurework bootstrap reporting to use pubsubTor: 0.4.2.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/28636Address WTF-PAD comments by Nick (2018-11-27 over IRC)2020-06-13T15:39:35ZGeorge KadianakisAddress WTF-PAD comments by Nick (2018-11-27 over IRC)Nick expressed the following concerns/comments about the branch:
- Figure out how dormant mode interacts with the padding code.
```
15:27 <+nickm> okay. short version is that tor can enter a "dormant" state when it is inactive for a r...Nick expressed the following concerns/comments about the branch:
- Figure out how dormant mode interacts with the padding code.
```
15:27 <+nickm> okay. short version is that tor can enter a "dormant" state when it is inactive for a really long time, or when the controller tells it to do so.
15:28 <+nickm> we should probably figure out whether being dormant prevents you from sendig padding and vice versa...
15:28 <+nickm> ... and whether it should prevent you from sending padding (and vice versa)...
```
- Do type checking when downcasting the vcarious probability distributions.
- `<+nickm> Also there are all these generic dist_ops functions that you could use ... but the API seems to encourage you not to use them. having wrapper functions instead that call dist->dist_ops.func(dist, ...) would be neat`
- `<+nickm> oh, one list thing: I think src/lib/math is not allowed to include lib/crypt_ops, since that would introduce a circularity. Better make sure that it doesn't`Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24031Protover.rs could use a better algorithm2020-06-13T15:23:41ZNick MathewsonProtover.rs could use a better algorithmThis probably doesn't matter in practice, but: it would be cool if protover.rs used a smarter representation for sets of protocol versions than `HashSet`. Maybe a BTreeSet of (low,high) tuples?This probably doesn't matter in practice, but: it would be cool if protover.rs used a smarter representation for sets of protocol versions than `HashSet`. Maybe a BTreeSet of (low,high) tuples?Tor: 0.3.3.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/21648prop140: Caches generate diffs as appropriate2020-06-13T15:07:01ZNick Mathewsonprop140: Caches generate diffs as appropriateDirectory caches should pre-generate and pre-compress diffs as appropriate. It might be best to do this in a different thread or process. It might be best to pre-generate some and create others on demand.Directory caches should pre-generate and pre-compress diffs as appropriate. It might be best to do this in a different thread or process. It might be best to pre-generate some and create others on demand.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17799Use a better PRNG unless OpenSSL starts using a better one on their own.2020-06-13T14:52:10ZteorUse a better PRNG unless OpenSSL starts using a better one on their own.#17694 hashes important PRNG output with some system randomness before use, so that observed PRNG outputs are resistant to PRNG state analysis.
But almost all of Tor's use of PRNG outputs is observable from one or more locations outside...#17694 hashes important PRNG output with some system randomness before use, so that observed PRNG outputs are resistant to PRNG state analysis.
But almost all of Tor's use of PRNG outputs is observable from one or more locations outside Tor, whether in salts or nonces sent to other machines on the wire, or in the random choices made in guard, directory, and path selection.
We could hash all of the bytes coming from the PRNG to avoid this state exposure. (Although we might not need to use the system randomness source each time.)Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/6720Review and support Firefox 152020-06-13T01:28:49ZMike PerryReview and support Firefox 15https://developer.mozilla.org/en/Firefox_15_for_developers
http://beta.elchi3.de/doctracker/#list=fx&version=15.0
From the dev doc, my major concern at a glance is the high resolution timers. WebSMS also looks bad for mobile. I have not...https://developer.mozilla.org/en/Firefox_15_for_developers
http://beta.elchi3.de/doctracker/#list=fx&version=15.0
From the dev doc, my major concern at a glance is the high resolution timers. WebSMS also looks bad for mobile. I have not yet gone through the undocumented bugs.
Also, lots of patch conflicts this time: 8, 10, 11, 14, and 17-21.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3846Recruit build test/signoff volunteers2020-06-13T01:07:49ZMike PerryRecruit build test/signoff volunteersI still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
Ther...I still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
There also used to be a pastebin or google doc with a testing checklist + instructions in it? Is that lost forever?Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2672Fix bugs/issues with consolidate_stats2020-06-13T00:07:00ZMike PerryFix bugs/issues with consolidate_statsQuoting karsten:
I think there's a bug in this script: Whenever we skip a line in a .data file, because that line represents a failure, we might get out of sync with the .extradata file and stop writing any data to .mergedata. You shoul...Quoting karsten:
I think there's a bug in this script: Whenever we skip a line in a .data file, because that line represents a failure, we might get out of sync with the .extradata file and stop writing any data to .mergedata. You should be able to reproduce this bug with the Torperf 50KB run (https://metrics.torproject.org/data/torperf-50kb.data https://metrics.torproject.org/data/torperf-50kb.extradata). The last line in the result has CIRC_ID=4384. If I delete the line in .extradata starting with CIRC_ID=4397, the result has more entries than before. I think the fix is to distinguish between absolute slack of up to 1 second and a time difference of, say, more than 1 minute.
Also, is there a way to include timed out runs in the .mergedata, too? We do include failures, so by including timeouts, we wouldn't have to parse the original files for timeouts/failures anymore. This could be a new ticket, I'd just like to know whether it's possible.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2514Document an iteration and write up a rosetta stone for reports2020-06-13T00:03:31ZMike PerryDocument an iteration and write up a rosetta stone for reportsI realized it's going to take some time/resources to do this agile nonsense and to explain it to everyone, so why not meta-document and track that time using agile+trac? Sounds like a plan to me.I realized it's going to take some time/resources to do this agile nonsense and to explain it to everyone, so why not meta-document and track that time using agile+trac? Sounds like a plan to me.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5790Rebase+test Firefox patches to 10.0.x-ESR for TBB stable2012-08-29T00:28:19ZMike PerryRebase+test Firefox patches to 10.0.x-ESR for TBB stableI've been convinced that we should be tracking 10.0 ESR for TBB stable by some anonymous cypherpunk in #5737. I should test rebasing the current set of Firefox patches to 10.0.x ESR and see how it works out. If it seems to work, I think ...I've been convinced that we should be tracking 10.0 ESR for TBB stable by some anonymous cypherpunk in #5737. I should test rebasing the current set of Firefox patches to 10.0.x ESR and see how it works out. If it seems to work, I think we should switch over for TBB 2.2.x (but keep tracking Rapid Release for TBB 2.3.x-alpha).Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5965Flag important sections of Torbutton code for preservation2012-07-10T18:50:14ZMike PerryFlag important sections of Torbutton code for preservationI should do a pass over the Torbutton code and mark the sections that we want to keep (or toss) somehow, to make #5709+#1506 easier.I should do a pass over the Torbutton code and mark the sections that we want to keep (or toss) somehow, to make #5709+#1506 easier.Mike PerryMike Perry