Closed Bug 1475260 Opened 6 years ago Closed 6 years ago

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

Categories

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

defect

Tracking

(firefox63 affected)

RESOLVED FIXED
Tracking Status
firefox63 --- affected

People

(Reporter: bryce, Assigned: jlund)

References

Details

Attachments

(1 file)

The media team are planning on updating the Widevince CDM to version 1.4.9.1088 in nightly (Firefox 63). I have verified the CDM for the following cases:
- Linux (32bit + 64bit builds)
- MacOS (64 bit build)
- Windows 7 (32bit + 64bit builds)
- Windows 8 (32bit + 64bit builds)
- Windows 10 (32bit + 64bit builds)

As the new CDM appears to be working, it would be helpful for us to have the nightlytest rules updated to allow for testing. Provided all is well with nightlytest verification, we can update nightly after which we would want the rules to ride the train.

Could the balrog rules for nightlytest please be updated? The following are the details for the new CDMs:

Linux 32bit:
URL: https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-linux-ia32.zip
SHA512: fb0207c6e24c05144ed345a6e37afc8e7bc2700c9bc4b536fa23503f08f2d258e10c4f1ef40f6ed0d6d8eaf495dbdcc924e71314cc1858f81fe6208cd210e8b5
file size: 3062013 bytes

Linux 64bit:
https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-linux-x64.zip
SHA512: 8038d142f14b8992db282003ed7bd7fcb6a11c556fdfe34d410d017c3d8d792c24f38a24f6f65fea1a979a4c697f50cca826d8a28ae4fa9740512c3291d52aaf
file size: 2921375 bytes

MacOS:
https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-mac-x64.zip
SHA512: 79cde6f9457f1b46f03ba5baade0852ad2a7d640930c3229a750deb37b5061a9e75e8d6410a138bbdd7c871f8310476ad4a6f295cd05235ea9f392de339ff83c
file size: 3220735 bytes

Win 7/8/10 32bit:
https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-win-ia32.zip
SHA512: 8e115f3f941663ac052570191acca09cb025388f82b232df5770aeb1781a611f002226de244ddd1b75553bbb5154068dca8913465b2c27ea28a1b4cae8359682
file size: 3389392 bytes

Win 7/8/10 64bit:
https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.9.1088-win-x64.zip
SHA512: 48b25b1a89ac07fa041c17ff4ae6ac43171a69a7fdcb226c09150b8ecc824dc3a7fa2f2a9f607c35fb5e1e234cfc0bd717a9a48883fc8084ac0743f2e695bbf8
file size: 3351002 bytes

Please let me know if any further details are required.
I have notified the release-drivers mailing list of the intent to update the CDM.
Tracking this for 63, barring any blockers, this will likely ride the 63 release train.
Last time we did this was bug 1388771.
hi - 

Would this be okay to do early next week? Trying to slot it in when we have experienced people available to assist. Can expedite if this bug is blocking and doing sooner has notable impact.
Flags: needinfo?(bvandyk)
Early next week sounds good.
Flags: needinfo?(bvandyk)
@aki - is this something you can mentor releaseduty? The outcome should be that releaseduty write docs of what was passed on.
Flags: needinfo?(aki)
Yes, I can mentor. Is there a good time for you/releaseduty?
Flags: needinfo?(aki)
Any updates on the progress of bumping nightlytest?
Assignee: nobody → jlund
FYI, bug 1476080 added an alias for Linux ASan builds on the previous Widevin (1.4.8.1088):

--- Data Version 1
+++ Data Version 2
@@ -24,6 +24,9 @@
           "filesize": 2207964,
           "hashValue": "37e037a5e0c320a6a577492050d86b2bbd00239610785b0f07326e6c47b6d1899ac4f6874ad1436982a95a13c11fd73e10e9287d88da0c1036dd6eb36fe91e65"
         },
