Opened 3 years ago

Closed 3 years ago

#15864 closed defect (fixed)

Differentiate between build and release sha256sums.txt

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-4.5-regression, tbb-usability, TorBrowserTeam201507R, GeorgKoppen201507R
Cc: mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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...

Child Tickets

Attachments (1)

0001-Bug-15864-rename-sha256sums.txt-to-sha256sums-unsign.patch (9.9 KB) - added by boklm 3 years ago.
Patch to use sha256sums-unsigned-build.txt everywhere

Download all attachments as: .zip

Change History (16)

comment:1 Changed 3 years ago by mcs

Cc: mcs added

Maybe we should choose names that will sort next to each other, e.g.,

sha256sums-build.txt
sha256sums-release.txt

And we should think about adding a sha256sums-readme.txt file that explains everything.

comment:2 Changed 3 years ago by gk

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:

1) You should verify your Tor Browser's signature.
2) 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.

comment:3 Changed 3 years ago by 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 also think tor-browser-launcher expects sha256sums.txt to exist. We should check with them to make sure they can handle the switch.

comment:4 in reply to:  3 Changed 3 years ago by gk

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.

comment:5 Changed 3 years ago by proper

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

comment:6 Changed 3 years ago by arma

(I'm cc'ing myself on the ticket since this is something that's been confusing users on the blog. I'm looking forward to some solutions! :)

comment:7 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201506 added; TorBrowserTeam201505 removed

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.

comment:8 Changed 3 years ago by mikeperry

Keywords: MikePerry201506 added
Owner: changed from tbb-team to mikeperry
Status: newassigned

comment:9 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201507 added; TorBrowserTeam201506 removed

Move over remaining June items to July

comment:10 Changed 3 years ago by mikeperry

Keywords: MikePerry201507 added; MikePerry201506 removed

Move my tickets over for July

Changed 3 years ago by boklm

Patch to use sha256sums-unsigned-build.txt everywhere

comment:11 Changed 3 years ago by boklm

Keywords: TorBrowserTeam201507R added; TorBrowserTeam201507 removed
Status: assignedneeds_review

comment:12 Changed 3 years ago by mikeperry

Keywords: MikePerry201507 removed

comment:13 Changed 3 years ago by gk

Keywords: GeorgKoppen201507R added

comment:14 Changed 3 years ago by gk

Status: needs_reviewassigned

Looks good to me, applied as commit 748c56459b1304207502754d8541c089edc4051a. Mike, could you update the release process document?

comment:15 Changed 3 years ago by mikeperry

Resolution: fixed
Status: assignedclosed

Release process updated.

Note: See TracTickets for help on using tickets.