#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely --------------------------+------------------------------------ Reporter: gk | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Tor: 0.3.3.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------+------------------------------------
Old description: > In #22341 we are thinking about picking up LZMA- and zstd-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- > launc...@torproject.org.xpi!/components/tl-protocol.js :: > TorProtocolService.prototype._torReadLine :: line 920" data: no] > }}} New description: In #22341 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- launc...@torproject.org.xpi!/components/tl-protocol.js :: TorProtocolService.prototype._torReadLine :: line 920" data: no] }}} -- Comment (by gk): Turns out this is affecting Zstandard-compressed diffs as well: {{{ Jan 10 07:55:33.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as Zstandard compressed, and it seems to be Zstandard compressed. Jan 10 07:55:53.000 [info] handle_response_fetch_consensus(): Applied consensus diff (size 522839) from server 'XX.XX.XX.XX:9001', resulting in a new consensus document (size 1866898). }}} This time it hit the 2 second Torbutton timeout breaking the local SOCKS port check. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24826#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs