Closed Bug 1774221 Opened 6 months ago Closed 6 months ago

Ship a dummy openh264 update that has a signed dylib to work around the quarantine attribute

Categories

(Release Engineering :: Release Automation: Signing, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jrmuizel, Assigned: aki)

References

Details

Attachments

(7 files, 1 obsolete file)

Bug 1746675 broke the removal of the quarantine attribute which breaks loading OpenH264. Widevine still works despite having the quarantine attribute presumably because it is signed.

It looks bug 1689232 added signing for the mac ARM builds so hopefully it's not too hard to do the same for x86-64 builds.

Severity: -- → S2
Priority: -- → P1
See Also: → 1773207
Component: Audio/Video: GMP → Release Automation: Signing
Product: Core → Release Engineering
QA Contact: aki

Aki, what needs to be done to move this forward?

Flags: needinfo?(aki)
See Also: → 1587537
Attached file adhoc-signing
Assignee: nobody → aki
Flags: needinfo?(aki)
Attached file signed.zip (obsolete) —

We can test this. If it works, we may want to change the version in the .info file to 1.8.1.2, not sure.

Catalin, can you take a look at the signed.zip to see if it helps?

Flags: needinfo?(catalin.sasca)

The signed dylib still fails library validation for me.
code signature in (/Users/jrmuizel/source/gecko-inbound/obj-opt/tmp/profile-default/gmp-gmpopenh264/1.8.1.2/libgmpopenh264.dylib) not valid for use in process using Library Validation: library load disallowed by system policy

It's not at all clear to me why widevine succeeds and openh264 fails.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)

The signed dylib still fails library validation for me.
code signature in (/Users/jrmuizel/source/gecko-inbound/obj-opt/tmp/profile-default/gmp-gmpopenh264/1.8.1.2/libgmpopenh264.dylib) not valid for use in process using Library Validation: library load disallowed by system policy

It's not at all clear to me why widevine succeeds and openh264 fails.

It looks like the problem is we are not signing the arm64 and comment 3 signed.zip file version of libgmpopenh264.dylib with the right authority chain. They are signed using our "Authority=Mozilla Fake DMG Cert". The codesign -dvvv output doesn't include the developer ID authority or Apple Root CA. I assume it should have

Authority=Developer ID Certification Authority
Authority=Apple Root CA

If that is the problem, it explains what we're seeing. Apple's policy for a quarantined codesigned dylib per the 2019 WWDC presentation[1] regarding user approval is "Users must approve software in bundles" which is probably meant to apply to whole .apps and not standalone shared libraries (like we have in the profile.)

  1. https://developer.apple.com/videos/play/wwdc2019/701

The Terminal.app icon in the slide represents dlopen'd code as well as some other methods of executing code that were not previously affected by Gatekeeper.

Sure thing, tried accessing the terminal and libgmopenh264 throws the same error (identity of the developer cannot be confirmed. Please let me know if I can help with anything.

Flags: needinfo?(catalin.sasca)

Haik, the ARM64 dylib does have Authority=Mozilla Fake DMG Cert but running codesign -dvvv on the dylib in the comment 3 signed.zip gives:

Authority=Developer ID Application: Mozilla Corporation (43AQ936H96)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)

Haik, the ARM64 dylib does have Authority=Mozilla Fake DMG Cert but running codesign -dvvv on the dylib in the comment 3 signed.zip gives:

Authority=Developer ID Application: Mozilla Corporation (43AQ936H96)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

Sorry, yes I do see Apple's authority on the zip like you.

On 1.8.1.1 that is getting downloaded when I create a new profile on arm64, they're signed without the Apple authorities according to codesign output.

It also appears the Widevine dylib is notarized, but libgmpopenh264.dylib is not.

Guangwei, Hank, we have two new signed and notarized openh264 zipfiles attached in comment 11 and comment 12.

These are signed and notarized copies of http://ciscobinary.openh264.org/openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip
and http://ciscobinary.openh264.org/openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip, respectively.

Could we get these uploaded to ciscobinary.openh264.org? Once that happens we start serving them to Firefox users.
(We've had some turnover; are we missing any steps or process here?)

Flags: needinfo?(hankpeng)
Flags: needinfo?(guangwwa)

@Aki
I want to confirm 2 things.
first, these 2 old packages openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip and openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip should be deleted from the ciscobinary.openh264.org. and then upload the new(updated) package
in comment 11 and comment 12, is it right?

second, there is a .asc file (openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip.asc) in the cisco binary. I thinks this file should be kept. is it right?

Flags: needinfo?(guangwwa) → needinfo?(aki)

(In reply to GuangweiWang from comment #15)

@Aki
I want to confirm 2 things.
first, these 2 old packages openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip and openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip should be deleted from the ciscobinary.openh264.org. and then upload the new(updated) package
in comment 11 and comment 12, is it right?

Hm, to be safer, let's upload a new binary. Maybe openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip and openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip (note the -2)?

second, there is a .asc file (openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521.zip.asc) in the cisco binary. I thinks this file should be kept. is it right?

Ah, we probably gpg signed the zipfiles. I don't think we use this gpg signature from our side (we don't reference it in the balrog release, which is our update manifest) but we can create those to be safer.

Flags: needinfo?(aki)
Attachment #9281456 - Attachment filename: signed2-macx64.zip → openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip
Attachment #9281466 - Attachment filename: signed-notarized-mac-arm.zip → openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip
Attachment #9281456 - Attachment description: signed-notarized-macx64.zip → openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip
Attachment #9281466 - Attachment description: signed-notarized-mac-arm.zip → openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip

Guangwei: Can we get these four files uploaded? I've renamed them and added the .asc files.
Thank you!

Flags: needinfo?(guangwwa)

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #20)

Guangwei: Can we get these four files uploaded? I've renamed them and added the .asc files.
Thank you!

ok. will upload these 4 files.

another thing which is not related to this bug, you mentioned me and hank in the previous comment, hank is not working on this. can you help to remove his email to the list and add a new member?

Flags: needinfo?(guangwwa) → needinfo?(aki)

hi @Aki

these 4 files have been uploaded. please check.

Flags: needinfo?(aki)

The 1.8.1.2 blob is ready for testing on the nightlytest channel.

Flags: needinfo?(hankpeng)

(In reply to GuangweiWang from comment #22)

another thing which is not related to this bug, you mentioned me and hank in the previous comment, hank is not working on this. can you help to remove his email to the list and add a new member?

Yes, who should we add?

Flags: needinfo?(guangwwa)

1.8.1.2 is now available on nightly.

1.8.1.2 is now available in aurora(devedition) and beta.

Shipped to release and esr. RyanVM and I also cleaned up old rules, so everyone who was getting 1.8.1* should be getting 1.8.1.2 now.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Blocks: 1774709

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #25)

(In reply to GuangweiWang from comment #22)

another thing which is not related to this bug, you mentioned me and hank in the previous comment, hank is not working on this. can you help to remove his email to the list and add a new member?

Yes, who should we add?

please add Wayne Liu(huili2@cisco.com) to the list. thanks.

(In reply to GuangweiWang from comment #29)

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #25)

(In reply to GuangweiWang from comment #22)

another thing which is not related to this bug, you mentioned me and hank in the previous comment, hank is not working on this. can you help to remove his email to the list and add a new member?

Yes, who should we add?

please add Wayne Liu(huili2@cisco.com) to the list. thanks.

Done.

Flags: needinfo?(guangwwa)
You need to log in before you can comment on or make changes to this bug.