Spinoff of conversation in bug 322206.

I suggest reading this paper from CCS2010: http://freehaven.net/~arma/tuf-ccs2010.pdf Additionally: https://www.updateframework.com/wiki/About https://www.updateframework.com/browser/specs/tuf-spec.txt Here is a python implementation which much of the work references or uses: https://gitweb.torproject.org/thandy.git

The vast majority of documentation is in regards to updating software. bug 322206 and this bug are about installing software. Can you provide links to TUF documentation or sections of the documentation regarding installing software? Thanks.

Yes, that's correct. What is an update? An update is an install of some components that happens after you already have an installed set of files. If a user manages to get a good installer to begin with, Thandy/TUF tries to ensure that the user doesn't go belly up, even in the event of a key compromise. In any case - here's a specific blurb about install: https://gitweb.torproject.org/thandy.git/blob/HEAD:/specs/thandy-spec.txt#l82 https://gitweb.torproject.org/thandy.git/blob/HEAD:/specs/thandy-spec.txt#l119 Practical guide for hackers: https://gitweb.torproject.org/thandy.git/blob/HEAD:/doc/HOWTO In an ideal world, we'd have a TUF/Thandy stub and it would then be ready to install any of the components required by MoCo. Thus, the stub can be very small and now you have a root of trust for all other components. Thandy then will protect you against the issues covered in the CCS2010 paper, etc.

So, they already do all the stuff required of an installer such as dealing with files in use, registry settings etc.? It is clear from the docs that it is update specific and it doesn't seem to fit the bill as an installer.

For example, they specify that the files to install could be an MSI and the MSI *IS* an installer. TUF is not an installer and needs to be installed first for it to be useful. It is well outside of the scope of the stub installer. For example, with what we are trying to accomplish with the stub installer we would need to implement it to install TUF if we were to go with TUF.

(In reply to Robert Strong [:rstrong] (do not email) from comment #4) > So, they already do all the stuff required of an installer such as dealing > with files in use, registry settings etc.? It is clear from the docs that it > is update specific and it doesn't seem to fit the bill as an installer. At some point, I believe there was an MSI or something similar on Windows of Thandy code - I don't recall the current state of that. It seems that there are requirements that you have but have not listed in this bug. I am primarily concerned that the hard ones - the ones covered by TUF - will be left behind unless TUF/Thandy or something similar is used. If Thandy/TUF is missing say, an MSI installer - what's easier to build? An MSI installer for TUF or an a TUF for an MSI enabled installer?

(In reply to Robert Strong [:rstrong] (do not email) from comment #5) > For example, they specify that the files to install could be an MSI and the > MSI *IS* an installer. Yes, that's perfectly reasonable. If you have a bundle and it is for say, Thunderbird, you'd want to ensure that you used the Thunderbird MSI and that you get the freshest one, etc. > TUF is not an installer and needs to be installed > first for it to be useful. It is well outside of the scope of the stub > installer. For example, with what we are trying to accomplish with the stub > installer we would need to implement it to install TUF if we were to go with > TUF. It's a chicken/egg problem. However, the reason you're going for a stub installer is to improve security - this includes all of the issues that TUF covers, right? It should, I think. With that said, I think that a quick signed MSI installer of TUF gets you basically everything that you need. I've asked one of the Thandy authors to comment here because I do not know the state of Thandy's Windows installer.

note: the reason we are going with a stub installer is to lessen the initial download time so the UI is shown to the user sooner. The current plan is to do what most (perhaps all?) other stub installers do today. Also part of the current plan is we will host the signed stub on one of our web properties that only allows SSL and have it download the signed core files from a mirror site. This download will be verified. We will also use the stub to report problems with the download from any of the mirrors since they can sometime be problematic.

This would be a huge amount of work across a number of teams to implement, so the security benefit has quite a hill to climb in order to become worth the cost, but it does bear at least looking into.