It does have such a safety switch already: http://golang.org/pkg/image/png/#DecodeConfig

I'm not sure there's anything to be done here that wouldn't be redundant with that. You could imagine a new Decoder type with some optional limit options, and have Decode return an error if limits are violated, I guess. That might be a little more friendly.

/cc @nigeltao @mpl

(this applies to all image decoders, really... not just png)

It does have such a safety switch already: http://golang.org/pkg/image/png/#DecodeConfig

Ah, yes. It seems there's no way to continue reading the entire image from the same reader without seeking to the start of the stream, though.

There is a way, once you learn the rest of the standard library. :-)

Imagine you have a streamReader which is not seekable. (e.g. it's coming from the network, via an HTTP request or response or whatever). You can read the header, verify its properties, and then decode the rest of the image with the already-read header re-stitched on to the front like this:

var header bytes.Buffer
conf, err := png.DecodeConfig(io.TeeReader(streamReader, &header))
if err != nil || !confValid(conf) { ... }
im, err := png.Decode(io.MultiReader(&header, streamReader)

See the docs for io.TeeReader and io.MultiReader to see how that works.

@bradfitz
Wow, cool. I think the issue can be closed, then.

Yeah, what @bradfitz said.

As for a nicer API, this is issue #5050.