> In fact, the article's conclusion that the OpenSSH team should have rolled their own memory management code rather than use tried, tested and approved librari

> In fact, the article's conclusion that the OpenSSH team should have rolled their own memory management code rather than use tried, tested and approved libraries doesn't sound like a good recommendation to me. I agree with your general statements but disagree with your ending conclusion. Notice that they never mentioned `malloc` in that post, nor `read` and `write`, etc. If you're writing code that needs to be secure, then it's important to be able to recognize what features you can use, which you can't, and thus what pieces of the standard-library are usable. `malloc` is perfectly fine, because it will never touch the memory you put inside it - If you clear the memory with a `memset` before `free` (And make sure the `memset` isn't removed), then `malloc` and `free` will never be able to copy your memory or leave it laying around. `realloc` breaks this guarantee because it explicitly will make a copy if it has to find a new place to put the buffer, and thus it's not usable if you need to keep the above guarantees about copies of the data. `fread` and `fwrite` are obviously out for the same reason - There's no guarantee they'll clear their buffers. For such a situation you definitely want unbuffered IO, and the best way to do that is to just directly do `read` and `write`. You could write your own buffer layer on top of it (that is securely cleared), but it's not necessary to use buffers at all - Especially if the file is small enough that you could just read the entire thing into a single buffer anyway. (Note that it may be possible to get those guarantees through some `setvbuf` and similar calls - I'm not completely sure since I've never tried - It's not the defaults regardless). The big problem with the approach taken is that it doesn't take enough precautions when handling secure data, and uses functions that explicitly do things they don't want.