Make sure our updates are dealing with SSE requirement properly

https://bugzilla.mozilla.org/show_bug.cgi?id=1271761 landed on ESR45 and it is very likely that Firefox won't work on machines without SSE support anymore in the next ESR (52). We should make sure we handle this properly with our updater. We want to be sure users without SSE support won't get an update then, for instance.

added TorBrowserTeam201704R component::applications/tor browser ff52-esr owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-7.0-must-alpha type::task labels

Similar to the minSupportedOSVersion update manifest attribute that we added for the Mac OS 10.6 issue (see https://trac.torproject.org/projects/tor/ticket/13047#comment:3), we should add support for a new attribute such as: minInstructionSet="SSE2"

We want to be sure users without SSE support won't get an update then, for instance.

Should they get a large clearly visible warning that their platform won't be supported for much longer? (In browser UI ideally since enough people probably don't read the release notes).

Anyone using something that doesn't support SSE2 is guaranteed to be on 32 bit Windows or Linux, and if we ever need to do it, detecting SSE2 support is trivial (CPUID with EAX set to 1, look at bit 26)...

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

Getting those tickets on our March radar as well.

Trac:
Keywords: N/A deleted, TorBrowserTeam201703 added

Are you sure want to make Tor Browser phoning home about CPU features?

Replying to cypherpunks:

Are you sure want to make Tor Browser phoning home about CPU features?

If we add an update manifest attribute similar to minSupportedOSVersion (as suggested by mcs), we are not phoning home with the CPU features, but checking locally that the feature is available.

Trac:
0001-fixup-Bug-4234-Use-the-Firefox-Update-Process-for-To.patch

Replying to mcs:

