Differentiate between build and release sha256sums.txt
Windows users on our blog and elsewhere are being confused by the fact that the sha256sums for our exes don't match the downloaded files. This problem will probably get worse once we sign the Mac packages..
We might be able to communicate this to them indirectly by providing two sets of sha256sums.txt files: build-sha256sums.txt and release-sha256sums.txt. Or maybe build-sha256sums.txt and sha256sums.txt...
Activity
I am not convinced yet that we should add another SHA256 sums file containing the checksums of the bundles we release for a couple of reasons (hopefully combined they are stronger than the "but users are doing it this way"-argument :) ).
First, adding another checksums file is not reproducible builds related but only for two scenarios: a) A user just downloads the additional SHA256 sums file and checks a bundle downloaded before (or obtained otherwise) b) A user downloads the additional SHA256 sums file and its signature, checks the signature and uses then the checksum to check a bundle downloadable before (or obtained otherwise)
Now, I think we don't want to support a) as this actually reduces the security compared to things we recommend: that users are checking the signature of the bundle they download and use the advanced verification method if they don't trust a single signature. Just downloading the SHA256 sums and checking a bundle does actually not provide more security than HTTPS. I don't know much about verification of Tor Browser on Windows but could imagine that checking the hash is kind of a shortcut due to the hassle involved with GPG on Windows but maybe I am wrong here.
What about scenario b)? If users are already checking the signature then using the SHA256 sum in addition does not buy them anything security-wise I think.
So given a) I am worried that we are actually harming our efforts to provide instructions to get Tor Browser in a secure way. But even if we don't and all the users who are confused by the checksum mismatch are belonging into group b) then we might create some confusion by providing different checksum files. I envision users that download the wrong one or confuse both with each other making the whole process of getting Tor Browser in a secure way even more cumbersome leading, at the end, to resignation.
And, note, there are a bunch of user, I think, that are just curious why the sums are not matching and not demanding that we should provide additional sums. They might have been used to that method and might easily adapt to the new situation.
So I think we should proceed with our two clear messages:
- You should verify your Tor Browser's signature.
- If you don't trust your Tor Browser's signature follow the advanced verification path (warning: there be dragons)
I could think about renaming the sha256sums.txt into "sha256sums-build.txt" if that helps, though. It might make it clearer to users what these hashes are actually for then.
Ok. How about sha256sums-presigned-build.txt? And should we just make this a step in our release process, or should we update the actual build scripts? At this point, I am thinking that the release process update is OK, but what about later?
I also think tor-browser-launcher expects sha256sums.txt to exist. We should check with them to make sure they can handle the switch.
-
Replying to mikeperry:
Ok. How about sha256sums-presigned-build.txt? And should we just make this a step in our release process, or should we update the actual build scripts? At this point, I am thinking that the release process update is OK, but what about later?
I think I am fine with any fancy additions to "sha256sums-" if they are getting our message to the users. I think we should aim at updating the actual build scripts in order to avoid adding another thing we need to do manually to the release notes. Having a release process update as a stopgap is okay.
I also think tor-browser-launcher expects sha256sums.txt to exist. We should check with them to make sure they can handle the switch.
Yes, definitely.
Deprecation of sha256sums files is bad. Breaks Tor Browser downloaders such as torbrowser-launcher and worsens security.
sha256sum files helped to authenticate filenames... Because...
GPG signatures do not authenticate filenames: #2340 (moved)
-
We went with -unsigned-build.txt. No existing automatic downloaders were broken by this change, as we provide redirects for those URLs. We've updated the user documentation for advanced users to remove the Windows signatures if they wish to verify against the build hashes.
I'm inclined to call this solved, though we still need to bake in the new filenames into the build process, and script the addition of .htaccess.
I'm not especially motived by the filename authentication issue to special case a whole new set of post-signature shasum files just to deal with that.
Trac:
Keywords: TorBrowserTeam201505 deleted, TorBrowserTeam201506 added mentioned in issue #17511 (moved)
mentioned in issue tpo/applications/tor-browser#17511 (closed)
