OpenSSL 3.x changed license and OpenSSL 1.x is deprecated. It's only used for computing the specific md5 of the EFS.
I did a quick research on various library licenses and there is no ideal library:
| Library |
Status |
License |
License status |
Supports GNU/Linux |
Supports Android |
| BoringSSL |
Stable |
OpenSSL |
Compatible with GPLv2+, GPLv3+ |
? |
Yes, unsure of the versions though |
| OpenSSL 1.x |
Deprecated |
OpenSSL |
Compatible with GPLv2+, GPLv3+ |
Yes (for now) |
Yes, no Android.{mk,bp} though |
| OpenSSL 3.x |
Stable |
Apache 2.0 |
Incompatible with GPLv2 |
Yes |
Yes, no Android.{mk,bp} though |
| WolfSSL |
Stable |
GPLv2+ |
Compatible with GPLv2+, GPLv3+ |
Yes |
Yes, has Android.bp and uses git |
And here's what currently used in Replicant:
| Replicant version |
Library used |
| Replicant 4.2 |
OpenSSL |
| Replicant 6.0 |
BoringSSL |
| Replicant 11 |
BoringSSL |
Note that BoringSSL is a Google fork of OpenSSL 1.x.
So we have some options:
| Option |
Advantages |
Issues |
| Copy the OpenSSL 1.x md5 code inside libsamsung-ipc. |
It works the same |
(will be) Unmaintained, potential security issues |
* Add WolfSSL in Replicant and link to it
* Depend on WolfSSL on GNU/Linux too |
Doable
Maintained
Has an Android.bp for Android
Probably well packaged in GNU/Linux |
1 extra dependency on Android |
| Write MD5 related code ourselves |
No external dependency |
Probably Time consuming |
Having 1 extra dependency is not a big issue on Android, especially if it already works fine (Android.bp, Android support, has a git repository etc). However adding a dependency to something not packaged on GNU/Linux will probably prevent a wider adoption of libsamsung-ipc + it's a lot of work to package 1 extra TLS library in each distribution. That would also be a problem for potential contributors. BoringSSL also gives no API guarantes1.
So the best option is probably WolfSSL or a similar library.
edit1: add info about BoringSSL API guarantees.
edit2: fix typos