bmp/decoder: ensure palette has correct length

[philipc]

This is a minimal fix for #477.

I'm not sure this is the best fix though. What's the general philosophy regarding corrupt files? Should we fail if we detect corruption, or proceed as best as possible? A related concern is whether there should there be a limit on image width, height, palette size etc; we don't want to use gigabytes of memory due to a corrupt or malicious file.

Should I convert the test case into a file and add it under tests? This would be different from the existing tests, because I don't think there are any test cases for invalid files yet.

I also plan to audit other uses of read_to_end().

[nwin]

We don’t have a policy regarding corrupted files yet. So far we are failing. It could be an option to make the decoder configurable such that it may continue decoding if the error is recoverable.

To understand it correctly: This error occurs if the file is truncated? Looks like a sensible fix

Big/corrupt images are actually an issue as valid file might actually take up several GiB of memory. PNG is especially problematic at it requires to hold an entire scanline in memory to decode the next so on-the-fly resizing is difficult. An option would be to compress the previous scanline…  😳

[philipc]

This error could occur for both truncation of color palette or corruption of color palette size. This fix will make it try to continue decoding. We could make it fail immediately by using read_exact() instead of take().read_to_end().

[philipc]

Changed the fix to fail if the image is truncated. Also added a test, and an additional fix in tga.

[nwin]

Great, that looks good. Thank you for your contribution.