Closed Bug 1388771 Opened 3 years ago Closed 2 years ago

Update Widevine CDM to version 1008 (Windows, Mac, and Linux)

Categories

(Release Engineering :: Release Requests, enhancement, P1)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: JamesCheng, Assigned: aki)

References

Details

Attachments

(1 file, 1 obsolete file)

We are planning to update the CDM when bug 1383769 is fixed.

The detail will be provided once we verified the new CDM on Windows, Linux and Mac.
We probably want to depend on bug 1382882, which is the entire releng stack.
I think we're done with the signing server side (bug 1383769) but we still have to land on m-c (bug 1383771). We can uplift bug 1383771 to beta once it looks good on central.
Depends on: 1382882
We change our target to version 984.

So I'd like to change the bug title and wait for the sig file landed in Nightly.

Thank you Aki.
Summary: Update Widevine CDM to version 1008 (Windows, Mac, and Linux) → Update Widevine CDM to version 984 (Windows, Mac, and Linux)
Blocks: 1390453
Depends on: 1390739
Depends on: 1390725
See Also: → 1383624
Depends on: 1392175
Blocks: 1392535
Depends on: 1392976
We finally resolved the last blocking issue for CDM 1008, so we decided to focus on pushing 1008 CDM to Nightly and Beta.

Change the title back.
Depends on: 1392485
Summary: Update Widevine CDM to version 984 (Windows, Mac, and Linux) → Update Widevine CDM to version 1008 (Windows, Mac, and Linux)
Beta could be tested with CDM 1008 only bug 1392485 and bug 1383771 have been uplifted.
See Also: → 1383771
We have a new Widevine CDM version 1.4.8.1008 to deploy on desktop.

Please update the balrog rules for Firefox 57 (currently in Nightly) as follows:

Linux 32bit
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-linux-ia32.zip
SHA512: 5af0f41dddf3077c2977a775a3009c435569892f7efa2110932424fda3556d6ecee76fbb1e9633e72b72e09a92b0b7fa2ac159e1741b0d4cd94e095b6e121bce
FileSize: 2289324

Linux 64bit
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-linux-x64.zip
SHA512: 37e037a5e0c320a6a577492050d86b2bbd00239610785b0f07326e6c47b6d1899ac4f6874ad1436982a95a13c11fd73e10e9287d88da0c1036dd6eb36fe91e65
FileSize: 2207964

MacOS 10.9+
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-mac-x64.zip
SHA512: 950b2e1e74dc685294540e2969050a5558e9314d17a122b38b61de35897e692da247bff820fa3df721c607b38aa3bd95f36f7d4da83fb11a67ec9b1198890be8
FileSize: 1755276

Windows 7+ 32bit
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-win-ia32.zip
SHA512: 4630796cf6e5cc832317bf07bcda70f46432111d0bb381da9e2ebf9350cbac7790d6db1c34c7e3bced774a9b7811310cf21011fccbff779ac76d237505b5f117
FileSize: 2544372

Windows 7+ 64bit
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-win-x64.zip
SHA512: 2c3ebe3a5c3fa62e2fb2e41080d576c71fa060cb81ef415815652a020bb3da16de28d9a2d0d5af4f71df920abd159d6c3cf27ebdd1d65daf62cee6282f9def85
FileSize: 2537223

I've manually tested the new 1008 CDM with latest Nightly on Win7(32/64bits), Win8.1(32/64bits) and Win 10(32/64bits), MacOS, Linux(32/64bits).

Hello Mihai,
Could you please help on this? Since bug 1380175 was taking charge of you?
Once it was pushed out to Nightly, we will test it and request pushing out to Beta then.
Thanks you.

Blake Wu will send notification of this update to the release-drivers mailing list.
Flags: needinfo?(mtabara)
Flags: needinfo?(bwu)
Done! I have sent out the email.
Flags: needinfo?(bwu)
Absolutely, just one question though.

We currently serve:
Widevine-1.4.8.903 to <56.0a1 users 
Widevine-1.4.8.970 to users above that.

Which of the following scenarios do we want next?

1) keep existing restrictions and also add Widevine-1.4.8.1008 to >= 57.0a1 so that:
Widevine-1.4.8.903 to <56.0a1 users 
Widevine-1.4.8.970 to <57.0a1 users
Widevine-1.4.8.1008 to all above

