Secure memory: Yay or nay

OpenSSL has support for a concept that is referred to as _secure memory_ or _secure heap_. Essentially, every time OpenSSL allocates memory, it indicates whether that memory should be allocated from the "normal" heap using `malloc` or from the "secure" heap. Allocations on the secure heap usually have the following security properties: - Allocated memory is never swapped to the disk and never included in core dumps, making it less likely to leak sensitive information through those. - Allocated memory is always overwritten on deallocation, also making it less likely to leak information. - It is far more difficult to use buffer overflows to retrieve data from these allocations. (OpenSSL causes the process to terminate if memory surrounding secure allocations is accessed.) Node.js does not use this feature, meaning that OpenSSL performs normal allocations. (OpenSSL still overwrites the memory on deallocation.) We can enable OpenSSL's implementation, but it is quite restrictive and will be difficult to configure for users of Node.js. The alternative is to provide a more suitable implementation within Node.js, which provides similar security properties while being easier to use and less restrictive. However, that requires: - Upstream changes to OpenSSL's memory management, in order to allow overriding the built-in secure memory implementation. I have talked to some of the maintainers, and they would likely accept such changes. - The actual secure heap implementation in Node.js. That is not super difficult, but the implementation is platform-specific and will not be easy to test. I started working on this approach about a year ago, and never finished it. I got varying feedback at the Montreal summit, so let's discuss this in public before I either stop working on it or put in a lot more work. As someone pointed out, many cloud applications likely don't care about this level of security. Even if we upstream the necessary changes in OpenSSL, it is unlikely to ever work with…