On Sun, Nov 05, 2006 at 06:22:34PM -0800, Ralph Giles wrote:
> On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael
Niedermayer wrote:
>
> > btw, ralph if you disagree here, iam curious about
the cases where you think
> > that a crc field on frames makes sense
>
> The main thing, I think, is that most decoder
implementations are not
> robust against garbage data (and in some cases cannot
be, entirely) so
> a crc on the frame data helps catch corruption that
could crash or
> mangle playback. It's not a security issue per se,
since malicious code
> could of course set correct crcs, but it still improves
robustness.
If your decoder implementation is not robust against invalid
data,
then you MUST fix it. Not doing so is a remote exploit
waiting to
happen. Having the container 'protect' the decoder from
corrupt data
only makes it less likely for these bugs to be found at
random, and
more likely for evil crackers to be hoarding them and
waiting to use
them on you.
> The other point is file verification. Since people
collect and serve
> media files, it's convenient to have an embedded
integrity check to
> detect corruption. An embedded hash or separate
checksum can do the same
> thing, but it's not automatic, and doesn't work with
streaming. They do
> help with truncation detection though.
A single hash of the whole file is easier to check when
managing file
integrity, and then you can use a single scheme for all your
files
rather than different integrity-checking for each file
format.
> PNG images (and FLAC frames) have CRCs, JFIF jpeg and
GIF do not, so
> perhaps you can make an argument that it's more
important for lossless
> storage. But I've only heard the png developers talk in
terms of
> integrity verification motivated as above.
I think it's just a matter of people not understanding what
they're
doing and thinking "hey I could throw a CRC at it to
protect it from
corruption!" without even asking what concrete problems
it would solve
or fail to solve...
Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
> The other point is file verification. Since people
collect and serve
> media files, it's convenient to have an embedded
integrity check to
> detect corruption. An embedded hash or separate
checksum can do the same
> thing, but it's not automatic, and doesn't work with
streaming. They do
> help with truncation detection though.
A single hash of the whole file is easier to check when
managing file
integrity, and then you can use a single scheme for all your
files
rather than different integrity-checking for each file
format.
> PNG images (and FLAC frames) have CRCs, JFIF jpeg and
GIF do not, so
> perhaps you can make an argument that it's more
important for lossless
> storage. But I've only heard the png developers talk in
terms of
> integrity verification motivated as above.
I think it's just a matter of people not understanding what
they're
doing and thinking "hey I could throw a CRC at it to
protect it from
corruption!" without even asking what concrete problems
it would solve
or fail to solve...
Rich
_______________________________________________
NUT-devel mailing list
NUT-devel
mplayerhq.hu