Bump up version of the libipp-crypto dependency #37940
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Mikhail Krinkin <[email protected]>
repokitteh-read-only
bot
added
the
deps
|
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to |
|
/lgtm deps |
repokitteh-read-only
bot
removed
the
deps
|
Hi, @giantcroc and @soulxu, can you please take a look and, if you don't have concern, approve? Thank you! |
|
/wait (for @giantcroc and @soulxu) |
|
Hi @giantcroc, a friendly ping, just in case it fell through the cracks. Thank you! |
|
lets push this through - if there is any issue we can revisit |
bazmurphy
pushed a commit
to bazmurphy/envoy
that referenced
this pull request
Jan 29, 2025
The currently used version of libipp-crypto library has an issue when we build it using fresh versions of LLVM toolchain (specifically I tried 18). clang-14, that is currently used, is somewhat old-ish (the latest official release is from mid 2022) and in envoyproxy#37911 I'm looking and making changes that will make it possible to build Envoy with newer versions of LLVM toolchain. Now, when it comes to libipp-crypto library, the version Envoy currently uses internally defines a `__INLINE` macro. Identifiers that start with two underscores are typically reserved for compilers, standard library and similar use cases, but it didn't cause problems with the older version of LLVM toolchain. However, on LLVM-18 some system headers that libipp-crypto relies on also define `__INLINE` macro (and then undefine it) which causes conflicts and results in a compilation failure. The issue has been addressed upstream and to fix it in Envoy we just need to switch to a newer version of libipp-crypto to include intel/cryptography-primitives@ea7cd15 (and does not contain intel/cryptography-primitives@7d6ac34). This change bumps up the version of the libipp-crypto to a recent release that contains the fix In addition to newer clang versions I also did test that `--define=boringssl=fips` builds work with existing clang version (clang-14, `--config=docker-clang` and `--config=docker-clang-libc++`), plus checked that the `--config=docker-gcc` still builds. I tested both regular envoy and contrib versions, though this dependency is only used by contrib. For the functional tests I rely on the tests that will be run automatically by GitHub. Related to envoyproxy#37911 Fix envoyproxy#37628 Signed-off-by: Mikhail Krinkin <[email protected]> Signed-off-by: Mikhail Krinkin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commit Message: Update version of libipp-crypto dependency
Additional Description:
The currently used version of libipp-crypto library has an issue when we build it using fresh versions of LLVM toolchain (specifically I tried 18). clang-14, that is currently used, is somewhat old-ish (the latest official release is from mid 2022) and in #37911 I'm looking and making changes that will make it possible to build Envoy with newer versions of LLVM toolchain.
Now, when it comes to libipp-crypto library, the version Envoy currently uses internally defines a
__INLINEmacro. Identifiers that start with two underscores are typically reserved for compilers, standard library and similar use cases, but it didn't cause problems with the older version of LLVM toolchain. However, on LLVM-18 some system headers that libipp-crypto relies on also define__INLINEmacro (and then undefine it) which causes conflicts and results in a compilation failure.The issue has been addressed upstream and to fix it in Envoy we just need to switch to a newer version of libipp-crypto to include intel/cryptography-primitives@ea7cd15 (and does not contain intel/cryptography-primitives@7d6ac34). This change bumps up the version of the libipp-crypto to a recent release that contains the fix
Risk Level: Low
Testing:
In addition to newer clang versions I also did test that
--define=boringssl=fipsbuilds work with existing clang version (clang-14,--config=docker-clangand--config=docker-clang-libc++), plus checked that the--config=docker-gccstill builds. I tested both regular envoy and contrib versions, though this dependency is only used by contrib. For the functional tests I rely on the tests that will be run automatically by GitHub.Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
Related to #37911
+cc @phlax @mathetake
Fix #37628