1 Dec
2018
1 Dec
'18
4:03 p.m.
Hi!
Sorry for the late reply. I have no direct access to the created DCP
and the equipment used. I have just studied the logs.
On Wed, Aug 22, 2018 at 2:42 PM Carl Hetherington <cth(a)carlh.net> wrote:
Sorry, this was sort of a wild guess. I don't think this was ever the case.
Best,
Mattias
Hi all,
Sorry I dropped the ball with this... too many emails and too little time.
I'm still keen to get to the bottom of it!
Maybe a warning or a note in the manual is enough? Some media block's
secure clocks are prone to be really off. Especially the Dolby Cat.745
can be upt to 1,5 hours off in "normal" operation. The units I have
seen with the secure clock drifting it has been set into the future
(i.e. 1,5 hours ahead).
1) DoM self-signed certificate chain is created
with a validity time
stamp in the future. This could happen because either the system clock
on the machine which DoM runs on, or the media block secure clock is
out of sync. I don't know if there is anything we really can do about
this, apart from telling people that it is important to have accurate
clocks. Especially Dolby Cat745:s are notorious for drifting (usually
into the future though). The Cat745 clock in this particular case has
been verified as set accurately. Unfortunately I have so far been
unable to verify if system time on the system which DoM was run to
generate the content was set correctly.
The chain should only be created when DCP-o-matic is first run on a
machine, so unless the clock was way out I think this should only happen
if a DCP is made soon enough after DCP-o-matic's initial install.
Maybe it's possible to set the validity period of DoM's certificates to
start before "now" as a partial workaround? 2) uuid:s for
DoM:s KDM:s are reused. Why I suspect that maybe DoM
incorrectly re-uses KDM uuid:s is because the Cat745 log below
referencing an ID from the KDM XML issued with the same id after this
log entry
I don't think I follow this, sorry. The log is validating 4576cbc1...
where is the re-use?