[vlc-devel] RFC: Expose gcrypt through vlc_crypto.h ?

[Rémi Denis-Courmont]

Hi,

The counter argument is that we don't clobber LibVLC core with a large dependency. I already added and then was rightfully forced by the others to remove gcrypt in the past for that exact same reason. Currently, LibVLC core only depends on system/compiler libraries (c, rt, pthread, iconv, resolv, etc) or substitutes (idn).

The argument against putting a generic API is that you have to link tons loads of algorithms, regardless of how many you actually need, since the unused algorithms cannot be eliminated at link time.

Le 29 mai 2019 13:25:16 GMT+03:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>Le 27/05/2019 à 20:52, Rémi Denis-Courmont a écrit :
>pt API is crap, Nettle should be used in new code. If you only
>> need a small set of algos, that's much smaller, thread-safe and
>error-free. If 
>> you need a large set of algos, you are reinventing TLS and that's a
>not a good 
>> idea anyway.
>> 
>> Writing a wrapper around libgcrypt will end up bad, like libxml.
>
>I don't see the counter argument for providing a generic API as I
>suggested. Thit just allows replacing gcrypt backend in the end.
>
>handle = vlc_hash_start(VLC_HASH_MD5)
>/* if not hardcoded in core -> load a crypto module */
>vlc_hash_push();
>vlc_hash_finish(handle)
>
>-- 
>Francois Cartegnie
>VideoLAN - VLC Developer
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190529/d1f56e48/attachment.html>