GitLab

In #22341 (moved) we are thinking about picking up LZMA- and Zstandard-support for consensus diffs.

For LZMA-compressed diffs I often encounter boostrap delays of at least 20s like this:

Dec 26 21:01:18.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed.
Dec 26 21:01:38.000 [info] handle_response_fetch_consensus(): Applied consensus diff (size 482897) from server 'XX.XX.XX.XX:9001', resulting in a new consensus document (size 1903167).

But, worse, it might even break Tor Browser bootstrap entirely when blocking a Tor Launcher GETCONF call (throwing an exception as Tor Launcher thinks tor is not working) like so:

Dec 30 23:54:54.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed.
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
[12-30 22:54:55] TorLauncher DBUG: readTorSettings ----------------------------------------------
[12-30 22:54:55] TorLauncher DBUG: Sending Tor command: GETCONF UseBridges
[12-30 22:55:10] TorLauncher NOTE: Exception on control port [Exception... "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT) [nsIBinaryInputStream.readBytes]"  nsresult: "0x804b000e (NS_ERROR_NET_TIMEOUT)"  location: "JS frame :: jar:file:///home/thomas/Arbeit/TBB/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-launcher@torproject.org.xpi!/components/tl-protocol.js :: TorProtocolService.prototype._torReadLine :: line 920"  data: no]