14 Oct
2014
14 Oct
'14
2:58 p.m.
I tend to do it unsigned, so I can later modify the xml files by hand
if needed. Wondering if there is any advantage on signing (not
encrypting) a DCP.
Thanks!
Manuel AC
14 Oct
14 Oct
3:10 p.m.
I Manuel,
In my opinion, there is no advantage signing a plaintext or an interop
encrypted dcp.
Lilian
Le 14/10/2014 16:58, Manuel AC a écrit :
I tend to do it unsigned, so I can later modify the
xml files by hand
if needed. Wondering if there is any advantage on signing (not
encrypting) a DCP.
Thanks!
Manuel AC
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
3:19 p.m.
Hi,
my guess :
signing makes little more complicated to modify your DCP once in the
wilderness.
It's mostly a way for "versionning" your DCP.
Signing may not be useful for DCP you only use in one place.
Am I right ?
Best regards,
Gérald
Le 14/10/2014 16:58, Manuel AC a écrit :
I tend to do it unsigned, so I can later modify the
xml files by hand
if needed. Wondering if there is any advantage on signing (not
encrypting) a DCP.
Thanks!
Manuel AC
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
3:55 p.m.
I tend to do it unsigned, so I can later modify the
xml files by hand
if needed. Wondering if there is any advantage on signing (not
encrypting) a DCP.
As far as I know, at some point unsigned SMPTE DCPs will be rejected by servers. I
don't know which server currently enforces that already. Signing usually will prevent
others from doing changes to the DCP. That could be a benefit or not.
I have yet to do some testing of signed/unsigned Interop and SMPTE content on different
servers to find out what happens. I did some test previously on our Sony which shows
various validation indicators for ingested content. I haven't been able to find out
exactly what they are based on, because they vary even for 'commercially'
generated content - trailers, features, etc.
I follow the ISDCF maling list for a while now and the ISDCF's struggle in the
transition from Interop to SMPTE formatting. It's a simple technical, but complex
behavioural process, which in turn makes it a complex technical matter again because of a
necessary transitional process in order have no lost shows.
Also we should not take for granted that the DCP-o-matic is doing it is completely right
or the only way to implement it.
We recently had an issue with a commercial DCP that was one of our first tests of an IP
based download from a german content provider. We were able to ingest it okay, it would
show up in the list of ingested features, but we couldn't select the CPL for playback,
it simply didn't turn up in that CPL list. So there was obviously something wrong with
it. Another download fixed it, but we weren't even sure wether they had changed
something in the file now or if it was a download issue (a dedicated download client is
used).
As far as I know, 'Signing' is for authorative preventing of intentional or
unintentional manipulation, while 'file hashes' provide some technical means to
assure proper transmission and storage.
Then a server could do some additional checks to make sure the content is correct, e.g.
checking for valid audio or J2k file structures. I don't know which server applies
which strategies. Most do some checking while or after ingesting.
- Carsten
4:11 p.m.
Le 14/10/2014 17:55, Carsten Kurz a écrit :
I
think this point is only for encrypted smpte dcps.
E.G. EasyDcpPlayer+ will reject them.
I tend to do it unsigned, so I can later modify
the xml files by hand
if needed. Wondering if there is any advantage on signing (not
encrypting) a DCP.
As far as I know, at some point unsigned SMPTE DCPs will be rejected by servers. I don't know which server currently enforces
that already. Signing usually will prevent others from doing changes to the DCP. That
could be a benefit or not.
Signing will not prevent the modifications in all cases:
only for
encrypted smpte dcps.
If you want to modify a cpl of an interop encrypted dcp, you'll can do
this without trouble.
You'll can put you own signature if wanted.
I have yet to do some testing of signed/unsigned Interop and SMPTE content on different
servers to find out what happens. I did some test previously on our Sony which shows
various validation indicators for ingested content. I haven't been able to find out
exactly what they are based on, because they vary even for 'commercially'
generated content - trailers, features, etc.
I follow the ISDCF maling list for a while now and the ISDCF's struggle in the
transition from Interop to SMPTE formatting. It's a simple technical, but complex
behavioural process, which in turn makes it a complex technical matter again because of a
necessary transitional process in order have no lost shows.
Also we should not take for granted that the DCP-o-matic is doing it is completely right
or the only way to implement it.
We recently had an issue with a commercial DCP that was one of our first tests of an IP
based download from a german content provider. We were able to ingest it okay, it would
show up in the list of ingested features, but we couldn't select the CPL for playback,
it simply didn't turn up in that CPL list. So there was obviously something wrong with
it. Another download fixed it, but we weren't even sure wether they had changed
something in the file now or if it was a download issue (a dedicated download client is
used).
Did you check it with dcp_inspect?
As far as I know, 'Signing' is for authorative preventing of intentional or
unintentional manipulation, while 'file hashes' provide some technical means to
assure proper transmission and storage.
As I said before, it only works for smpte
encrypted content.
You can remove the signature of plaintext dcps and encrypted interop
dcps if you take care modifying hashes and sizes.
Lilian
Then a server could do some additional checks to make sure the content is correct, e.g.
checking for valid audio or J2k file structures. I don't know which server applies
which strategies. Most do some checking while or after ingesting.
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
3849
days inactive
3849
days old
4 comments
4 participants
participants (4)
-
Carsten Kurz -
Gérald Maruccia -
lilian lefranc -
Manuel AC