2) 

Widevine-1.4.8.970 to <57.0a1 users 
Widevine-1.4.8.1008 to users above that

I could be wrong, but my gut feeling says we'd go for option 1) since 56.0 is not yet releases and going with option 2 would mean we're serving Widevine-1.4.8.970 (which is still riding the trains in beta currently) to previous release populations.

Am I right?
Flags: needinfo?(mtabara) → needinfo?(jacheng)
See Also: → 1380175
Hi Mihai,

Yes, currently, we wanna apply option 1.

I think bug 1392485 will be uplifted to Beta soon and will be built into 56.0bX(X depends on the build date)

We will request Beta updating the Balrog rule to serve 1008 CDM.

So the rule will be changed like:

Widevine-1.4.8.903 to <56.0a1 users 
Widevine-1.4.8.970 to <56.0bX users && Widevine-1.4.8.970 to <57.0a1 users
Widevine-1.4.8.1008 to >= 56.0bX and >=57.0a1

I don't know how you distinguish if user's Nightly firefox is before Bug 1392485 landed since 57.0a1 is always the same in Nightly by my observation.

Is that clear to you?

ni? cpearce that keep him updated.

Thank you very much.
Flags: needinfo?(jacheng) → needinfo?(cpearce)
Flags: needinfo?(mtabara)
Dumping some context for later on:

JamesCheng> mtabara: 57.0a1 always confuse me. If it is a fixed value ,how can you tell the version among Nightly
17:43:19 <mtabara> you can't. the version in nightly changes every 6 seeks
17:43:32 <mtabara> I guess we'd need to filter by buildid in this case
17:45:08 <JamesCheng> So if user did not update Nightly, they might use 1008 cdm without the fix,right?
17:48:38 <@catlee> yes, we can filter by buildid
17:56:30 <@catlee> JamesCheng: each  build gets a buildid that increases over time 
17:56:51 <@catlee> We can use that to serve updates to some nightly users but not others 
17:57:23 <JamesCheng> catlee: thanks but I don't know if we can use the buildid in the Balrog rule
17:57:32 <@catlee> We can 
17:58:28 <mtabara> we'll use the next nightly or so after that change from 1392485 landed
17:58:40 <JamesCheng> ok, thanks for the information. 
17:59:35 <mtabara> JamesCheng: what's the ETA for this?
18:00:30 <JamesCheng> mtabara: what you mean "ETA"?
18:00:39 <mtabara> expected time of arrival
18:01:04 <mtabara> as in, when is the 1008 expected to be live? today/tomorrow or can it wait till next week
18:01:19 <JamesCheng> next week is OK
18:01:58 <JamesCheng> we need to test it in Nightly and request the rule update in Beta also
18:02:16 <@catlee> JamesCheng: I'm curious how you're testing this on Try. Are you testing with real DRM content?
18:02:24 <@catlee> or are there test endpoints for development?
18:02:42 <JamesCheng> catlee: I tested using Netflix(real DRM content)
18:03:01 <JamesCheng> catlee: I download the target.zip from treeherder
18:03:33 <JamesCheng> mtabara: The final goal should be making all 56 user use 1008 CDM.
18:04:22 <mtabara> ok
After IRC discussion,

Assume that
Bug 1392485 will be uplifted and will be built into 56.0bX
Bug 1392485 was landed in Nightly with 57.0a1 with buildid YYY

So the final rule could be like,

Widevine-1.4.8.903 to <56.0a1 users 
Widevine-1.4.8.970 to <56.0bX users && Widevine-1.4.8.970 to <57.0a1 with buildid YYY users
Widevine-1.4.8.1008 to >= 56.0bX and >=57.0a1 with buildid YYY

Hope it's ok for you to regulate the Balrog rule?
Flags: needinfo?(mtabara)
Priority: -- → P1
Just noting that the changes in bug 1392485 landed in time for the beta 8 build.
The newer CDMs don't work with older Firefox. So we need to keep serving the older CDMs to older Firefox for the rest of time.
Flags: needinfo?(cpearce)
Attached file widevine-1.4.8.1008.json (obsolete) —
This is based on https://bugzilla.mozilla.org/attachment.cgi?id=8886353&action=edit , but with the information from comment #5.
Attachment #8903275 - Flags: review?(nthomas)
Attachment #8903275 - Attachment is obsolete: true
Attachment #8903275 - Flags: review?(nthomas)
Attachment #8903279 - Flags: review?(nthomas)
Comment on attachment 8903279 [details]
widevine-1.4.8.1008.json - fix the mac url

