Hot Fuzz

Right after releasing cashpack 0.4 I decided to add a new fuzzer to the toolbox, hoping to maybe find something after a while. I found something immediately:

• a heap buffer overflow
• a broken invariant

Both cases were related to missing length checks that were easy to find and add since the code is articulated to ease such checks. Both fixes are one-liners, and the reasons why they flew under the radar until now are detailed in the test suite's README.

Incremental stability

For the last 3 years, cashpack has not seen much novelty and a pile of small improvements eventually accumulated into a sizeable bunch of invisible changes for such a small project.

One bug was found and fixed, and new functions were introduced:

• hpack_event_id()
• hpack_search()
• hpack_skip()

To make hpack_skip() possible the HPACK_RES_BIG error was renamed to HPACK_RES_SKP and became recoverable. There is one case that is not recoverable from and for that a new HPACK_RES_BIG error code was introduced for that specific semantic. This shouldn't affect previous code since the error was fatal to the HPACK consistency. New code can benefit from this change.

A new result HPACK_RES_NAM was introduced by hpack_search(). The manual pages are comprehensive as usual, you can learn more from there.

There are still more features to be implemented but this is a spare time project and this release was long overdue.

Portable reliability

With this release cashpack is more portable than ever. It complies to the standard C99 language and targets POSIX.1-2008 systems. The build system strives for the same level of portability as the library itself, targeting different make and sh implementations. Thanks to Travis CI, OSX support was added after a painful game of trial&error.

To make sure not to forget a component of portability, a release process is now documented.

Overall quality improved: besides strict compliance to C99 (-pedantic) with a slight API change all warnings are now enabled. The goal was to match FreeBSD's WARNS level 6 with additional warnings but some of them needed to be disabled. Sparse was added to the toolbox to bring even more warning checks, none of them triggered.

According to lcov, the code coverage would be 100% if it weren't for 5 uncovered branches. As a matter of fact those branches lead to WRONG statements that should never be reached. Drawing conclusions is an exercise left to the reader (hint).

Besides portability and tooling, two new functions landed in cashpack:

• hpack_decode_fields: a decoding process without a callback
• hpack_dump: a dump of the data structure (previously in the test suite)

It is now possible to inspect the dynamic table at any time, even from within a callback. The cashdumb example was partially rewritten and simplified thanks to that, and the hpack_decode_fields function.

Can cashpack grow more features before reaching 1.0? Yes, a wee bit more.

Harder Better Faster Stronger

Harder: further hardening of both the library and test suite
Better: slight redesign resulting in overall improvements
Faster: throughput bump in Huffman coding and insertions
Stronger: mitigation/reduction of two possible DoS vectors

This release has seen many improvements since the previous one. According to lcov, the code coverage for cashpack is 100%: the lines not covered are the WRONG statements that should never be reached, and the branches not covered are the ones that lead to those statements. Interoperability checks now include Go's HPACK implementation, and they all match cashpack results.

It's probably fair to say that cashpack is a 100% compliant HPACK implementation.

Changing one design goal resulted in overall simplicity:

• no more DATA event during decoding
• redundant events were merged together
• the decoding state machine is more readable
• the dynamic table code is now straightforward
• pseudo-header names can finally be validated

cashpack is now more portable, it is tested on the following platforms:

• GNU/Linux (Fedora) with GCC/clang (x86_64)
• GNU/Linux (Fedora) with GCC (i686, armv7hl, aarch64, ppc64, ppc64le, s390x)
• SunOS (SmartOS) with GCC/SunCC (x86_64)

Special thanks to @mbgrydeland for his review, @nigoroll and @gquintard for their help.

It works

v0.1

0.1