chunks longer than 2^31 bytes

[rayrobdod]

Although encoders and decoders should treat the length as unsigned, its value shall not exceed 2³¹-1 bytes.

-- the PNG spec (Second Edition)

• An oversized inflated IDAT (or fdAT - but this would require renumbering all the APNG chunks, which is the same problem as merging adjacent fdATs) can be split;
  • this could mean that chunk inflating is no longer always a one-to-one transformation
  • this could mean that Chunk struct could hold data that is illegal to write - which can already happen through the ConcatinateIdats step, or theoretically since Chunk doesn't currently encapsulate its typ field. Being idiomatic would probably require forcing Chunk to always be a valid-to-write chunk. (have separate png-legal Chunk and a not-neccessarily-legal Chunk types? seems overengineered). And this would require adding a SplitIdats step.
• An oversized inflated zTXT, iCCP or iTXT would be unrecoverable. Those chunks can't be split with a preserved meaning, and an algorithm to inflate as much as possible without going over 2MB is not worth the time or effort.
• any other chunk wasn't decompressed, and thus was an input error to begin with, but could be checked at read time

Also, might want to be able to integration-test this without having to commit a 2MB file into the source repository. Which would mean having to let the derive crate generate files in addition to listing existing paths.

[rayrobdod]

On the one hand, I want the program to be relatively strict in order to avoid corrupting something that it does not understand; on the other hand "be liberal in what you accept"

If the input isn't checked for the artificial chunk size limit, only output, then the test for a large uncompressed file hits the same code paths as a zip bomb, meaning I wouldn't have to do both.

Granted, I don't think CI would be happy whether the program tried to process a large input file or a zip bomb.