ZLib VS OpenSSL

So the real issue here is that the lack of tree validation before the tree construction, I believe. I'm surprised that this check was not yet implemented (I actually checked libwebp to make sure that I was missing one). Given this blind spot, an automated test based on the domain knowledge is likely useless to catch this bug.

[1] https://github.com/madler/zlib/blob/master/examples/enough.c

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

A minimal viable Deflate decompressor is not exactly complex[1], although slower than mainline zlib.

[1] https://github.com/madler/zlib/tree/master/contrib/puff

ZLibrary not zlib for anyone worried about archiving algorithms. https://zlib.net/ and all the Linux repositories are safe (AFAIK).

>The following is my educated guess at what to do next and I am a week-end warrior programmer at best. If someone with more experience comments, I would listen to them over me< If you have no programming experience, this may be a lost cause. It looks like the save file has a header area followed by a list of "zlib" compressed chunks. zlib.net may have a program that can open the save file and let you see the raw information inside it. Something after the header is garbled and it is preventing Save-Editors from decompressing that chunk OR from parsing what is inside of it. If you are lucky, the garbled bit will jump out at you and you can repair it.

These appears to be the relevant changes:

2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25...

2022-08-08: https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae3...

The second commit definitely fixed a null pointer dereference, I am not sure if the CVE is referencing something else that was fixed by the first commit.

It is actually possible to estimate the compression level without actually compressing everything again, because different levels use different strategies which can be identified in some cases. zlib in particular has three strategies [1] and preflate [2] leverages this to store the deflate stream reconstruction data without much bits.

[1] https://github.com/madler/zlib/blob/21767c6/deflate.c#L134-L...

[2] https://github.com/deus-libri/preflate/blob/master/preflate_...

It's still a heap of old school C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25...

If I'm understanding the draft correctly, I think the webserver you're hosting your sites on would need it implemented as it requires private keys and ECH configuration. In the example of nginx since it uses openssl, openssl would need to implement it. I found an issue on their Github but it's still open: https://github.com/openssl/openssl/issues/7482

Source code: https://github.com/openssl/openssl/blob/master/crypto/aes/aes_core.c

Ah, I see, OpenSSL is licensed under apache[1], so they can distribute patches under non-OSS licenses. I thought it was GPL for some reason.

1: https://www.openssl.org/

thanks, and what is the reason git clone -b openssl-3.1 https://github.com/openssl/openssl cloned the 3.1.0-dev and not just 3.1.0? Because that's just how they named the branch - 3.1, and not 3.1.0?

==> Downloading https://github.com/openssl/openssl/commit/96f1dbea67247b79b1e7b3

I understand that it looks that way, especially since I just noticed you're a C++ developer who's been trying to learn it recently. But really, when on one hand you have a critical CVE caused by one wrong byte of C source code and on the other hand you have net zero memory-related CVEs in ~1.5 million lines of Rust code compared to 1 CVE per 1k SLOC in their C++ codebase, there's no denial that Rust simply does have the safety advantage for that kind of low level development. Heck, as I always say, memory safety is not a new concept at all, garbage-collected languages have had it for several decades now. But garbage-collected languages weren't fit for projects like the Linux kernel or drivers (at least I assume that is the case), which is why such a thing is exciting and good news in the first place.

Here's OpenSSL calling cryptography crypto since 1998: https://github.com/openssl/openssl/commits/master?after=9313...

And libgcrypt in 2000: https://github.com/gpg/libgcrypt/commit/bf2fc9201cfa96cd70ef...

Totally normal and not cringy at all.