AWS-LC-FIPS 3.0.0 reports "1.40.0" as its version string

[wlallemand]

Problem:

AWS-LC-FIPS 3.0.0 reports "1.40.0" as its version string, indeed openssl/base.h contains:

#define AWSLC_VERSION_NUMBER_STRING "1.40.0"

Where AWS-LC-FIPS 2.0.17 has the right string:

#define AWSLC_VERSION_NUMBER_STRING "2.0.17"

Is this something intentional, will the new 3.0 branch keep the version string corresponding to its non-FIPS version?

[torben-hansen]

Hi!

We modified the version string in PR #1888. The current source code link from the FIPS 3.0 staging branch https://github.com/aws/aws-lc/blob/fips-2024-09-27/include/openssl/base.h#L125.

I think what must have happened is that you checked out the source code using the release tag AWS-LC-FIPS 3.0. Unfortunately, for a few days, the tag AWS-LC-FIPS 3.0 was pointing to the wrong commit. Apologies.

To fix your locally checked out code, I believe you have to delete the tag and check out the release again.

[wlallemand]

Hi @torben-hansen!

Indeed we used the AWS-LC-FIPS-3.0.0 tarball from github releases, but I've had this problem since my first tests with this version. That's now resolved with the right commit since friday. Thanks!

I must say that the push --force of the 3.0.0 tag surprised us since this is an LTS branch and we spend a little bit of time trying to understand what was going on because some of our build were behaving differently. At the point I was wondering if the code was compromised.

Maybe we could have GPG signatures on the git tag or something like this so the releases are guaranteed to be emitted by AWS-LC?

Regards,

[torben-hansen]

Apologies for the inconvenience. It was an operator error on the part of the (very) limited group that can cut releases. We have subsequently improved our procedures for cutting releases to prevent it from happening again.

[wlallemand]

Good to know that the procedure was improved, that's reassuring, thanks! I'm closing the issue since this is now fixed!