You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow on from PR #574 where @traud suggested better documentation on what is the default.
What about adding a statement that either crypto library is used but none is leveraged on default. Some downstream maintainers like those on Debian, for example, did no enable OpenSSL for years. And now offer just NSS.
My take on this is that it would be better to enabled openssl by default and let NSS and internal be alternatives.
The text was updated successfully, but these errors were encountered:
The pro would be that more people benefit from AES-NI (and the library comes with the AES-GCM symbols then). The con would be that the user has to change its build system because a crypto engine gets a new, additionally requirement. The alternative for the con would be that the script configure detects/enables one of the crypto engines automatically. However, that would lower the pro, because still some people would miss that they would benefit from a crypto engine.
What about: The script ./configure picks one crypto engine and bails when none is installed. The user then is told and forced to explicitly override with a ./configure --disable-external-crypto-engine for example.
By the way, what about the recent addition of mbed TLS. Was that added to ./configure?
By the way, what about the recent addition of mbed TLS. Was that added to ./configure?
that was not added by the mbed TLS contributor and we have not prioritized adding it to configure. I would hope if some one needs it they will make a PR.
This is a follow on from PR #574 where @traud suggested better documentation on what is the default.
My take on this is that it would be better to enabled openssl by default and let NSS and internal be alternatives.
The text was updated successfully, but these errors were encountered: