59 bytes, text/x-review-board-request
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.
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 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.
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.
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.
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.