Opened 3 years ago

Closed 3 years ago

#22595 closed defect (duplicate)

Timestamps in tor-browser tar file are set to a fixed value

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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:


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.

Child Tickets

Change History (2)

comment:1 Changed 3 years ago by cypherpunks

There are two ways to solve the issue without changing how the tarballs are generated.

  1. tar has the -m and --touch options (see to use the current date as the modification date when extracting.
  2. rsync has the -c and --checksum options to skip based on checksum, not mod-time & size (see

comment:2 Changed 3 years ago by gk

Resolution: duplicate
Status: newclosed

Thanks for reporting this. While I agree that there are ways to avoid this issue when extracting/rsyncing we can do better on our side, especially as the odd date is causing confusion. We have #11506 to deal with that. I therefore resolve this bug as a duplicate of that one.

Note: See TracTickets for help on using tickets.