#18904 closed defect (fixed)

Mac OS: meek-http-helper profile not updated

Reported by: mcs Owned by: mcs
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Normal Keywords: ff45-esr, TorBrowserTeam201605, tbb-6.0-must
Cc: brade, boklm, dcf, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

After the changes from #13252 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).

Child Tickets

Attachments (1)

0001-Bug-18904-Mac-OS-meek-http-helper-profile-not-update.patch (4.6 KB) - added by mcs 13 months ago.
meek patch

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 months ago by mcs

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.

comment:2 Changed 13 months ago by gk

  • Keywords TorBrowserTeam201605 added

Dragging into May to have it on our 6.0 radar.

comment:3 Changed 13 months ago by gk

  • Owner changed from tbb-team to mcs
  • Status changed from new to assigned

comment:4 Changed 13 months ago by mcs

  • Status changed from assigned to needs_information

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?

comment:5 follow-up: Changed 13 months ago by 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?

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?

comment:6 in reply to: ↑ 5 Changed 13 months ago by mcs

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.

comment:7 Changed 13 months ago by gk

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

comment:8 Changed 13 months ago by mcs

  • Keywords TorBrowserTeam201605R added; TorBrowserTeam201605 removed
  • Status changed from needs_information to needs_review

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.

comment:9 follow-ups: Changed 13 months ago by gk

  • Component changed from Applications/Tor Browser to Obfuscation/meek
  • Keywords TorBrowserTeam201605 added; TorBrowserTeam201605R removed

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?

comment:10 in reply to: ↑ 9 ; follow-up: Changed 13 months ago by 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.

comment:11 Changed 13 months ago by gk

  • Keywords tbb-6.0-must added

comment:12 in reply to: ↑ 10 Changed 12 months ago by gk

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.

comment:13 in reply to: ↑ 9 ; follow-up: Changed 12 months ago by 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.

comment:14 in reply to: ↑ 13 Changed 12 months ago by gk

  • Resolution set to fixed
  • Status changed from needs_review to closed

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.

Note: See TracTickets for help on using tickets.