Hi Alexander, Quoting Alexander Traud (2021-10-21 21:42:10) > One year ago [1], you enabled NSS as crypto library. With that AES-GCM > and AES-NI are possible. However, libSRTP can be built with NSS or > OpenSSL. You played around with OpenSSL six years ago [2]. Do you > remember why it failed? Curl has several packages [3], the default for > OpenSSL and an alternative package for NSS. Is something like this > possible with your libsrtp2 package? > > [1] <https://salsa.debian.org/pkg-voip-team/libsrtp2/-/commit/afd2a46> > [2] <https://salsa.debian.org/pkg-voip-team/libsrtp2/-/commit/d79666e> > [3] <https://packages.ubuntu.com/source/impish/curl>
Linking with OpenSSL didn't fail in itself, but licensing of OpenSSL is tricky and (as I recall) some consumers of libsrtp had licensing incompatible with OpenSSL and the only real use back then (as I vaguely recall) was for a randum number function which got deprecated due to relying on private OpenSSL symbols. Yes, it is indeed possible to have the packaging build the code multiple times, linked against varying TLS engines, and then provide each as a separate package. That is extra work, however, and I am not aware of any concrete need for that. Do you see a concrete use for alternate TLS enginge linkage, then please share more details on that. Otherwise I will close this as a non-bug (which is perfectly fine - I appreciate your asking regardless). Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
