[NUT-devel] NUT?

[Rich Felker]

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