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>

Hi Alexander,

Quoting Alexander Traud (2021-10-21 21:42:10)

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

The random number generator was another story: The libSRTP team stopped to support an internal generator and expects the application developer to supply its own. Anything can be used, like [0].

Recently, as crypto libraries, users of libSRTP added mbed TLS [2] and NSS [3]. OpenSSL was the primary library. Consequently, two packages, a non-linked, and an OpenSSL-linked would have been great. Now, with the addition of NSS, a third package, an NSS-linked could have been added.

2. The project I am using libSRTP with, Digium Asterisk, is based on OpenSSL. It is wired to use two different crypto libraries.

3. I have to re-test my VoIP/SIP phones, which use AES-GCM, whether everything works, especially because the Cisco implementation is probably using OpenSSL internally.

4. The crypto library is not only about AES-GCM but also changes AES-ICM. Consequently, I have to test not only AES-GCM but all implementations.

5. In libSRTP, a crypto library adds not only AES-GCM but also AES-NI. I have to double-check whether the other crypto libraries actually leverage AES-NI.

None of those points are hard requirements:
to 1. primary does not mean better maintained
to 2. not aware of any issue mixing libraries except more memory
to 3. to avoid that, there is that test suite in libSRTP, which the "others" passed successfully
to 4. same as 3
to 5. the "others" are mature libraries and AES-NI is nothing new

So, yes, there is no hard requirement, at least for me. Perhaps someone else has a hard requirement and tells us. If you close this wish, he has to create a new wish, correct?

[0] <https://gist.github.com/kernigh/d169895a700c6511d08511c005a28d88>
[1] <https://github.com/cisco/libsrtp/pull/34>
[2] <https://github.com/cisco/libsrtp/pull/512>
[3] <https://github.com/cisco/libsrtp/pull/413>

Quoting Alexander Traud (2021-10-25 13:06:00)

Bugreports (and other kinds of reports - the name is kinda misleading)
are always appreciated.

Thanks for that clarification.

It would be quite helpful if you could check the Debian packaging of
Asterisk and report any shortcomings related to its SIP support.

[  details appreciated yet snipped for this response ]

Closing a bugreport only flags it as nothing actionable in it¹ - it
still accepts posts even when closed¹ and continue to appear in the bug
archive².

Anyone having followup information on this can either post to this issue
or post a new issue.  iIf in doubt if really same, I recommend to post
as a new issue: It is easy to merge issues as needed, but slightly more
tricky and confusing to fork an issue.


Kind regards,

 - Jonas


¹ After some time - I think a month - a closed bugreport with no
activity gets "archived" to reduce spam - it then need to be explicitly
"unarchived" before further posts are accepted.

² By default only unarchived bugs are searched, so readers need to
explicitly request to "dig deeper" into potentially dusty discussions.