I will write software that will be released under a GNU license because the entity that bought my time to do it can decide to put the result under whatever license suits their goal.
However, if the result of my work will be made available under a more permissive license i (most likely) demand less money since it ensures that i can reuse whatever i wrote.
I will write software that will be released under a GNU license because the entity that bought my time to do it can decide to put the result under whatever license suits their goal.
However, if the result of my work will be made available under a more permissive license i (most likely) demand less money since it ensures that i can reuse whatever i wrote.
on top of my head: libgmp (not a crypto library but used by some), libgcrypt, openssl (requires a dynamic engine to do this), libssh2, libmcrypt ...
IMHO the user of an encryption library (the developer of a crypto application) should at least be able to ensure that every bit of heap that was touched by the library is zeroed after it was freed.
When i was still doing such things i preferred to use the facilities provided by the Operating System. That is: svc on Solaris, rc on FreeBSD and services on Windows. I never did anything serious with Linux but i suspect there is a way a Linux distribution manages it's services. On Solaris and FreeBSD i found it helpful to always contain the deployed software in packages -- this takes some effort first but saves one from reinventing the wheel all over again (including service management).
I would require this in every C library that provides a crypto framework or provides support functionality for such a framework. And to extend this: i would require this in every c library that touches cleartext (in an cryptographic application).
bottom line: amateurs get caught.
[1] https://www.usenix.org/conference/usenixsecurity13/practical...