Closed Bug 1689232 Opened 4 years ago Closed 4 years ago

The openH264 plugin cannot run on Apple Silicon without signing

Categories

(Release Engineering :: Release Automation: Signing, defect)

ARM64
macOS
defect

Tracking

(firefox87 fixed)

RESOLVED FIXED
Tracking Status
firefox87 --- fixed

People

(Reporter: mjf, Assigned: mozilla)

Details

Attachments

(4 files, 1 obsolete file)

The signing job for macos64-aarch64 is not signing the plugin library. If the artifact is downloaded, running codesign -dvvv <file. returns code object is not signed at all.

After a conversation with @aki today, he suggests:
It looks like that task is using our linux signing scriptworkers, which use signingscript https://github.com/mozilla-releng/scriptworker-scripts/tree/master/signingscript

Our mac signers use iscript. https://github.com/mozilla-releng/scriptworker-scripts/tree/master/iscript

We may need to add support for signing openh264 in iscript, and send the mac aarch signing tasks there instead of the linux signing scriptworkers.

I manually signed a copy of this yesterday; I'm happy to send it over if that's an OK interim solution. Obviously we need to fix the signing in Taskcluster, too, though.

I think it probably needs to be from an "official" build before I'm comfortable with having it hosted for download.

(In reply to Michael Froman [:mjf] from comment #2)

I think it probably needs to be from an "official" build before I'm comfortable with having it hosted for download.

OK, how soon does this need to be done?

From Nils (on PTO at the moment):
"I would answer in the next few days would be nice as the OpenH264 issue affects Release users. And folks on Twitter have noticed."

I checked in with Nils: we don't have H264 hardware encoding support on Mac so this should mean that making WebRTC calls is probably broken in many use cases on the M1.

Attached file Bug 1689232 - sign mac openh264 on mac (obsolete) —
Attachment #9199963 - Attachment is obsolete: true

Needs testing. I'm thinking:

  • push to maple
  • create all the openh264 signing tasks
  • test the mac signing task locally on a quarantined mac, adjust the iscript patchset
  • switch the quarantined mac to a different workerType
  • switch maple to the different workerType
  • test geckodriver signing + openh264 signing to make sure it works
  • create a ronin-puppet patch (this will need the revision from scriptworker-scripts post-merge before merging)
  • reviews
  • land, roll out

I could skip some of the manual testing in favor of creating the alternate workerType sooner.

Assignee: nobody → aki
Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/ci/ci-configuration/rev/9504777ce85a
add private/openh264 scopes to mac signers. r=releng-reviewers,bhearsum
Keywords: leave-open
Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/292d5c030eff
sign mac openh264 on mac r=bhearsum

Rolled out to all mac signers except 1,2,11, which are all quarantined (using 11 for bug 1689376 testing).
Once we merge from autoland to central we should be able to mark this reso fixed.

Keywords: leave-open
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Backed out on suspicion of cause macOS startup crashes (bug 1689807)

Backout: https://hg.mozilla.org/mozilla-central/rev/b8f3561e20d9abe1202ca4d74ec5d7ca5d6ebd9d

Status: RESOLVED → REOPENED
Flags: needinfo?(aki)
Resolution: FIXED → ---

Aki, please confirm that nothing needs to be reverted in ci-config (sheriffs don't have access to it, FYI).

Narrowed it down to https://github.com/mozilla-releng/scriptworker-scripts/commit/176c04e46688841f5c844720bbf07912f800fd32. Notes here. The gecko backout didn't do anything, but I can reland directly on Central when we resolve the iscript problem.

Because the question got asked: Can you link to the commit or mention the deployment which fixed it, please?

No commit, manual deploy.

Flags: needinfo?(aki)
Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2e94cc710273
sign mac openh264 on mac r=bhearsum DONTBUILD

Once this merges, we should be able to trigger openh264 signing tasks on central.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

:mjf, do you want to trigger new openh264 signing tasks on central? want me to? (or do we do this on a different repo?)

Flags: needinfo?(mfroman)

I'll do it, and pull it down and try it here.

Flags: needinfo?(mfroman)

Ok - I finally got through all the testing issues and here is what I've learned:

  1. The signing of the library works and survives the test download process.
  2. However, the output of the new signing process, a .tar.gz file, will not work. Our GMPExtractor code requires a .zip file.
  3. The new .tar.gz file only contains the signed library file, but must also contain the gmpopenh264.info file.

So to recap, what we need is for the output of the signing job to be a zip file (as it was originally), containing 2 files:
gmpopenh264.info
and the signed version of libgmpopenh264.dylib

Please let me know if you need any other info. The testing process should go much quicker on the next try!
Thank you!

Status: RESOLVED → REOPENED
Flags: needinfo?(aki)
Resolution: FIXED → ---
Flags: needinfo?(aki)

Rolled out.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

This new zip file works great - thank you!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: