Upgrade gradle wrapper to latest version (8.13) #437
Closed
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
In prep for full Java 21 support, gradle needs to be updated to version 8.5 or later. https://docs.gradle.org/8.5/release-notes.html#java-21 https://docs.gradle.org/8.5/userguide/compatibility.html#java Updating gradle to latest version available now (8.13). Also upgrading plugin 'com.google.osdetector' to version '1.7.3' to fix gradle deprecation warnings.
chockalingamc
force-pushed
the
jdk21_upgrade
branch
from
bcde4b7 to
5aab64b
Compare
gradlew
Outdated
There was a problem hiding this comment.
were these updates auto-generated in the upgrade? if so, by which command?
There was a problem hiding this comment.
Yeah, gradlew gets generated when you initialize a gradle project. The expectation is to generate it, check it into the repo, and not touch it
There was a problem hiding this comment.
yeah, if you already have gradle 8.1 (the 'latest' label was introduced since 8.1)
gradle wrapper --gradle-wrapper latest
or you could specify the exact version if upgrading from lower versions
gradle wrapper --gradle-wrapper 8.13.
The command updates the gradle.properties, the wrapper JAR, gradlew, & gradlew.bat.
The changes related to exec commands are manual (to fix a deprecated warning for exec API and use the new providers.exec API
geedo0
approved these changes
Feb 28, 2025
geedo0
requested changes
Feb 28, 2025
There was a problem hiding this comment.
The legacy platform CI task is failing due to libc linker issues. We don't need the latest version of gradle to work on that, but we do need to ensure that we can compile ACCP's native code successfully on the version of GCC present on that machine.
Caused by: java.lang.UnsatisfiedLinkError: /root/.gradle/native/0.2.7/x86_64-linux-gnu/libgradle-fileevents.so: /lib/libc.so.6: version `GLIBC_2.14' not found (required by /root/.gradle/native/0.2.7/x86_64-linux-gnu/libgradle-fileevents.so)
See [PR corretto#434][1] for a detailed description of this commit. [1]: corretto#434
*Issue #, if available:* ACCP-129 _**THIS FEATURE IS NOT INTENDED FOR PRODUCTION AND IS THUS LEFT UNDOCUMENTED IN OUR README**_ ## Notes This PR builds on prior work from @amirhosv on the `fips-experimentation` branch to provide an alternative mode of handling AWS-LC self test failures. We call this (non-default) mode `FIPS_SELF_TEST_SKIP_ABORT`, and it is only usable when ACCP is built in FIPS mode. By default, AWS-LC will `abort()` on self-test failures. However, as of AWS-LC v1.47, when built with the `AWSLC_FIPS_FAILURE_CALLBACK` build flag AWS-LC will [call][1] a [weak symbol][2] `AWS_LC_fips_failure_callback` function to handle self test failures instead of aborting. When ACCP is built with `-DFIPS_SELF_TEST_SKIP_ABORT`, ACCP defines `AWS_LC_fips_failure_callback` such that it appends to a queue of error strings in ACCP's native heap. To manage the accumulated error strings, we add a native `std::vector` wrapper `ConcurrentStringVector` providing a minimal, threadsafe API. Once the error queue is non-empty, all subsequent `getInstance` calls on an algorithm provided by ACCP will throw `FipsStatusException`. We provide two functions for callers to query fips self test error state on an `AmazonCorrettoCryptoProvider` instance: - `public boolean isFipsStatusOk()` - `public List<String> getFipsSelfTestFailures()` We could get away with only the latter function, but we provide `isFipsStatusOk()` to avoid performance costs of copying error strings over the JNI. [1]: https://github.com/aws/aws-lc/blob/1d8b807ed1ae75c89beda6c73a4ae27c404fa46f/crypto/fipsmodule/bcm.c#L416 [2]: https://github.com/aws/aws-lc/blob/1d8b807ed1ae75c89beda6c73a4ae27c404fa46f/crypto/internal.h#L1427-L1432 ## Testing To adequately test the new mode, we need to build AWS-LC with `FIPS_BREAK_TEST=TESTS` to programmatically break AWS-LC's pairwise consistency tests (PCTs). We test against each available PCT breakage during key generation by setting the appropriate environment variable, indicating which PCT to break. Unfortunately, Java doesn't appear to have a standard utility for manipulating process environment variables at runtime, so we create our own `TestUtil.setEnv` that calls POSIX `setenv`/`unsetenv` over the JNI. In addition to CI tests, I've also executed `run_accp_basic_tests.sh` with the new `--fips-self-test-failure-no-abort` flag, which will eventually be incorporated into our GitHub CI. ``` $ TEST_JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64 ./tests/ci/run_accp_basic_tests.sh --fips-self-test-failure-no-abort ... BUILD SUCCESSFUL in 40m 15s 18 actionable tasks: 13 executed, 5 up-to-date ``` --- By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice. --------- Co-authored-by: Amir Vakili <[email protected]> Co-authored-by: Amir Vakili <[email protected]> Co-authored-by: Gerardo Ravago 🇵🇭 <[email protected]>
PR corretto#394 deliberately [coupled][1] ACCP's Ed25519 key generation to SunEC's KeyFactory in the hopes of increasing compatibility. However, this also prevents the use of Ed25519 in standalone ACCP. This PR provides a fallback mechanism to allow Ed25519 keys to be generated by standalone ACCP without relying on SunEC. If SunEC has a relevant KeyFactory registered, the old behavior is retained for backwards compatibility. Conveniently, this fallback mechanism also allows us to provide Ed25519 support on JDK versions < 15. We add a test that de- and re-registers default providers to prove Ed25519 signatures can be performed by standalone ACCP with an empty JCA registry. [1]: corretto#394 (comment)
Follow-ups from PR corretto#438: 1. Tighten self test timeout and sleeps (discussed offline) 2. Tighten and consolidate some test logic (see [here][1]) [1]: corretto#438 (comment)
|
Pushing out a new PR #442 from latest main. Closing this out. |
Yes, Gradle's native integration is compiled with GLIBC 2.14 which is not available in the older ubuntu 10.04 platform. Updated our codebuild CI task for legacy platform to include the system property |
chockalingamc
added a commit
that referenced
this pull request
Mar 13, 2025
Upgrade gradle wrapper to version 8.5 for JDK21 support *Issue #:* [332](#332) *Description of changes:* In prep for full Java 21 support, gradle needs to be updated to version 8.5 or later. https://docs.gradle.org/8.5/release-notes.html#java-21 https://docs.gradle.org/8.5/userguide/compatibility.html#java Note: Tried updating gradle to the latest version available now (8.13), but that failed CI tests with linker errors on legacy platforms (newer GLIBC_2.14 not available in older Ubuntu 10.04 platform). So staying with 8.5 until legacy builds are deprected. Also upgrading plugin 'com.google.osdetector' to version '1.7.3' to fix gradle deprecation warnings. (Closed out a old PR #437 related to this and starting clean from latest main branch) By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
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.
Upgrade gradle wrapper to latest version (8.13)
Issue #: 332
Description of changes:
In prep for full Java 21 support, gradle needs to be updated to version 8.5 or later.
https://docs.gradle.org/8.5/release-notes.html#java-21
https://docs.gradle.org/8.5/userguide/compatibility.html#java
Updating gradle to latest version available now (8.13).
Also upgrading plugin 'com.google.osdetector' to version '1.7.3' to fix gradle deprecation warnings.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.