lgtm based on diffing this against the 970 release blob and running my check script over it.
Attachment #8903279 - Flags: review?(nthomas) → review+
Current status:

- added the release to balrog from the json
- added 2 nightlytest rules. These look good currently.

# gives us 1008
curl https://aus5.mozilla.org/update/3/GMP/57.0a1/20170830220349/WINNT_x86_64-msvc-x64/en-US/nightlytest/default/default/default/update.xml
# gives us 970
curl https://aus5.mozilla.org/update/3/GMP/57.0a1/20170829220349/WINNT_x86_64-msvc-x64/en-US/nightlytest/default/default/default/update.xml

- scheduled priority bumps for the existing widevine rules. I also changed rule 611 to only apply to version <57.0a1. These currently need signoff from QE and Relman. https://aus4-admin.mozilla.org/rules/scheduled_changes

- Once those are signed off, we need to change the 2 nightlytest rules 646 and 647, to s,nightlytest,nightly*,
Then we should re-test the above two curl commands.
I believe we are updated to 1008 on the nightly channel now.
We'll still need to make rule changes for beta 9? 10? when we want to roll out there.
Hi Aki,

I've tested and it works well on all platforms.

If I tested the new CDM manually on Beta(maybe 56.0b8), I will request the Balrog rule updating.

Should I use this bug for updating request or I need to create a new bug?

Thanks.
Flags: needinfo?(aki)
Either works for me.
Flags: needinfo?(aki)
Hi Aki,

I bumped into a problem,

http://searchfox.org/mozilla-central/rev/999385a5e8c2d360cc37286882508075fc2078bd/browser/app/profile/channel-prefs.js#5

The channel-prefs.js in my install folder records "pref("app.update.channel", "nightly");".

But when I use ./mach run, the channel-prefs.js records "pref("app.update.channel", "default")".

And the widevinecdm didn't appear in update.xml with "default" channel [1].
For "nightly" channel, widevinecdm appears [2].

Is it related to the Balrog rules on "default" channel which may need to align "nightly" channel?

Thanks.




[1]
https://aus5.mozilla.org/update/3/GMP/57.0a1/20170904100131/Linux_x86_64-gcc3/en-US/default/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml
[2]
https://aus5.mozilla.org/update/3/GMP/57.0a1/20170904100131/Linux_x86_64-gcc3/en-US/nightly/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml
ni Aki as comment 20 described.
Flags: needinfo?(aki)
You're able to build with the channel changed, via mozconfig... I believe setting MOZ_UPDATE_CHANNEL in env works. widevinecdm 1008 is only set to download if the update channel is nightly* ... this is to avoid adding it to beta/esr/release.

