Bug 1774221 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(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 using the "Authority=Mozilla Fake DMG Cert"  authority only. 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](https://developer.apple.com/videos/play/wwdc2019/701)[1] regarding user approval is "Users must approve software in bundles" which is probably meant to apply to whole .apps and not shared libraries. (Although in this case the shared library is within a .app bundle, but we don't see this issue with Widevine which does have the Apple authorities.)

1. https://developer.apple.com/videos/play/wwdc2019/701
(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 using the "Authority=Mozilla Fake DMG Cert"  authority only. 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](https://developer.apple.com/videos/play/wwdc2019/701)[1] regarding user approval is "Users must approve software in bundles" which is probably meant to apply to whole .apps and not shared libraries.

1. https://developer.apple.com/videos/play/wwdc2019/701
(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 using the "Authority=Mozilla Fake DMG Cert"  authority only. 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](https://developer.apple.com/videos/play/wwdc2019/701)[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
(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](https://developer.apple.com/videos/play/wwdc2019/701)[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

Back to Bug 1774221 Comment 6