Opened 14 months ago

Last modified 10 months ago

#28102 new defect

Make sure we pick the exact same compile environment for Tor Browser builds

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, TorBrowserTeam201811
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When creating a container image at time t and creating a container image at time t1 it is not guaranteed that we include the same compiler versions etc.

This has led to mar executables being different, for instance (see: comment:52:ticket:26475): GCC version was in both cases 4.9.2 but in one of them contained an updated resulting in GCC: (Debian 4.9.2-10+deb8u1) 4.9.2 as a version string instead of GCC: (Debian 4.9.2-10) 4.9.2.

We could fix that by making sure we compile our own GCC for this case but there might be other packages lurking with the same trouble potential. We should make sure instead that everyone creating *and* using a container image is getting/having the same available.

Child Tickets

Change History (4)

comment:1 Changed 14 months ago by boklm

I can think about the following ways to fix that:

  • specify exactly the versions of the packages we need, when we know that this package can cause reproducibility issues. For example we could make the firefox build on macOS require gcc-49=4.9.2-10+deb8u1. The problem is that any package update could cause such issue, and it can take time until we notice it. With complex package such as gcc, with many dependencies, the list of packages for which we need to specify the version might be long.
  • add a container image version number. We can then increase this number when we need to invalidate old containers after we found that an update is causing a reproducibility issue. Like the first option, this means that we only fix the issues after finding them, and the previous releases can become unreproducible.
  • use snapshots.debian.org to only install package updates that were available on a specific date. I think the main problem would be that changing the selected date would cause everything to be rebuilt, but that might be ok if we don't do it too often.

comment:2 Changed 14 months ago by gk

I like the snapshot idea. And we would change the selected date anyway only in case there are serious reasons why we should need that. I wonder if there is an easy way to visualize which of n critical components got a security update to help us deciding whether we want to redo our containers or not. Otherwise I wonder how we would determine to change the specific snapshot date *proactively*.

comment:3 Changed 14 months ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:4 in reply to:  1 Changed 10 months ago by boklm

Replying to boklm:

I can think about the following ways to fix that:

  • specify exactly the versions of the packages we need, when we know that this package can cause reproducibility issues. For example we could make the firefox build on macOS require gcc-49=4.9.2-10+deb8u1. The problem is that any package update could cause such issue, and it can take time until we notice it. With complex package such as gcc, with many dependencies, the list of packages for which we need to specify the version might be long.
  • add a container image version number. We can then increase this number when we need to invalidate old containers after we found that an update is causing a reproducibility issue. Like the first option, this means that we only fix the issues after finding them, and the previous releases can become unreproducible.
  • use snapshots.debian.org to only install package updates that were available on a specific date. I think the main problem would be that changing the selected date would cause everything to be rebuilt, but that might be ok if we don't do it too often.

An other way to fix this could be to not use the system's gcc to build firefox, but our own build of gcc. We are already doing that for the Windows build, and could maybe share the gcc build as both are based on jessie.

However this would not help if other package updates cause the same kind of issues.

Note: See TracTickets for help on using tickets.