HLS identity key format added inappropriately

[joeyparrish]

System info

Operating System: ChromeOS with Debian container
Shaka Packager Version: v3.2.0 and current main (f07fd0d), but bug may date back to 2020 (665e784 and v2.5.0)

Issue and steps to reproduce the problem

Asking for Widevine only in HLS should not result in the identity key format being added as well. This effectively leaks Widevine content keys.

Discovered while updating and debugging Shaka Streamer test cases.

Packager Command:

packager 'in=tmp1,stream=video,init_segment=output_files/video_144p_108k_h264_init.mp4,segment_template=output_files/video_144p_108k_h264_$Number$.mp4' --quiet --segment_duration 4 --generate_static_live_mpd --mpd_output output_files/dash.mpd --hls_playlist_type VOD --hls_master_playlist_output output_files/hls.m3u8 --enable_widevine_encryption --key_server_url https://license.uat.widevine.com/cenc/getcontentkey/widevine_test --content_id 3FDD22DBF8A7ECB92F071A1A4B1FC7FA --signer widevine_test --aes_signing_key 1ae8ccd0e7985cc0b6203a55855a1034afc252980e970ca90e5202689f947ab9 --aes_signing_iv d58ce954203b7c9a9a9d467f59839249 --protection_scheme cenc --clear_lead 0

What is the expected result?

Something like #EXT-X-KEY:METHOD=SAMPLE-AES-CTR,URI="data:text/plain;base64,AAAAOHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABgiED/dItv4p+y5LwcaGksfx/pI49yVmwY=",KEYID=0x2dfddc4a6a7c5136bb68bb314887eed5,KEYFORMATVERSIONS="1",KEYFORMAT="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" in the media playlist.

What happens instead?

We also get #EXT-X-KEY:METHOD=SAMPLE-AES-CTR,URI="data:text/plain;base64,Lf3cSmp8UTa7aLsxSIfu1Q==",KEYFORMAT="identity"

<Please attach the input files or email to [email protected].>

This is a 1-second MP4 clip used in the above command, but I expect other inputs might work with the same parameters: tmp1.zip

[joeyparrish]

It's not clear to me what this logic was supposed to do in FillPsshGenerators in packager/media/crypto/encryption_handler.cc, but this is where the extra key format gets added to HLS output:

  if (pssh_generators->empty() && no_pssh_systems->empty() &&
      (encryption_params.key_provider != KeyProvider::kRawKey ||
       encryption_params.raw_key.pssh.empty())) {
    pssh_generators->emplace_back(new CommonPsshGenerator());
  }

It was added in f07fd0d, which was supposed to move key logic from one place to another, but there's no equivalent to this logic in the original location AFAICT.

[joeyparrish]

Using old docker images, I have confirmed that this bug was present in the v2.5.0 release, but not in v2.4.3.

[joeyparrish]

Simply removing that stanza doesn't seem to be the right fix. That appears to add the common PSSH to DASH outputs, which is appropriate and doesn't leak the key. But that common PSSH generator translates to the identity key format for HLS, which feels wrong.