4 ms·
That screams "supply chain attack risk". You find someone to pollute the "global decoder table" and you can introduce all sorts of fun problems, many of which
by hakfoo 5y ago
That screams "supply chain attack risk".
You find someone to pollute the "global decoder table" and you can introduce all sorts of fun problems, many of which turn into "I can't replicate it here (because I cached a working decoder, or the malicious decoder is only shipped to specific clients)"
TBH, I don't think we want external entity injection and Turing-complete languages in our image formats.
You also create a bunch of permanent assumptions in any of the encoders. Today, the "image data" it expects to return might be, say, an uncompressed 48-bit RGBA bitmap. What if the next generation of image formats can do more or different? Say, volumetric image formats for VR or holographic systems? You'd need a way to signal what you're getting in the metadata, which would then have to be open-ended enough to satisfy future needs, AND reliably enforced. (I'm imagining decoders that don't bother explicitly specifying all the return format properties, because in CURRENT_YEAR, only one type made sense).
- amelius 5y ago> TBH, I don't think we want external entity injection and Turing-complete languages in our image formats. Meanwhile, people are using WebAssembly and Javascript all the time, from untrusted sources.