Mac OS: meek-http-helper profile not updated

After the changes from #13252 (moved) and related tickets were merged, on Mac OS a template is used to create the meek-http-helper browser profile. Unfortunately, the meek-client-torbrowser code that Kathy and I wrote to copy files does not account for the fact that files within the template may change during a Tor Browser update (it only copies files if the profile.meek-http-helper directory does not exist).

added TorBrowserTeam201605 component::circumvention/meek ff45-esr owner::mcs priority::medium resolution::fixed severity::normal status::closed tbb-6.0-must type::defect labels

I do not think we should wait for a fix for this before releasing TB 6.0a5, especially since it will require changes to the meek-client-torbrowser code which is part of meek.

Dragging into May to have it on our 6.0 radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201605 added

Trac:
Owner: tbb-team to mcs
Status: new to assigned

Kathy and I have been thinking about how best to handle this. We need some kind of "versioning" for the meek-http-helper browser profile, but we would rather not add a manual maintenance step to the release process (e.g., "If any of the files that will be part of the meek-http-helper browser profile have changed since the last release, change the contents of meek-profile-version.txt").

gk, dcf: What do you think of the idea of generating a checksum and storing that in a file? Here is how it could work:

1. During the Tor Browser gitian-based bundling step, we would generate a checksum that uniquely identifies the contents of the meek-http-helper profile template and place it in the template, e.g., as meek-profile-sha256sum.txt. We could do this by creating a sorted sha256sums file and then calculating a checksum of that file.
2. The meek-client-torbrowser code would compare the contents of the meek-profile-sha256sum.txt that is part of the browser bundle (the template) with the profile that is in use (the user's copy). If the contents are different, the meek-client-torbrowser code would remove the entire profile and create a new one from the template.

Comments?

Trac:
Status: assigned to needs_information

To recap: the problem exists because the updater is not reaching that part anymore and thus, there is no way to get a newer meek extension and prefs file to the user, right?

While thinking about your solution it occurred to me that the profile would get overwritten every time the user had chosen to use meek because that causes the profile dir getting used and thus the checksum is not matching anymore. Is that intended?

Is there a way to get the Tor Browser version from meek-client-torbrowser code? Probably, I guess. Couldn't we force-update the profile dir instead in case a new Tor Browser version got installed?

Replying to gk:

To recap: the problem exists because the updater is not reaching that part anymore and thus, there is no way to get a newer meek extension and prefs file to the user, right?

Right. On Mac OS, the meek-client-torbrowser program now creates the meek-http-helper profile by copying everything in a template directory. But it only knows to do that if the destination profile directory does not exist at all.

While thinking about your solution it occurred to me that the profile would get overwritten every time the user had chosen to use meek because that causes the profile dir getting used and thus the checksum is not matching anymore. Is that intended?

Actually, we are not planning to generate a checksum based on the files that are on the user's computer. Our idea is to generate a checksum once when we build Tor Browser and then use the checksum file as a kind of version to indicate that the meek-http-helper profile was created from a different template (that is, from a different version of Tor Browser). That way the profile will only be removed and recreated when the template files are modified.

Is there a way to get the Tor Browser version from meek-client-torbrowser code? Probably, I guess. Couldn't we force-update the profile dir instead in case a new Tor Browser version got installed?

We could try to get the version number and store it in a file. But I am not sure how the meek-client-torbrowser code could easily get the version number. The checksum file we propose would serve as an automatically generated version number, but we could instead store the Tor Browser version number in a similar way, e.g., in a file named tor-browser-version.txt within the meek-http-helper profile. And that file could be created at build/bundling time. Using a hash of the meek files would be slightly more efficient since the meek-http-helper files (extension plus user.js) do not change with every Tor Browser release.

Okay, I think I understand your proposal now, thanks. Sounds good to me.

Trac:
0001-Bug-18904-Mac-OS-meek-http-helper-profile-not-update.patch

meek patch

I just attached the meek part of the fix to this ticket. The other part is here: https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/commit/?h=bug18904-01&id=495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7

Please review both patches.

Trac:
Status: needs_information to needs_review
Keywords: TorBrowserTeam201605 deleted, TorBrowserTeam201605R added

The tor-browser-bundle one looks good to me and is applied to master (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek part and create a new tag we can use?

Trac:
Keywords: TorBrowserTeam201605R deleted, TorBrowserTeam201605 added
Component: Applications/Tor Browser to Obfuscation/meek

Replying to gk:

The tor-browser-bundle one looks good to me and is applied to master (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek part and create a new tag we can use?

Yes but probably not until tomorrow.

Trac:
Keywords: N/A deleted, tbb-6.0-must added

Replying to dcf:

Replying to gk:

The tor-browser-bundle one looks good to me and is applied to master (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek part and create a new tag we can use?

Yes but probably not until tomorrow.

Ok. Just to give you some timeframe for planning: my current plan is to start the building for 6.0 next Tuesday, May 24, probably evening Europe time.

Replying to gk:

The tor-browser-bundle one looks good to me and is applied to master (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek part and create a new tag we can use?

Here is a tag 0.22-18371-3.

I suppose after the next stable release, we can merge the bug18371 branch into master, because the old behavior will no longer be needed.

Replying to dcf:

Replying to gk:

The tor-browser-bundle one looks good to me and is applied to master (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek part and create a new tag we can use?

Here is a tag 0.22-18371-3.

I suppose after the next stable release, we can merge the bug18371 branch into master, because the old behavior will no longer be needed.

Thanks, yes, merging that into master after the next stable sounds good.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

mentioned in issue #29347 (moved)

moved to tpo/anti-censorship/pluggable-transports/meek#18904 (closed)