The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:19:28Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/18817weasel: may i have a path-spec link from https://spec.torproject.org/ ?2020-06-27T14:19:28ZRoger Dingledineweasel: may i have a path-spec link from https://spec.torproject.org/ ?weasel suggested i make a ticket, so here is one! thanks!weasel suggested i make a ticket, so here is one! thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/18816We still wait 120 seconds for cert fetches from missing dir mirrors2020-06-27T13:59:14ZRoger DingledineWe still wait 120 seconds for cert fetches from missing dir mirrorsIn legacy/trac#4483 and prop210 we set up an elaborate download schedule for consistently reaching fallbackdirs when fetching the consensus, so we don't end up just sitting there for 120 seconds while a tcp connection waits (and eventual...In legacy/trac#4483 and prop210 we set up an elaborate download schedule for consistently reaching fallbackdirs when fetching the consensus, so we don't end up just sitting there for 120 seconds while a tcp connection waits (and eventually the SocksTimeout parameter is reached and we move on).
But we didn't do any similar thing with fetching the key certs. I just had my bootstrap go smoothly through the legacy/trac#4483 features (with the fixes from legacy/trac#18809) and then it stalled for 2 minutes trying to fetch the certs from a fallbackdir that's offline.
Sure enough, in authority_certs_fetch_missing() I see
```
/* XXX - do we want certs from authorities or mirrors? - teor */
directory_get_from_dirserver(DIR_PURPOSE_FETCH_CERTIFICATE, 0,
resource, PDS_RETRY_IF_NO_SERVERS,
DL_WANT_ANY_DIRSERVER);
```
So teor noticed this one too.
I think in 0.2.8, if we leave the fallbackdir stuff in (meaning we merge legacy/trac#18809 or equivalent into 0.2.8), we could bandage this one by changing DL_WANT_ANY_DIRSERVER to DL_WANT_AUTHORITY, and then it wouldn't be much worse than it is now (in terms of performance -- we would indeed lose the ability to bootstrap from scratch when the authorities are unavailable).
Longer term (0.2.9 and later), I think we should explore a) having directory_get_from_dirserver() notice that there are tls conns established to dir mirrors that we just recently used (and prefer them), or b) trying to explicitly remember the dir mirror that gave us the consensus and re-use it, and/or c) designing a piggy-back mechanism so we can ask for "the certs that go with this consensus" when we're fetching a consensus and we know we will want the certs for it too (thus saving a round-trip).Tor: 0.2.8.x-finalhttps://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)