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.