Does that work? Or do we need to make changes?
Flags: needinfo?(aki)
I will try it when I'm in office. 
But why it did work before this bug landed?
I don't need to set anything in mozconfig, then I can get the CDM with my local build firefox.
Flags: needinfo?(aki)
The rule is only set to update <57.0a1 on all channels; nightly is set to update to 970 up to a certain buildid, and then 1008 after that buildid.
Do we require a default widevinecdm? Should we pin it to 970 or 1008?
Flags: needinfo?(aki)
To put it another way - normally the GMP rules don't have any channel set, so local builds get GMP information too. While we're in the process of deploying there are channel specific rules, which block the information being available to channels which aren't yet included. Eventually we'll get back to rules without channels set. But would a local build have the .sig files that the CDM needs ?
(In reply to Nick Thomas [:nthomas] from comment #25)
> To put it another way - normally the GMP rules don't have any channel set,
> so local builds get GMP information too. While we're in the process of
> deploying there are channel specific rules, which block the information
> being available to channels which aren't yet included. Eventually we'll get
> back to rules without channels set. But would a local build have the .sig
> files that the CDM needs ?
No, local build didn't have .sig files.

But we still can debug non-VMP part of logic through local build.

Originally, when I run a local build firefox, the downloader can get the widevine CDM from AUS server.

But now it cannot. I don't really know the detail of your rule, just curious why it worked before.
(In reply to Aki Sasaki [:aki] from comment #24)
> The rule is only set to update <57.0a1 on all channels; nightly is set to
Does "default" include in all channels? 

If so, there is no information in the update.xml, so GMP downloader do not have chance to download the CDM.

Ideally, the rule of local build(central code base) should keep up with official Nightly. We should be able to download the CDM for local debugging.

> update to 970 up to a certain buildid, and then 1008 after that buildid.
> Do we require a default widevinecdm? Should we pin it to 970 or 1008?
Hi Aki,

We've tested Beta on all supported platforms.

We would like to request the Beta Balrog rule update according to my comment 10.

The 1008 CDM is available from 56.08b

So the rule could be
========================================
Bug 1392485 was landed in Nightly with 57.0a1 with buildid YYY
Widevine-1.4.8.903 to <56.0a1 users 
Widevine-1.4.8.970 to <56.0b8 users && Widevine-1.4.8.970 to <57.0a1 with buildid YYY users
Widevine-1.4.8.1008 to >= 56.0b8 and >=57.0a1 with buildid YYY
========================================

Thank you so much.
Flags: needinfo?(aki)
Ok. I think my scheduled changes will work.

- Rule 357 catches everyone < 56.0a1 (release and esr and older betas/nightlies)
and and is the 1.4.8.903 watershed.
https://aus4-admin.mozilla.org/rules/357

- Rule 611 currently catches everyone < 57.0a1 (betas and older nightlies) and is the
main 1.4.8.970 watershed.
https://aus4-admin.mozilla.org/rules/611

There is a scheduled change to rule 611, to set it to <56.0b8, so 56.0b8 and 56.0b9 users will fall through to the next rules.

- Rule 646 catches everyone on nightly* channel, <58.0a1, <20170830220349. It is the nightly 57
1.4.8.970 watershed.
https://aus4-admin.mozilla.org/rules/646

We don't have to change this one, I don't think.

- Rule 647 currently updates non-watershed nightly* users to 1.4.8.1008. There is a scheduled change to set it to all channels, so anyone not caught by a watershed will update to 1008.
https://aus4-admin.mozilla.org/rules/647

These changes need signoff; I'd also love logic review here from both the dev+releng teams.
These are scheduled for 8am PDT Tuesday morning should they get signoff; if we're sure about these changes, we can change the time.
Flags: needinfo?(aki)
We're sure about these changes, Thank you.

BTW, I couldn't open the link you provided.

I want to see if "all channels" contained "default" channel for my local build.
(In reply to James Cheng[:JamesCheng] from comment #30)
> We're sure about these changes, Thank you.
> 
> BTW, I couldn't open the link you provided.
> 
> I want to see if "all channels" contained "default" channel for my local
> build.

I don't see your ldap within Balrog permissions. Also, to access that URL you need to be behind VPN.
(In reply to Aki Sasaki [:aki] from comment #29)
> - Rule 647 currently updates non-watershed nightly* users to 1.4.8.1008.
> There is a scheduled change to set it to all channels, so anyone not caught
> by a watershed will update to 1008.
> https://aus4-admin.mozilla.org/rules/647

We can't see this rule, and I think it's a good thing for James and I to not have balrog privileges, so can you clarify what you mean by this please? When you say "all channels", do you mean everything not covered by the other rules? So that would include locally built 57 builds, and Firefox 56 and later, so including Beta 56 and Nightly 57 users?

Thanks!
Flags: needinfo?(aki)
As comment 27 said, by testing, the "default" channel didn't be included.

Could you please check is there any change that make default channel behave abnormally?

Thanks.
"All channels" includes the default channel.
The changes in comment #29 haven't been signed off, so they're not live yet.
Flags: needinfo?(aki)
Sounds like Aki, James, and jlorenzo are in agreement about the rules as they stand now in balrog, so I will sign off for relman that we would like to make this change and start rolling out the widevine update.
The rule changes are live.
I think we're done here :)
Please reopen or file new if I'm wrong.
Assignee: nobody → aki
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
See Also: → 1413835
You need to log in before you can comment on or make changes to this bug.