←back to thread

A new PNG spec

(www.programmax.net)
616 points bluedel | 2 comments | | HN request time: 0.05s | source
Show context
LeoPanthera ◴[] No.44373778[source]
> I know you all immediately wondered, better compression?. We're already working on that.

This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files.

It'll be like USB-C but for images.

replies(11): >>44373790 #>>44373796 #>>44373928 #>>44373937 #>>44374139 #>>44374147 #>>44374842 #>>44375132 #>>44375261 #>>44375615 #>>44380021 #
Lerc ◴[] No.44373928[source]
It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress.

The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

replies(7): >>44374018 #>>44374025 #>>44374290 #>>44374346 #>>44374473 #>>44374501 #>>44374528 #
pvorb ◴[] No.44374290[source]
Extending the format just because you can – and breaking backwards compatibility along the way – is even more pointless.

If you've created an extensible file format, but you never need to extend it, you've done everything right, I'd say.

replies(1): >>44374468 #
1. jajko ◴[] No.44374468[source]
What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)? I know its not so much about PNG but some future format.

That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.

replies(1): >>44374541 #
2. lelanthran ◴[] No.44374541[source]
> What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)?

Will sooner or later be used to implement RCEs. Even if you could do a restriction as is done for eBPF, that code still has to execute.

Best would be not to extend it.