[tor-bugs] #25102 [Applications/Tor Browser]: Add script to sign nightly build mar files, generate update-responses xml and publish the new version

[Tor Bug Tracker & Wiki]

#25102: Add script to sign nightly build mar files, generate update-responses xml
and publish the new version
-------------------------------------------------+-------------------------
 Reporter:  boklm                                |          Owner:  boklm
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-rbm, tbb-update,                 |  Actual Points:  4.5
  TorBrowserTeam202004R                          |
Parent ID:  #18867                               |         Points:  3.5
 Reviewer:  gk                                   |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:20 boklm]:
 > GeKo was asking on IRC why we are hardcoding the version of martools we
 are using for signing the mar files, and why we are not just using the
 martools from the nightly builds.
 >
 > The reason to do that is to isolate the signing VM from the build VM.
 The nightly setup looks like this:
 > - the nightly build VM is building the nightly, and makes the builds
 available through http on an onion address. The nightly build is using the
 git master branch from several components, which means that an attacker
 who manages to get root access to the git server would also be able to
 access the build VM.

 Hey, another attacker is coming out of the weeds, good! Keep 'em coming.
 :)

 > - the signing VM fetches the mar files from the build VM through the
 onion address, sign them (using the martools from a stable Tor Browser
 version), and upload the signed mars to
 https://nightlies.tbb.torproject.org/ (using an ssh key). If we were using
 the martools from the nightly build, an attacker who got access to the
 build VM could get access to the signing VM too and steal the signing key,
 and the ssh key to upload malicious mar files to
 nightlies.tbb.torproject.org.
 >
 > So I think it is useful to try to keep the build and signing VMs
 separate. Unfortunately this is not enough to avoid the case where an
 attacker uses their access to the build VM to produce malicious builds for
 nightly users. To mitigate this I think what we can do:
 > - reinstall the build VM frequently. Keeping build and signing VMs
 separate means we don't have to rotate mar signing and ssh keys at the
 same time.
 > - require all commits (or at least the top commit on the master branch)
 to be signed
 > - have a second build VM, and check that the builds are matching before
 signing them.

 Thanks for writing this up, really appreciated. Yes, the last three steps
 are good things to do. Could you open bugs for the last two (signed
 commits which we probably should enforce with a git hook and some means on
 the nightly side to only start building if commits are properly signed;
 and the second build VM) items so we don't forget about them?

 Unfortunately, I fear the issue with mar signing tools breaking will
 happen in situations where we need that least, that is during transition
 to a new major release once we do our first nightly builds with the new
 code. In that moment we do not want to deal with broken mar signing tools,
 too, so that the whole team is blocked on that. So, how about the
 following:

 a) We do use a hardcoded martools version as you propose, but

 b) if that fails, e.g. due to a new major upcoming release, we use the
 martools that gets shipped with the nightly so that other folks on the
 team can work on that new upcoming major release while someone from the
 team fixes the mar signing issue (the former do not get blocked anymore on
 the latter) (we can then rotate the signing key afterwards and set the VMs
 newly up to be on the safe side).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25102#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online