@parent and @grandparent: The chunk CRC-32 does cover the chunk type.
> A four-byte CRC (Cyclic Redundancy Code) calculated on the preceding bytes in the chunk, including the chunk type field and chunk data fields, but not including the length field. -- https://www.w3.org/TR/2003/REC-PNG-20031110/#5Chunk-layout
It has been many years since I looked into this matter, and I seem to have forgotten that detail.
Digging through my sent box, to png-mng-misc, I see that knew that back in 2012!
I also wrote that most of the tools I checked didn't verify the CRC:
> I tried a PNG with an IDAT chunk with an invalid CRC on various software
on the my Mac. Unless I messed up my testing, the desktop, email preview,
OmniGraffle, and Pixen.app all used the chunk with the invalid CRC.
My thread was "I would like some insight about PNG CRC and other experience" in case someone wants to dig it up.
I was able to make an PNG with a length field which, if changed, would produce another PNG showing a different result. At least one of the PNGs had an invalid checksum, but was still displayed.
'IHDR' 13 (this is the chunk data size, excluding the 4 bytes of crc)
'xtra' 0
'IDAT' 1012 <-- this one is displayed
'IDAT' 1090 <-- this one is ignored
'IEND' 0
> A four-byte CRC (Cyclic Redundancy Code) calculated on the preceding bytes in the chunk, including the chunk type field and chunk data fields, but not including the length field. -- https://www.w3.org/TR/2003/REC-PNG-20031110/#5Chunk-layout