powturbo / TurboBench

Compression Benchmark
326 stars 34 forks source link

Consider dropping pithy #3

Closed nemequ closed 8 years ago

nemequ commented 8 years ago

As part of my efforts to fuzz compression libraries, I recently tested pithy and found some vulnerabilities. The author has not responded to email about the issue for over a month, nor the pull request filed against the project, so AFAICT it's abandoned.

I'm not sure whether or not it is appropriate for this project to keep supporting pithy or not. It obviously shouldn't be used in production code, but turbobench isn't really intended for production code… I guess the distinction should be whether turbobench is intended to help people choose a compression library for their code (in which case it would be better not to include pithy), or as a tool for people writing compression libraries (in which case it would be better to include it).

powturbo commented 8 years ago

Thanks for reporting. TurboBench is a benchmark program intended for comparison of different compressors and algorithms. Compressors are included just for benchmarking. Lot of compressors are not efficient enough to be considered for production code. Anyway, in my published benchmarks, I'm showing only the best, most efficient or popular compressors. I'll consider a separate compile option for unstable compressors like pithy.

nemequ commented 8 years ago

I get that you want to include as many as possible, that makes sense. The problem is that pithy actually is an interesting codec which is efficient enough for production code in many cases, even if your results don't show it. Its performance is excellent for small pieces of data, it's liberally licensed, and it is relatively small and easy to integrate.

When people see that they're liable to be interested in the codec, but they have no way of knowing that doing so could open them up to security vulnerabilities.

IIRC lzmat (at least) also has some issues, though it's rather less interesting than pithy. I'm sure others do as well… Instead of trying to maintain a list of vulnerable codecs yourself, maybe you want to provide a somewhat prominent warning that some codecs are not secure, and link to the CompFuzz Results page? I'm currently just trying to get through all the codecs with Squash plugins and get the issues fixed, but I'd be willing to make more of an effort to include codecs which aren't part of Squash.

powturbo commented 8 years ago

Well, I'm including only interesting codecs, those with a simple (In memory) interface or recent codecs. I'm spending only few minutes to include a codec into turbobench. Nice idea, I'll put a link in TurboBench to the "ComFuzz Results" page.

powturbo commented 8 years ago

link added to references in readme