Re: libspng: a modern libpng alternative
Clifford Yapp <[email protected]> Thu, 13 Sep 2018 08:33:53 -0400
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <CAHsgyAQWh+uUJnAZUZ2z-C2ss4q=5LxPoF0R+rUrXPLMC8z5eQ@mail.gmail.com> |
On Wed, Sep 12, 2018 at 9:59 AM Randy via png-mng-implement <png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote: > > libspng(https://libspng.org) is a C library for reading and writing Portable Network Graphics (PNG) format files with a focus on security and ease of use. > > It is written from scratch in C99 as an alternative to libpng, it does not share > any code. It is faster at decoding than libpng when compiled with profile-guided optimizations. > > Currently in alpha, it can decode any PNG image to 8/16-bit RGBA, it supports > gamma correction and the equivalent of png_set_tRNS_to_alpha(). Encoding and > "PNG editor" support is planned. Sounds interesting! I definitely agree keeping explicit structure definitions hidden via something like the PIMPL pattern (https://en.wikipedia.org/wiki/Opaque_pointer#C) would be a good way to go. For ease of integration I would suggest considering the possibility of keeping to a one header + one C file implementation, or perhaps even a stb style "all-in-one-header" approach, but I know there are multiple schools of thought there... One other suggestion that occurs to me (although I don't know enough about the details of the body of CVE issues to know if this would truly make good technical sense) would be to incorporate into continuous integration testing examples designed to trigger CVE issues previously fixed in libpng (and any other PNG software related CVEs that seem appropriate) whenever that seems useful. In cases where it isn't needed/useful, I'd suggest explicitly documenting why that particular CVE isn't relevant to the new codebase. I'm remembering comments from a discussion about lodePNG at https://news.ycombinator.com/item?id=8600634 - a combination of CVE history-aware regression testing, fuzz testing and overt, documented attention to things like the CERT C coding standards may be key to achieving user adoption. libpng's string of known corrected CVEs makes many folks wary of starting over with a new code base and needing to repeat the repair process, so it will probably be necessary to articulate/demonstrate in concrete detail what "focus on security" means/achieves.