Timestamps in tor-browser tar file are set to a fixed value
In the tor-browser tar files, every file's modification time is set to the same value (Jan 1, 2000).
As a result, tools such as rsync that look at modification times to determine whether two files differ will fail in strange ways.
For example, after running the following commands:
mkdir tb1 tb2
tar -xJf tor-browser-linux64-6.5.2_en-US.tar.xz -C tb1
tar -xJf tor-browser-linux64-7.0_en-US.tar.xz -C tb2
rsync -a --delete tb2/ tb1/
a reasonable user would expect that 'tb1' would contain a working copy of Tor Browser. However, several files would be out of date:
tor-browser_en-US/Browser/application.ini
tor-browser_en-US/Browser/browser/blocklist.xml
tor-browser_en-US/Browser/liblgpllibs.so
tor-browser_en-US/Browser/libnssdbm3.so
tor-browser_en-US/Browser/libplds4.so
tor-browser_en-US/Browser/libsmime3.so
tor-browser_en-US/Browser/platform.ini
tor-browser_en-US/Browser/TorBrowser/Docs/sources/bundle.inputs
with potentially disastrous consequences. (I have no idea whether any of the above constitute a security issue in this instance.)
I presume that the timestamps are set to a fixed value in order to make the tar files more easily reproducible. However, there are many ways to do that without creating new security problems:
-
set each timestamp to a hash of the file contents
-
set every timestamp to a fixed value derived from the Tor Browser version number
-
set every timestamp to the date of the most recent commit in some particular git repository
... basically, anything other than setting every timestamp to exactly the same value for every release.