Closed Bug 1587537 Opened 5 years ago Closed 5 years ago

Create rule to serve dummy 1.8.1.1 OpenH264 version to ensure quarantine attribute is cleared on MacOS

Categories

(Release Engineering :: Release Requests, task)

Product:
Release Engineering
Component:
Release Requests
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bryce, Assigned: jlund)

References

Details

Per bug 1587533:

This is a suggested way to mitigate bug 1587421 per my comment there.

If we downloaded openh264 before bug 1566523 landed then we won't have cleared the quarantine attribute on the file and this will cause issues for MacOS Catalina users. To mitigate this we could ensure that versions of Firefox that have the changes from bug 1566523 redownload the plugin by having a dummy version.

This would mean updating our balrog rules as well as the fallback downloader for affected versions.

Could we please create a rule that will is essentially the same as our existing 1.8.1 rule, but with the version changed to 1.8.1.1? I.e. has the same binaries, with the same hashes.

Could we then stage the rule for nighttest for Firefox 70.0a1 and above to so that we can test that this mitigates bug 1587421?

Assignee: nobody → bhearsum

I set this up on nightlytest: https://aus5.mozilla.org/update/3/GMP/67.0/20180323154952/Darwin_x86_64-gcc3/en-US/nightlytest/Darwin%2015.6.2/default/default/update.xml

Let me know if things look good and we can carry it over to all of the live channels.

Flags: needinfo?(bvandyk)

Haik, I'd appreciate your help testing this when you have time.

Flags: needinfo?(bvandyk) → needinfo?(haftandilian)

Whoops, wasn't supposed to redirect my NI on that last comment, anywho.

I've just checked now and this appears to work when testing on my machine. I don't have Catalina, but was able to go from version 1.8.1 with the quarantine attribute to 1.8.1.1 without the attribute. This suggests that the following important things happen:

  • Having a new version triggers the GMP downloader to fetch it.
  • The downloading machinery clears the quarantine attribute on the new download as expected.

I'd like for Haik to have a look at this, given the strength of his Mac-fu. Not sure if he's on PTO.

I'll see where we've gotten to tomorrow and we can go from there.

Could we target all platforms for the version change, rather than just Mac? While the bug we're targeting is Mac specific, keeping the same version on all platforms means that balrog and the fallback rules will be in step.

(In reply to Bryce Seager van Dyk (:bryce) from comment #4)

Could we target all platforms for the version change, rather than just Mac? While the bug we're targeting is Mac specific, keeping the same version on all platforms means that balrog and the fallback rules will be in step.

Just to be 100% clear: you want all platforms to receive 1.8.1.1? Not a problem if you do.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #5)

(In reply to Bryce Seager van Dyk (:bryce) from comment #4)

Could we target all platforms for the version change, rather than just Mac? While the bug we're targeting is Mac specific, keeping the same version on all platforms means that balrog and the fallback rules will be in step.

Just to be 100% clear: you want all platforms to receive 1.8.1.1? Not a problem if you do.

Yes, please.

(In reply to Bryce Seager van Dyk (:bryce) from comment #6)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #5)

(In reply to Bryce Seager van Dyk (:bryce) from comment #4)

Could we target all platforms for the version change, rather than just Mac? While the bug we're targeting is Mac specific, keeping the same version on all platforms means that balrog and the fallback rules will be in step.

Just to be 100% clear: you want all platforms to receive 1.8.1.1? Not a problem if you do.

Yes, please.

This is done. Eg: https://aus5.mozilla.org/update/3/GMP/67.0/20180323154952/Linux_x86_64-gcc3/en-US/nightlytest/Darwin%2015.6.2/default/default/update.xml

(In reply to Bryce Seager van Dyk (:bryce) from comment #2)

Haik, I'd appreciate your help testing this when you have time.

I was able to reproduce the problem and I clicked "Move to Trash". A few minutes later I noticed Nightly had downloaded a new version of the dylib and it had the com.apple.quarantine attribute deleted. I also hit several crashes during that time - https://crash-stats.mozilla.org/report/index/6ee02859-107b-4884-96aa-00a6e0191010

I the fix sounds like a good way to do it. We already bumped the version of Widevine and I didn't think to do that for H264. Alternatively, we could ship a fix in Firefox that clears the quarantine flag, but the 1.8.1.1 approach is very low risk.

I will do a test today with nightlytest to get 1.8.1.1 and validate that.

Flags: needinfo?(haftandilian)

-> tag

Assignee: bhearsum → jlund

(In reply to Haik Aftandilian [:haik] from comment #8)

I will do a test today with nightlytest to get 1.8.1.1 and validate that.

I was able to reproduce the bug and validate the fix. I used the original ESR60 release with updates disabled with a new profile. I used https://mozilla.github.io/webrtc-landing/pc_test.html to test WebRTC with "Require H.264 Video" checked. I checked in the profile and made sure the libgmpopenh264.dylib was downloaded. Once libgmpopenh264.dylib was downloaded, trying to use WebRTC triggered the problem.

Then I used Nightly on the same profile and hit the same problem (the dialog was displayed like in the description.) Then I changed Nightly to use the nightlytest update channel. Once the new libgmpopenh264.dylib was downloaded, the problem did not occur any more.

ESR60.0 (original release) doesn't have the fix for bug 1566523 so the download does not clear the quarantine attribute.

Could we update the existing rules to roll out the dummy update to 70.0a1+ on all channels?

Could we also setup a rule that servers the dummy update to ESR 68.2+? This will should mitigate the same issue for users on ESR.

Flags: needinfo?(jlund)

I believe Callek has taken this request. Let me know if there is still work outstanding for this ticket.

Flags: needinfo?(jlund)

Thanks to Ryan this should all be live now

Based on testing I think this has mitigated the issue as hope, so I'm going to resolve.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
See Also: → 1774221
You need to log in before you can comment on or make changes to this bug.