On Mon, Oct 22, 2018 at 08:13:45AM +0200, Gabriel Zachmann via curl-library wrote: > On 10/19/18 11:49 AM, Erik Janssen wrote: > > > That said, explicit wipe of the most sensitive parts, probably controlled > > by the application through options, would be low-cost, and reduces the > > chance of exporting them in core dumps, etc. > [...] > still keep sensitive information in their own memory. However, for > applications that clear their own copy, an option would be nice for > libcurl clearing the memory, maybe by an explicit call in the suggested way:
Actually would be possible to allow an application to supply an allocator and deallocator callbacks to libcurl via an option? This way the application could control the sensitive data storage. E.g. by allocating a memory from core-locked (non-swappable) region. It could also scrub the data from the memory instead of libcurl. The callback could also be used by underlying crypto library for storing session keys etc. In other words the application would become responsible for the safety measures. libcurl would only use the callbacks instead of a native allocator (if provided). --Petr
signature.asc
Description: PGP signature
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
