On Friday, 23 March 2018 at 17:31:09 UTC, Jesse Phillips wrote:
@safe/@trusted doesn't mean "calling this function will not result in heartbleed."
If @safe doesn't protect against buffer overflows then chuck the whole thing out the window and start over.
What you're getting is that when you call this function there are no parameter values which you could pass such that you could cause memory corruption. If you are concerned about heartbleed then you don't need to review @safe code, @trusted code should be reviewed so that @safe code can't cause issue with any of the valid parameters (the way it calls @system functions should be safe). And @system code should reviewed for heartbleed. If you use zlib and it has a heartbleed bug then it is your fault for not reviewing the @system code, not the fault of D marking its usage as @system.
We can't review the zlib code which is the thrust of the issue. It's entirely possible that a bug in zlib could write past the bounds of an array. We could in theory verify zlib, but
1. It would require including the C code in the distribution that was reviewed rather than linking to the system version
2. The review process would have to be repeated every time we update to a new zlib release.
From a Phobos dev's perspective, zlib.compress2 is as much as a black box as malloc.
You mention mallac being ok to use with @trusted, but it has the same issue, if you didn't review the code behind your mallac call then it could introduce heartbleed, you don't know because you didn't review it.
Functions in the C standard library are a category difference because it's completely reasonable to assume that malloc isn't going to corrupt memory. The same assumption cannot be made with, to use the example again, libssl.
