The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:59:14Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18815Clients don't use optimistic data to fetch their first consensus, because we ...2020-06-27T13:59:14ZRoger DingledineClients don't use optimistic data to fetch their first consensus, because we told them to ask the consensus whether they should```
static int
optimistic_data_enabled(void)
{
const or_options_t *options = get_options();
if (options->OptimisticData < 0) {
/* XXX023 consider having auto default to 1 rather than 0 before
* the 0.2.3 branch goes stable....```
static int
optimistic_data_enabled(void)
{
const or_options_t *options = get_options();
if (options->OptimisticData < 0) {
/* XXX023 consider having auto default to 1 rather than 0 before
* the 0.2.3 branch goes stable. See bug 3617. -RD */
const int32_t enabled =
networkstatus_get_param(NULL, "UseOptimisticData", 0, 0, 1);
return (int)enabled;
}
return options->OptimisticData;
}
```
OptimisticData is "auto" by default, aka -1, so we look at networkstatus_get_param, but since there *is* no consensus on first boot, we pick 0.
For one, this means we're opting not to save a round-trip on the Tor user's first bootstrap (the one where they judge Tor first).
For another, it would seem that we're telling the directory mirror whether this is our first bootstrap, because all the other clients do it differently.
For three, it increases the set of possible behaviors by normal clients that we need to consider during bootstrapping, which is how I found it (working on legacy/trac#18809).
We should make it default default to 1 when there's no consensus.
See https://trac.torproject.org/projects/tor/ticket/3617#comment:8 where it seems I looked into the future and saw this bug coming.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18814Please create an LDAP account for Alison2020-06-27T14:19:29ZNima FatemiPlease create an LDAP account for Alison```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please create an LDAP account for Alison.
Username: Alison
Email: macrina@riseup.net
Fingerprint: FBF0 E7DB 1433 018E E52D 0DDA 9FC3 4089 CBE8 3CA3
-----BEGIN PGP SIGNATURE-----
i...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please create an LDAP account for Alison.
Username: Alison
Email: macrina@riseup.net
Fingerprint: FBF0 E7DB 1433 018E E52D 0DDA 9FC3 4089 CBE8 3CA3
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXDpAUAAoJEMAJ2xkckqd7p1oQALfIIeyRBWm11gZu7gEs9hTs
brqnV2glK3zCsUegkl0Kq5BLsubLVHn1AmALcTtukcLDh6p8ND6GLuYdXvYLhNfO
JZnjpFV1Eo6fOwexJwX+l5gbiIALeD4d3Xjmga5txxMwkzNKGNaD8jxKRzb0s1vT
9vknLeMmsYTCv8M9dz5wfNf/dPDJNuvKlshUL7iP2W9m5QeBFbIbmH4xVOtn1rDP
en+mg+gcbszTdjzqMRBlHGrqNZkrH6lauvIL3AiUcqIVfIDoW3ZDCTR8nbikoq0H
10I856p106LeaHioqoVzrSxNRjiirSrFTBwc+rK7s33c7M5S7K+c0XOoNgE2upgA
/TA/0w2k3UueSV0hqKSnSoNVxz/iRfk1QVyKaXmBuxgMOHHGTxeLUsXM3hJtm8Ph
qBpT2ILUate4+A/d8rdr53KgaBh569foi1rcFyOIyT7MOy1ZHz5rh7+qqNXaNTXE
r//iR7TB3WeUw79uRcE+40QgMlO50sBZk33KBitxaJ+eRBg0wv8G6kNDrjoF0OIi
UPM/npuvIFn+D4k5aVMZJAvGxKFO7euV+cyivjuVzI++qo3nxQwUW3e5xYrTsyeK
+jbOE18oe7Odk5YyWfPGa8NO9YBG6XkJzeIlrcdyJq3ypiMhwh3aScwM+uUgT/qc
DuGMuB5ewZ5pWrxqDcx/
=8+xh
-----END PGP SIGNATURE-----
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18813Tor Browser breaks rendering of fonts in applications launched from Tor Browser2022-11-30T16:47:36ZadrelanosTor Browser breaks rendering of fonts in applications launched from Tor BrowserTor Browser adds few additional environment variables which breaks `kdialog` and likely other applications also:
```
FONTCONFIG_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig
LD_LIBRARY_PATH=/home/user/tor-browser_...Tor Browser adds few additional environment variables which breaks `kdialog` and likely other applications also:
```
FONTCONFIG_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Data/fontconfig
LD_LIBRARY_PATH=/home/user/tor-browser_en-US/Browser/TorBrowser/Tor/
```
screenshot:
https://i.imgur.com/1ItY3jR.png
([This issue was originally reported against QubesOS.](https://github.com/QubesOS/qubes-issues/issues/1892))
Perhaps do not modify environment variables for applications launched from Tor Browser?https://gitlab.torproject.org/tpo/core/tor/-/issues/18812[warn] Tried connecting to router at 81.7.17.171:443, but identity key was no...2020-06-27T13:59:14ZRoger Dingledine[warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
...I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 13 03:17:50.620 [warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
Apr 13 03:17:52.147 [notice] Bootstrapped 40%: Loading authority key certs
[...]
```
So I think everything is going according to plan (cool, I even used a fallback dir!), except my fallback dir seems to have changed its key since it went into fallback_dirs.inc.
Maybe it isn't so reliably stable after all? :) :/
I wonder if we should consider a) doing periodic full checks of the fallback relays, to catch issues like this one preemptively, and then b) making the warning less scary for normal users.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18811Our first-party isolation patch incorrectly rejects blobs retrieved in workers2020-06-27T14:39:19ZArthur EdelsteinOur first-party isolation patch incorrectly rejects blobs retrieved in workersWhen isolation is enabled, blobs retrieved by an XHR inside a worker are rejected even when the blob's first party matches the worker's first party. I found that the regression was caused by this Mozilla patch:
https://hg.mozilla.org/moz...When isolation is enabled, blobs retrieved by an XHR inside a worker are rejected even when the blob's first party matches the worker's first party. I found that the regression was caused by this Mozilla patch:
https://hg.mozilla.org/mozilla-central/diff/12a852867c16/dom/base/nsXMLHttpRequest.cpp#l1694
Because of the Mozilla patch, when we are in a worker, NS_NewChannel is no longer passed a document, so our patch code in `nsHostObjectProtocolHandler::NewChannel2` is not able to obtain the correct first party. Therefore the blob URI is rejected even if the first party of the worker matches. I haven't yet figured out how to fix this problem.Arthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18809Handle linked connections better during bootstrap2020-06-27T13:59:15ZteorHandle linked connections better during bootstrapbegindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from legacy/trac#4483 that checks for consensuses that are downloading:
* is it a direct conn...begindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from legacy/trac#4483 that checks for consensuses that are downloading:
* is it a direct connection in state after connecting, or
* a linked connection that's attached, or
* a linked connection that's in a state after sending
And then do the standard "extra consensus download check" when we're about to link a directory connection to a TLS connection.
Or arma may have a better idea.
I am not sure whether we should fix this in 0.2.8, because the current code works, but it's not optimal when too many TLS connections hang.
Tagging it just in case.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18808Check if connection is excess in connection_dir_finished_flushing2020-06-27T13:59:15ZteorCheck if connection is excess in connection_dir_finished_flushingIn legacy/trac#4483, I added a check like the one below to every transition from DIR_CONN_STATE_CONNECTING to another state, but I missed connection_dir_finished_flushing:
```
/* Close this connection if there's another consensu...In legacy/trac#4483, I added a check like the one below to every transition from DIR_CONN_STATE_CONNECTING to another state, but I missed connection_dir_finished_flushing:
```
/* Close this connection if there's another consensus connection
* downloading (during bootstrap), or connecting (after bootstrap). */
if (connection_dir_close_consensus_conn_if_extra(conn)) {
return;
}
```
It would be good to to fix this in 0.2.8, because otherwise clients could end up requesting multiple consensuses, which is expensive for relays and for the network.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18807Trac Error: OSError: [Errno 12] Cannot allocate memory2020-06-27T14:19:29ZbugzillaTrac Error: OSError: [Errno 12] Cannot allocate memoryTrac Error
Event provider ChangesetModule failed for filters " - pluggable-transports/bundle.git", "Changesets in all repositories", " - torbutton", " - stem", " - pluggable-transports/obfsproxy", " - tor", " - bridgedb", " - tor...Trac Error
Event provider ChangesetModule failed for filters " - pluggable-transports/bundle.git", "Changesets in all repositories", " - torbutton", " - stem", " - pluggable-transports/obfsproxy", " - tor", " - bridgedb", " - torbrowser", " - builders/tor-browser-bundle": OSError: [Errno 12] Cannot allocate memory
You may want to see the other kinds of events from the Timeline or notify your Trac administrator about the error (detailed information was written to the log).Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18806Please install torsocks on iranicum2020-06-27T14:19:29ZNima FatemiPlease install torsocks on iranicumhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18805Please make an rtc password for gettor2020-06-27T14:19:29ZNima FatemiPlease make an rtc password for gettorPlease and thank you!Please and thank you!https://gitlab.torproject.org/tpo/core/tor/-/issues/18803Tools to manage Tor's intermodule callgraph, and help cut it down to size2021-09-16T14:34:12ZNick 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/tpo/applications/tor-browser/-/issues/18802remove Shumway (JS-based Flash VM)2020-06-27T14:39:19ZMark Smithremove Shumway (JS-based Flash VM) In legacy/trac#18546, Mike said:
Shumway (the flash previewer/player) can bypass proxy settings. If it is compiled in, we should rip it out/disable it at build time, so nobody enables it. In legacy/trac#18546, Mike said:
Shumway (the flash previewer/player) can bypass proxy settings. If it is compiled in, we should rip it out/disable it at build time, so nobody enables it.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18801disable the dom.push prefs2022-11-10T11:46:53ZMark Smithdisable the dom.push prefsIn legacy/trac#18546, Mike said:
We should disable all of the dom.push.* prefs. Even though it seems that only ServiceWorkers can use Push, it would be good for us to ensure now that if we decide to enable ServiceWorkers, push stays off.In legacy/trac#18546, Mike said:
We should disable all of the dom.push.* prefs. Even though it seems that only ServiceWorkers can use Push, it would be good for us to ensure now that if we decide to enable ServiceWorkers, push stays off.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18800Remove localhost DNS lookup in nsProfileLock.cpp2020-06-27T14:39:20ZMark SmithRemove localhost DNS lookup in nsProfileLock.cppIn legacy/trac#18546, Mike said:
We should get rid of the damn DNS lookup for localhost in toolkit/profile/nsProfileLock.cpp.In legacy/trac#18546, Mike said:
We should get rid of the damn DNS lookup for localhost in toolkit/profile/nsProfileLock.cpp.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18799disable Network Tickler2020-06-27T14:39:20ZMark Smithdisable Network TicklerIn legacy/trac#18546, Mike said:
We should patch the "Network Tickler" to be disabled for real, since it looks like it may now apply to the desktop as well.In legacy/trac#18546, Mike said:
We should patch the "Network Tickler" to be disabled for real, since it looks like it may now apply to the desktop as well.https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/18798Analyze descriptor completeness2022-02-28T14:57:22ZiwakehAnalyze descriptor completenessI started a wiki page [here](https://trac.torproject.org/projects/tor/wiki/doc/CollecTor/AnalysisDescriptorCompleteness).
Update: This wiki page needs to be move to our new wiki.I started a wiki page [here](https://trac.torproject.org/projects/tor/wiki/doc/CollecTor/AnalysisDescriptorCompleteness).
Update: This wiki page needs to be move to our new wiki.https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/18797Create a DescriptorGenerator for testing and maybe other purposes2022-04-11T16:41:41ZiwakehCreate a DescriptorGenerator for testing and maybe other purposesquote from legacy/trac#16873:
I pondered adding a `DescriptorGenerator` a while ago, where one would construct a new instance of a `Descriptor`, call its setters to give it some values, and then have the generator generate a text repre...quote from legacy/trac#16873:
I pondered adding a `DescriptorGenerator` a while ago, where one would construct a new instance of a `Descriptor`, call its setters to give it some values, and then have the generator generate a text representation of that descriptor. This would be useful for testing and maybe other things. Now, would the Javadoc of these setters copy the Javadoc of the getters or simply link to them? Or would we use some smarter pattern for building these instances? (And is there a smarter pattern for parsed descriptors than a huge interface with dozens of getters?)https://gitlab.torproject.org/tpo/tpa/team/-/issues/18796deb.torproject.org: merge obfs4proxy apt repository into regular deb.torproje...2020-06-27T14:19:29Zadrelanosdeb.torproject.org: merge obfs4proxy apt repository into regular deb.torproject.org repositoriesCould you please merge http://deb.torproject.org/torproject.org/dists/obfs4proxy/ into the regular repositories such as http://deb.torproject.org/torproject.org/dists/jessie/, stretch, etc.?
Why use a separate repository? I think instru...Could you please merge http://deb.torproject.org/torproject.org/dists/obfs4proxy/ into the regular repositories such as http://deb.torproject.org/torproject.org/dists/jessie/, stretch, etc.?
Why use a separate repository? I think instructions for using deb.torproject.org could be simplified if these all came from a single repository.weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/core/tor/-/issues/18795diversity weighting system2020-07-27T19:11:53ZTracdiversity weighting systemThis idea came up by thinking about how to prefer picking fallbacks that are located in less famous areas to increase diversity of dir-mirror/Tor traffic. (legacy/trac#18749) Diversity could be honored by a higher diversity-weight if rel...This idea came up by thinking about how to prefer picking fallbacks that are located in less famous areas to increase diversity of dir-mirror/Tor traffic. (legacy/trac#18749) Diversity could be honored by a higher diversity-weight if relays are located in countrys with rare Tor usage. Same with with unique adressrange, fameless ASes or not widely used OSes. Something like a diversity weight system could probably take place not just for choosing/rating fallbacks. Data like "Top-10 countries by directly connecting users" on metrics-page could be used for instance to give lesser chance of leading traffic to countys with high amount of mean daily users. Or to increase the chance of picking a circuit through a nonfamous AS. Could this be someting?
**Trac**:
**Username**: tscpdTor: unspecifiedhttps://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/18794add cobertura task2020-06-27T14:22:48Ziwakehadd cobertura taskadd Cobertura task:
requires cobertura 1.9.4.1+dfsg-3 (wheezy or 1.9.4.1+dfsg-4 for jessie)add Cobertura task:
requires cobertura 1.9.4.1+dfsg-3 (wheezy or 1.9.4.1+dfsg-4 for jessie)CollecTor 1.0.0iwakehiwakeh