> Since the unsafe APIs directly interface with memory directly
I'm not sure I follow this. Are you saying the unsafe APIs somehow treat memory differently than any other C API that has been wrapped with a safe C wrapper?
In any case, I'm saying their current unsafe wrapper can sit under another layer, which provides a safe API. Of course, if there's a bug somewhere in the lower layers, it could still be unsafe, but that's true of all C bindings.
Long story short: unsafe code can still be a source of vulnerabilities, even in a memory and thread-safe language. To me this sounds glaringly obvious.
I would even go a step further and say that there was no memory safety bug in the code. The attacker-provided exploit contained the memory safety issue by calling potentially unsafe APIs "incorrectly".
This does assume that all `unsafe` usages are wrapped in correctly `safe` guards though, doesn't it?
You can wrap `unsafe` functionality without checking and thus have memory issues, or if the unsafe wrapper hasn't correctly validated all possible entries that can cause memory corruption. Then any consumer of this dependency has a possible security issue with the right inputs to the consumer, which can trigger passing an exploit down to the unsafe portion.
> but once memory is corrupted, errors can manifest anywhere
Yes, but those errors can only be caused by code flagged with the unsafe keyword. Which makes debugging, auditing etc. a lot more simple than in, say, C, where it could happen anywhere.
Just because the source has unsafe blocks doesn't mean it is unsafe either. At least the amount of work to check these blocks for memory issues is a lot less then checking any other implementation.
If you don't use `unsafe` then it guarantees it barring compiler mistakes. The compiler has had issues with memory safety before, they were found, and they were fixed. There might be some left lurking, but they are extremely unlikely since people are using it in production and haven't seen anything weird.
If you use `unsafe` you have to make sure of it yourself, but you can easily grep for this keyword and see where the monsters lurk.
Oracle went the wrong direction with unsafe. Unsafe memory access is a feature of .NET and the CLR, not a hidden API where you get reprimanded by the community for using it. Not surprisingly, c# has succeeded where Java has failed in being cross platform, used for instance in game development with the unity engine or multi platform mobile development via xamarin. On the other hand, no one in the .NET community is complaining that their code is segfaulting all the time.
The jdk API developers should not be granted a special API because they are more trustworthy than the rest of us "average" developers. Unsafe should be made public, not removed and replaced.
But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.
Ah, yes, missed that. Nothing a GC can do about code like that. At least it remains true that this can only happen in Go if you explicitly import "unsafe".
> You don't generally. unsafe* functions practically are only used in libraries where you really need C-level speed. The next level of abstraction is their public API.
I agree. Who could ever think in using unsafe* functions?
The point of the GP was that any safe code using this safe API could in fact be memory unsafe is there is a bug in the unsafe implementation.
reply