Fail to load GMPs with a Win32 manifest

NEW
Assigned to

Status

()

P2
normal
Rank:
15
a year ago
a year ago

People

(Reporter: cpearce, Assigned: cpearce)

Tracking

({stale-bug})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

a year 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.
(Assignee)

Comment 1

a year 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
(Assignee)

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
mozreview-review
Comment on attachment 8877880 [details]
Bug 1373147 - Log and refuse to load GMP DLLs which contain Win32 manifests. ?bobowen

https://reviewboard.mozilla.org/r/149302/#review167268

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
You need to log in before you can comment on or make changes to this bug.