+        "Linux_x86_64-gcc3-asan": {
+          "alias": "Linux_x86_64-gcc3"
+        },
         "WINNT_x86-msvc": {
           "fileUrl": "https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-win-ia32.zip",
           "filesize": 2544372,

We should do this for 1.4.9.1088 too, and in future as ASan expands to other platforms.
You should now receive 1.4.9.1088 on all platforms against the "nightlytest" channel.

Couple notes:

* all other channels are unaffected
* there is another rule for "nightly*" that is a watershed which we may be able to delete? "nightly*" channel users who are gecko <58.0a1 will get Widevine-1.4.8.970 before then getting Widevine-1.4.8.1008
** if you are nightlytest specifically, you will now ignore this update flow
** I did not set any min or max requirements against what gecko version you must come from on nightlytest to receive this. So all nightlytest users will receive 1.4.9.1088.


bryce - We can update this on other channels as you sign off and dictate how you would like this to ride the trains
(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #9)
> FYI, bug 1476080 added an alias for Linux ASan builds on the previous
> Widevin (1.4.8.1088):
> 
> --- Data Version 1
> +++ Data Version 2
> @@ -24,6 +24,9 @@
>            "filesize": 2207964,
>            "hashValue":
> "37e037a5e0c320a6a577492050d86b2bbd00239610785b0f07326e6c47b6d1899ac4f6874ad1
> 436982a95a13c11fd73e10e9287d88da0c1036dd6eb36fe91e65"
>          },
> +        "Linux_x86_64-gcc3-asan": {
> +          "alias": "Linux_x86_64-gcc3"
> +        },
>          "WINNT_x86-msvc": {
>            "fileUrl":
> "https://redirector.gvt1.com/edgedl/widevine-cdm/1.4.8.1008-win-ia32.zip",
>            "filesize": 2544372,
> 
> We should do this for 1.4.9.1088 too, and in future as ASan expands to other
> platforms.

thanks, yep caught that.

That alias should be in for 1.4.9.1088
Thanks for the work thus far.

> * there is another rule for "nightly*" that is a watershed which we may be
> able to delete? "nightly*" channel users who are gecko <58.0a1 will get
> Widevine-1.4.8.970 before then getting Widevine-1.4.8.1008

I think I will benefit from a number of clarifications:
- Does 'nightly*' describe nightly and nightlytest channels, or something more? Do we have have catch all rules separate from the nightly* rules mentioned?
  - Follow up: do rules target a channel and a version (or build number)?
- Regarding the quoted text, are users on the nightly* channel before 58.0a1 will get 1.4.8.970, and those later than 58.0a1 will get 1.4.8.1008? Or rather those on the nightly* channel before 58.0a1 will get 1.4.8.970 and then also get 1.4.8.1008?

> ** I did not set any min or max requirements against what gecko version you
> must come from on nightlytest to receive this. So all nightlytest users will
> receive 1.4.9.1088.

Apologies, I should have specified a version in my initial request. This may be moot given that I want to move these changes to the main nightly channel, but could we ensure this update is only served to Firefox 63 and later? For my future reference, if we do not have a specific rule for nightlytest will we fall back to the nightly rules (and if not specific nightly rules to default/some sort of catch all)?

I've tested the update on the nightlytest channel across our T1 platforms. Behaviour appears consistent with the CDM we are currently using, I'm not seeing any issues. However, I want to make sure I understand the above before continuing to update more channels.
Flags: needinfo?(jlund)
we touched base on irc.

I used the following attachment to go over state.

jlund>
that image shows update paths. it can be read from top to bottom. It's ordered by a priority we set. You can see the priority field descending for each "rule".
14:58:44 iow - if you are a client (on a widevine update channel) pinging the update server (balrog) for an update, balrog will go through these rules top to bottom until it finds one that meets your current client specs
14:58:45 
<bryce> Bryce Van Dyk Ah. Cool. I that helps clarify how this works :)
15:01:27 specs == things like your OS and OS version, your gecko version, and update channel. if no channel is specified (majority in widevine case) than it applies to all channels. channels with a glob at the end, e.g. nightly* will apply to all clients that have nightly in the name and any (or none) chars after
15:01:35 so, more concretely
15:03:27 if I am ff 56.0 on any channel (including say nightly), I would skip the first two rules at the top as I don't meet those requirements. The third rule I would catch as I am <57.0 and so I would get served 1.4.8.970.
15:04:38 the next time I ping the update server, I would iterate over those rules again, iterating over them until either I meet a rule that is mapped to a newer widevine version than I have or I get served nothing
15:05:19 does that somewhat make sense? Happy to explain more or hop on vidyo if it helps
15:05:25 
<bryce> Bryce Van Dyk Appreciate the explanation, I think I follow. 1) If we want an update to ride the train, can we ammend the current last rule to be <63.0a1 and add a new final catch all? 2) Is there any concern with maintaining the old rules aside from bloating the table? At this stage we'd like to not rock the boat for old installs.
15:08:47 
<jlund> Jordan Lund 1) we can amend or create any rule to control flow. In this case, we could put <63.0a1 to the last rule and then create a new nightly rule upcoming 1.4.9.1088 release, users <63.0a1 won't get it. I think we are on the same page and you understand how it works
15:09:47 2) it's fine to add more rules. At some point, we should prune to minimize complexity. But that's a human complexity not a scaling issue. e.g. perhaps we can remove really old rules where we are confident we don't have users anymore.
bryce> Bryce Van Dyk cool, I'm happy to go ahead with moving into nightly, would you like me to comment on that bug as such, or is confirmation here sufficient?
Flags: needinfo?(jlund)
Widevine-1.4.8.1008 is being served <63.0 across all channels

Widevine-1.4.9.1088 is being served to nightly users >=63.0
Trello card indicates that no further work is needed for 63, untracking.
I believe all the work here is done. Please reopen if I'm mistaken.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: