Daniel Stenberg via curl-library wrote:
> On Mon, 22 Oct 2018, Gabriel Zachmann via curl-library wrote:
>
>>> Actually would be possible to allow an application to supply an
>>> allocator and deallocator callbacks to libcurl via an option?
>>
>> Sure. I don't know why I forgot about that option. I like that way and
>> think that's the way to go.
>
> curl_global_init_mem - https://curl.haxx.se/libcurl/c/curl_global_init_mem.html
>
> I suppose what could still be looked into further is if/where we keep data
> around longer than we need to before we free it.
>

Shooting from the hip as a non-developer, perhaps the starting point might be:

- Establish a standard libcurl secure erase routine convention which could
be a callback. It could default to a secure erase routine if available
(memset_s), otherwise be plain memset(a,0,n). It would not necessarily zero
memory, it could write random(ish) data instead if desired. Perhaps its
definition would be that it is only used to do otherwise unnecessary
erasures, it would be a nop in environments where this level of security is
not required. (Or have a second secure_memory_cleanup() function with this
meaning...? )

- establish standard allocator & deallocator calls, again settable as
callbacks, defaulting to the normal allocators (malloc/free) with something
like a prefix of bytes to erase being set by the secure allocator. But make
a second, allocator for stuff that doesn't have to be secure (sets bytes to
erase count to zero?) This second one would be the normally used workhorse.
  The single deallocator could tell whether erasure is needed, so one
doesn't have to worry about failing to call the matching one. Maybe these
[de]allocators would only be used in secure routines, the remaining code
could continue to use the normal malloc/free or whatever, unaffected by
these changes.

With these four calls, even as simple wrappers/macros for the current,
non-wiping usage, developers could start placing these calls in code where
they think they are needed. If nothing else, this would flag security
sensitive areas in the code. The underlying functions could be worked on
over time as experience is gained, especially with different
systems/compilers. Make an example source file (based on whatever libcurl's
versions do) so users can modify it and set their own callbacks.

Maybe a simple global setopt would tell libcurl whether to use insecure
routines or not. (0=insecure 1=libcurl secure versions 2=user?) There
would be setopt calls to set user callbacks for these functions. Does this
functionality need to be per easy handle, so that insecure protocols don't
pay any penalty??

Rats, didn't look at curl_global_init_mem() until now. Maybe add secure_
versions? (Except free(). For sanity, it should be able to do the right
thing with a secure or insecure allocations?) I just threw in a secure
erase option (or two). Do you need variable arguments here for expansion or
maybe define a struct table of these calls to allow expansion?

Insecure (current) behavior:
curl_global_init_mem(CURL_GLOBAL_DEFAULT, CURL_INSECURE_MEMORY_FNS);

Use built-in secure routines:
curl_global_init_mem(CURL_GLOBAL_DEFAULT, CURL_SECURE_MEMORY_FNS);

User specified:
curl_global_init_mem(CURL_GLOBAL_DEFAULT, &user_secure_fn_table);

(If one went the crazy of per easy handle control, having these functions as
a handy table would allow easy switching.)

Maybe you could do something with variable args and flags bits specifying
what follows (including non-memory related things) or variable args with a
stopper value so the list can grow.

Cheers!
Rich
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-22