Fail to load GMPs with a Win32 manifest

Assigned to



2 years ago
a month ago


(Reporter: cpearce, Assigned: cpearce)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



2 years ago
We have several times had CDMs that weren't loading on Windows under various situations where the root cause was that the CDM DLL contained a Win32 manifest, and that causes the sandbox to block loading it.

As such we don't want to ever accept a CDM/GMP update for a DLL that contains a Win32 manifest. I don't want to have to remember to check new CDM/OpenH264 updates for whether the DLL contains a manifest. So we should change our GMP loading code to explicitly check to see whether the DLL has a manifest, and log and then fail if so. Then we will detect the problem with the DLL when testing a new CDM/GMP update before pushing it out.

Comment 1

2 years ago
I'll upload a patch to detect this, but obviously we can't push it out until we've pushed out Widevine CDM update 970 which doesn't include a manifest!
Comment hidden (mozreview-request)
Rank: 15
Priority: -- → P1

Comment 3

a year ago
Comment on attachment 8877880 [details]
Bug 1373147 - Log and refuse to load GMP DLLs which contain Win32 manifests. ?bobowen

Bob: Are you able to review this? Mozreview seems to be swallowing my review.
Attachment #8877880 - Flags: review?(bobowencode)

Comment 4

a year ago
Comment on attachment 8877880 [details]
Bug 1373147 - Log and refuse to load GMP DLLs which contain Win32 manifests. ?bobowen

This feels like a bit of overkill to be checking this everytime everybody loads these, to catch things up front.
Wouldn't it make more sense to have some stand-alone validator or perhaps as part of an upload process.

If we're really against that maybe it could be Nightly only.
Attachment #8877880 - Flags: review?(bobowencode)
This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Keywords: stale-bug
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Moving to p3 because no activity for at least 1 year(s).
See for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.