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

Status: RESOLVED FIXED

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

Description

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

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

Comment 2

[Aki Sasaki (not active)]

Attachment: adhoc-signing

Comment 3

[Aki Sasaki (not active)]

Attachment: signed.zip

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.

Comment 4

[Aki Sasaki (not active)]

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

Comment 5

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 6

[Haik Aftandilian [:haik]]

(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

Comment 7

[Haik Aftandilian [:haik]]

Attachment: Slide 39 from WWDC 2019 Advances in macOS Security

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.

Comment 8

[Catalin Sasca, Desktop QA [:csasca]]

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.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

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

Comment 10

[Haik Aftandilian [:haik]]

(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.

Comment 11

[Aki Sasaki (not active)]

Attachment: openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip

Comment 12

[Aki Sasaki (not active)]

Attachment: openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip

Comment 13

[Aki Sasaki (not active)]

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?)

Comment 15

[GuangweiWang]

@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?

Comment 16

[Aki Sasaki (not active)]

(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.

Comment 17

[Aki Sasaki (not active)]

Attachment: adhoc-signing PR: gpg sign the zipfiles

Comment 18

[Aki Sasaki (not active)]

Attachment: openh264-macosx64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip.asc

Comment 19

[Aki Sasaki (not active)]

Attachment: openh264-macosx64-aarch64-2e1774ab6dc6c43debb0b5b628bdf122a391d521-2.zip.asc

Comment 20

[Aki Sasaki (not active)]

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

Comment 21

[GuangweiWang]

(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.

Comment 22

[GuangweiWang]

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?

Comment 23

[GuangweiWang]

hi @Aki

these 4 files have been uploaded. please check.

Comment 24

[Julien Cristau [:jcristau]]

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

Comment 25

[Aki Sasaki (not active)]

(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?

Comment 26

[Julien Cristau [:jcristau]]

1.8.1.2 is now available on nightly.

Comment 27

[Aki Sasaki (not active)]

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

Comment 28

[Aki Sasaki (not active)]

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.

Comment 29

[GuangweiWang]

(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([e-mail]) to the list. thanks.

Comment 30

[Aki Sasaki (not active)]

(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([e-mail]) to the list. thanks.

Done.