Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade gradle wrapper to latest version (8.13) #437

Closed
wants to merge 8 commits into from

Conversation

chockalingamc
Copy link
Contributor

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.

@chockalingamc chockalingamc requested a review from a team as a code owner February 28, 2025 20:06
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.
gradlew Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

were these updates auto-generated in the upgrade? if so, by which command?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@chockalingamc chockalingamc Feb 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@geedo0 geedo0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM assuming the CI failures are false alarms.

Copy link
Contributor

@geedo0 geedo0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Chocka Chidambaram and others added 7 commits March 11, 2025 16:23
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)
@chockalingamc
Copy link
Contributor Author

Pushing out a new PR #442 from latest main. Closing this out.

@chockalingamc
Copy link
Contributor Author

chockalingamc commented Mar 13, 2025

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)

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 org.gradle.native=false while running gradle. This disabled native integration and let gradle run successfully.

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.
@chockalingamc chockalingamc deleted the jdk21_upgrade branch March 13, 2025 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants