Feedback from Claude:

Testing DCP-o-matic 2.18.39 (d71b711220) on Linux turned up two defects in dcpomatic2_kdm_cli.

First, the trusted device list is written with a thumbprint of nothing: passing -T <certificate> produces a KDM whose AuthorizedDeviceInfo/DeviceList/CertificateThumbprint is always 2jmj7l5rSw0yVb/vlWAYkK/YBwk=, which is the base64 SHA-1 of an empty input, rather than the thumbprint of the certificate supplied. I reproduced it with three different certificates whose real DER SHA-1 thumbprints are PPvP/Eq5P0t9Om2CjjVmSSKVgJg=, 9Sla3fDlp3tVMdr4RvpJPvKepKg= and UQ03OaS5eHR2AFTQhIUhGLVe9ko=, and all three yielded the same empty hash with no error or warning, so the resulting device list names no real device and a TDL-enforcing playback device has nothing valid to match.

Second, KDM generation fails for an encrypted Interop film with the message "no CPLs found in film", even though the film transcodes successfully, its metadata.xml records <Encrypted>1, and it contains exactly one CPL at <film>/<dcp>/cpl_<uuid>.xml using the http://www.digicine.com/PROTO-ASDCP-CPL-20040511# namespace; the identical command against an encrypted SMPTE film, with the same projector certificate and validity window, produces a valid ST 430-1/430-3 KDM. Whether Interop KDM generation is deliberately unsupported or CPL discovery simply does not recognise an Interop CPL root, the error message is misleading either way. Both were reproduced with films created by dcpomatic2_create and KDMs requested as dcpomatic2_kdm_cli -C projector.pem -T trusted-device.pem -c Cinema -S Screen -f "2026-10-01 00:00:00" -t "2027-01-01 00:00:00" -o outdir <film>.