Add soname

[bkmgit]

Problem:

Would like to package this for Fedora. For shared libraries, it is helpful to have a soname. Would a pull request to add a soname be required.

Solution:

Add soname in CMake configuration for shared library builds

• Does this change any public APIs?* If yes, explain.
  Does not change any APIs, though when using shared library, linking to an explicit version will be made easier.

• Which algorithm(s) will this impact?
  Does not change any algorithms.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?
Shared libraries should have sonames, should generate .so, .so.x and .so.x.x.x - may want to use the sonames used for libssl and libcrypto used by the associated boringssl library if expect to keep compatibility, otherwise use sonames based on aws-lc releases

• RFC links: No relevant RFCs
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated? No changes needed
• Testing: No changes to tests needed.
  • Will this change trigger AWS LibCrypto Formal Verification changes? No changes needed
  • Should this change be fuzz tested? No changes needed

Out of scope:

Is there anything the solution will intentionally NOT address?

[skmcgrail]

Thanks for reaching out @bkmgit , I'm interested in learning more about your use case and packaging plan for Fedora.

The AWS-LC API is not considered stable, and we have made breaking API changes that wouldn't be considered SemVer compliant. This obviously poses challenges for packaging for OS package managers like Fedora. Are you looking to package AWS-LC for your own consumption, or is this something you were planning to contribute directly to Fedora? As indicated in #804, long-term we want to support packaging AWS-LC for operating systems (particularly Amazon Linux), but we don't have anything more specific that we can share in terms of timelines or a public roadmap.

As for the question of setting the SONAME, this is currently defaulting to an libcrypto.so and libssl.so respectively based on which library is built. We are open to setting SONAME to contain the release version number such as libcrypto.so.1.12.1 which would correspond to the v1.12.1 of AWS-LC.

[bkmgit]

It is a dependency of Apache Arrow

https://bugzilla.redhat.com/show_bug.cgi?id=2223664

Different names for the libraries would aso be great to prevent conflicts with those from OpenSSL and allow installation of both libraries.

[dougch]

S2N-tls did something similar for inclusion in AL2023 (fc35)- if you don't include minor and patch versions, it's a much more manageable change. But fair point, BoringSSL is not a semver project.

[skmcgrail]

It is a dependency of Apache Arrow

https://bugzilla.redhat.com/show_bug.cgi?id=2223664

Different names for the libraries would aso be great to prevent conflicts with those from OpenSSL and allow installation of both libraries.

It looks like Arrow doesn't actually expect AWS-LC to be linked as a shared object, but instead is linked in statically to support the AWS SDK for C++ for the S3 functionality. Additionally, it looks like libarrow would already be building with this default build behavior if my understanding is correct. Is upstream working to try to pull these all out into shared object dependencies? Another challenge that would need to be overcome outside the boundaries of our library ABI stability is that AWS SDK for C++. It has traditionally not provided in OS package managers for similar issues with trying to provide ABI stability guarantees on API interfaces that are controlled by AWS Service teams, and can be breaking at times (think preview APIs etc).

S2N-tls did something similar for inclusion in AL2023 (fc35)- if you don't include minor and patch versions, it's a much more manageable change. But fair point, BoringSSL is not a semver project.

@andrewhop provided an interesting fact that quictls intentionally prefixes their major version with the ASCII value for Q. Such that there OpenSSL 3 compatible major version SONAME is presented as libcrypto.so.81.3 which does break standard convention of using the major version naming scheme, but does ensure that an application compiled for quictls does not accidentally pick-up the standard OpenSSL distribution on a host.

[bkmgit]

In Fedora, preference is to have shared libraries, even if a static library is also provided. In many cses, one can change the builds to use shared libraries. As there are not too many consumers of AWS-LC, breaking changes can be managed at this point. Arrow has 4 releases per year and Fedora 2 releases per year, so having these work with recent AWS SDK and AWS LC seems feasible. It is possible to have more than one version of AWS-LC packaged if needed, though in this case the packager manages the name changes usually to provide a preview version or an older version used as a dependency. It would be great to prevent conflicts with other widely used software in the mainline version of AWS-LC.

[bkmgit]

Example build https://copr.fedorainfracloud.org/coprs/fed500/aws-lc/build/6182074/

[stewartsmith]

Note that this is 100% a blocker to including aws-lc in any version of Amazon Linux. Linux distributions with a shorter release cycle may work for such frequent soname bumps (assuming this is tracked correctly, which it doesn't look like it is), but for a LTS distro such as Amazon Linux, it's 100% a blocker.

So are static libraries. Therein lies pain and suffering, and we like to avoid that.