On Tue, Mar 23, 2021 at 1:34 PM Rainer Deyke via Boost
For me, the big question for a zlib derivative is where it stands in relation to the original zlib in terms of bugs and security.
Great question. So, the current implementation in Beast (which will become the starting point for an independent library) started out as a copy of the ZLib sources, followed by my changes to port it to header-only C++. I changed very little although I did rework some lines of code to be more idiomatic and concise using C++ features. I also removed the gzip file format support since Beast websockets did not need it, and it wouldn't have enough testing. The plans for this library in terms of bugs and security include: * Put back the gzip support by porting the relevant original zlib code again * Add Drone CI, GitHub Actions CI for C++11 and later compilers (same as Beast and JSON) * Add Code Coverage * Add Github Actions fuzzing * Manually translate and apply each of the newer commits in the upstream ZLib repository * Refactor statements to be code-coverage friendly * Add concise tests using coverage as guidance (100% coverage target) * Add tests for existing zlib input vectors * Add tests vectors for known attacks * Other tests as deemed useful Additional plans include: * Benchmark program plus CI integration to detect performance regression * Refactor public API to be idiomatic for C++ * Rewrite Javadocs to be readable * Create new exposition to show how to use the library * Add examples for common tasks As with my other libraries, this will be submitted to Bishop Fox for a periodic security review and report. In addition, there will be a dedicated maintainer so that issues can be addressed quickly and the library can be refined. Although I don't imagine there is much room left for innovation beyond cosmetic improvements since ZLib is very mature. Thanks