Similar to the minSupportedOSVersion update manifest attribute that we added for the Mac OS 10.6 issue (see https://trac.torproject.org/projects/tor/ticket/13047#comment:3), we should add support for a new attribute such as: minInstructionSet="SSE2"

I attached a first version of a patch to do that, but I did not test it yet, so it may not work.

I think there will still be an issue with people upgrading to the new ESR52 version from Tor Browser <= 6.5.1 (skipping the version that added support for the minInstructionSet attribute), as their browser will not know this attribute. If we want to avoid this, we will need to change the update_2 from the updates URL to update_3 (similar to what we did in #13047 (moved)).

Replying to boklm:

Replying to mcs:

Similar to the minSupportedOSVersion update manifest attribute that we added for the Mac OS 10.6 issue (see https://trac.torproject.org/projects/tor/ticket/13047#comment:3), we should add support for a new attribute such as: minInstructionSet="SSE2"

I attached a first version of a patch to do that, but I did not test it yet, so it may not work.

I think there will still be an issue with people upgrading to the new ESR52 version from Tor Browser <= 6.5.1 (skipping the version that added support for the minInstructionSet attribute), as their browser will not know this attribute. If we want to avoid this, we will need to change the update_2 from the updates URL to update_3 (similar to what we did in #13047 (moved)).

The plan sounds good to me. I think we should be less strict here, though: it seems SSE2 is only required for Windows builds with ESR 52. The Linux bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 which will land in Firefox 53. I am not sure about OS X. The tracking bug for the update on Mozilla's side is: https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 and there is a way to detect SSE2 support for Linux using UpdateUtils code included in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1277359.

Trac:
Status: new to needs_revision

It seems like all macOS Intel machines are SSE2 capable, so we are fine in that regard.

Replying to boklm:

Replying to mcs:

Similar to the minSupportedOSVersion update manifest attribute that we added for the Mac OS 10.6 issue (see https://trac.torproject.org/projects/tor/ticket/13047#comment:3), we should add support for a new attribute such as: minInstructionSet="SSE2"

I attached a first version of a patch to do that, but I did not test it yet, so it may not work.

It seems like we just need one attribute in the update manifest, e.g., minSupportedInstructionSet.

Also, I think your patch is missing a !. Maybe just do something like:

if (!this.unsupported && update.hasAttribute("minSupportedInstructionSet")) {
  let minInstructionSet = update.getAttribute("minSupportedInstructionSet");
  if (['MMX', 'SSE', 'SSE2', 'SSE3',
       'SSE4A', 'SSE4_1', 'SSE4_2'].indexOf(minInstructionSet) >= 0) {
  try {
    this.unsupported = !Services.sysinfo.getProperty("has" + minInstructionSet);
  } catch (e) {}
}

(untested).

I think there will still be an issue with people upgrading to the new ESR52 version from Tor Browser <= 6.5.1 (skipping the version that added support for the minInstructionSet attribute), as their browser will not know this attribute. If we want to avoid this, we will need to change the update_2 from the updates URL to update_3 (similar to what we did in #13047 (moved)).

Do we really need to change to update3? We are not changing the request URL. We should add support for the new instruction set attribute to TB 6.5.2 and then advertise to older Windows browsers an update to 6.5.2. Then, after that update is done, the 6.5.2 browser will recognize the new attribute and make the appropriate instruction set check. Mozilla does this kind of thing once in a while; they call it a step-wise update or flag day or something ;)

Replying to mcs:

Replying to boklm:

Replying to mcs:

Similar to the minSupportedOSVersion update manifest attribute that we added for the Mac OS 10.6 issue (see https://trac.torproject.org/projects/tor/ticket/13047#comment:3), we should add support for a new attribute such as: minInstructionSet="SSE2"

I attached a first version of a patch to do that, but I did not test it yet, so it may not work.

It seems like we just need one attribute in the update manifest, e.g., minSupportedInstructionSet.

Also, I think your patch is missing a !. Maybe just do something like: {{{ if (!this.unsupported && update.hasAttribute("minSupportedInstructionSet")) { let minInstructionSet = update.getAttribute("minSupportedInstructionSet"); if (['MMX', 'SSE', 'SSE2', 'SSE3', 'SSE4A', 'SSE4_1', 'SSE4_2'].indexOf(minInstructionSet) >= 0) { try { this.unsupported = !Services.sysinfo.getProperty("has" + minInstructionSet); } catch (e) {} } }}}

(untested).

This looks better, thanks.

I think there will still be an issue with people upgrading to the new ESR52 version from Tor Browser <= 6.5.1 (skipping the version that added support for the minInstructionSet attribute), as their browser will not know this attribute. If we want to avoid this, we will need to change the update_2 from the updates URL to update_3 (similar to what we did in #13047 (moved)).

Do we really need to change to update3? We are not changing the request URL. We should add support for the new instruction set attribute to TB 6.5.2 and then advertise to older Windows browsers an update to 6.5.2. Then, after that update is done, the 6.5.2 browser will recognize the new attribute and make the appropriate instruction set check. Mozilla does this kind of thing once in a while; they call it a step-wise update or flag day or something ;)

I think we have no easy way to continue advertising 6.5.2 to older Windows browsers after 7.0 is released, with what we use to generate the update responses files. We can add support for that, but it will probably require keeping a copy of the 6.5.2 mar files when generating update response files for many of the future releases. I think an easier way to do that is changing the update url to update_3 in 6.5.2, and not advertising 7.0 in update_2. We can also add update_2 -> update_3 redirects for the Linux and OSX URLs so that Linux and OSX browsers are updated to the latest version directly.

Trac:
0001-fixup-Bug-4234-Use-the-Firefox-Update-Process-for-To-v2.patch

I made a build with version 2 of the patch: https://people.torproject.org/~boklm/builds/bug19316/

I did not yet find a computer without SSE3 (or how to emulate one) to test it.

Moving tickets over to April

Trac:
Keywords: TorBrowserTeam201703 deleted, TorBrowserTeam201704 added

Getting this on our radar for alpha release in less than two weeks.

Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added

It seems to me there is still a patch for the client side missing for this bug?

Trac:
Status: needs_revision to needs_information

Replying to boklm:

I made a build with version 2 of the patch: https://people.torproject.org/~boklm/builds/bug19316/

I did not yet find a computer without SSE3 (or how to emulate one) to test it.

I have no computer without SSE2 support (and could not find how to emulate one), so I tested with SSE4A (which is not supported on my computer since it seems to be AMD only).

If I set this url as app.update.url.override: https://people.torproject.org/~boklm/bug19316/SSE4A.xml Then the update is not started, with a message saying "You Tor Browser is out of date, but the latest version is not supported on your system".

If I set this url as app.update.url.override: https://people.torproject.org/~boklm/bug19316/SSE2.xml Then the updating process is starting.

So the patch seems to be working as expected.

Trac:
Status: needs_information to needs_review

Trac:
Keywords: TorBrowserTeam201704 deleted, TorBrowserTeam201704R added