This may be slightly tangential, but this seems like the kind of code that would benefit greatly from fuzz testing, like go-fuzz <https://github.com/dvyukov/go-fuzz>. For this kind of code, go-fuzz <https://github.com/dvyukov/go-fuzz> can really help harden it against bad, malformed and malicious input. I have used it to really good effect. It requires thoughtful choices for the initial corpus, and a machine where you can let it run for a long time, preferable just leave it running for weeks.
On Wednesday, February 12, 2020 at 9:52:51 PM UTC-5, Dan Sugalski wrote: > > Specifically ones that are compatible with the Go license. The more broken > they are the better. Bonus points for ones that trigger degenerate > behaviour in the decoding libraries. > > The tldr here is that I'm making a bunch of changes to the basic image > libraries to add in metadata support. Since I'm in there anyway I figure I > may as well add in some safety measures against files that consume an > unreasonable amount of time and/or space to decode. (Or encode if anyone's > got an image.Image that triggers bad behaviour) Having a good suite of > known-bad files to check against will be handy to make sure the code > actually works which is, y'know, kinda nice. > > (I am aware of some bad files kicking around the web, and I've grabbed > some for testing, but none I've run across so far have licenses on them > that'd allow me to toss them up on github as part of the tests for this > stuff. Hence the asking around) > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/65419653-a48a-45b5-b1e1-7ca28dcd82c3%40googlegroups.com.
