About making Phobos @safe

[Jack Stouffer]

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.