-
Notifications
You must be signed in to change notification settings - Fork 729
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
Update to openssl 3.0.10 #14900
Update to openssl 3.0.10 #14900
Conversation
jenkins compile amac jdk11 depends ibmruntimes/openj9-openjdk-jdk11#500 |
jenkins compile zlinux,win,xmac,aix jdk11 depends ibmruntimes/openj9-openjdk-jdk11#500 |
It doesn't build on Windows
|
My rebuild for amac is https://openj9-jenkins.osuosl.org/job/Build_JDK11_aarch64_mac_Personal/57
The build doesn't yet support loading libcrypto.3.dylib (as ibmruntimes/openj9-openjdk-jdk11#499 is not yet merged) so it should be trying to load the old library libcrypto.1.1.dylib, which doesn't exist in the build. Perhaps it found some other library on the machine which is causing this error. I don't think this matters for the changes themselves. openssl3 was built, and copied into the JVM build. If it wasn't copied in, there would have been an error as seen in https://openj9-jenkins.osuosl.org/job/Build_JDK11_aarch64_mac_Personal/54
|
@keithc-ca any ideas for fixing #14900 (comment) ? |
I'll have a look. |
Windows is the only platform that uses a different compiler on jdk8 vs jdk11. jenkins compile win,win32 jdk8 depends ibmruntimes/openj9-openjdk-jdk8#559 |
Windows and AIX are the only platforms that use a different compiler on jdk17 vs jdk11. jenkins compile win,aix jdk17 depends ibmruntimes/openj9-openjdk-jdk17#88 |
All the Windows versions have the same basic problem #14900 (comment). If we can fix that, we'll be able to see if anything else is uncovered when using the different compiler versions. |
Perhaps some different 'special setup' is required for openssl 3 on Windows; see https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/openj9/closed/openssl.gmk#L30. |
Maybe we need a different version of perl. |
perl seems fine, it's the cygwin perl. It doesn't have a problem with forward slashes, even when I call it via nmake. This makefile works
and so does
|
The following makefile doesn't appear to do anything, I suspect it recognized
|
Running |
In my local build, the command echoed by
Notice numerous nested or unbalanced double-quotes. One avenue I think worth exploring is telling |
That looks very similar to the command in #14900 (comment) except for the cygwin / cygwin64 directory. Did you also get If I have a util/mkbuildinf.pl file, and run that command from bash or cmd, it "works" in that it runs my util/mkbuildinf.pl. |
Yes.
|
For the record, other uses of perl fail similarly when invoked by
Removing the double quotes fixes it. https://github.com/openssl/openssl/blob/master/NOTES-PERL.md#perl-on-windows recommends Strawberry Perl; I'll give that a spin to see if it helps. |
No dice:
|
It's behaving as if |
Using the |
As the description says, this depends on ibmruntimes/openj9-openjdk-jdk11#500, but we'll also need similar changes for other versions, and we'll need all versions to support using openssl 3.x on all platforms (not just Linux) before it would be safe to merge this. |
Also, openssl 3 doesn't build on some of the linux platforms, there is an (internal) issue open to update all the machines with the required perl modules. Then we can see if there is another problem. |
My point is that we can't change |
A new tag for |
We need to ensure that the fix for CVE-2023-2975 is included: https://www.openssl.org/news/secadv/20230714.txt OpenSSL have not yet shipped a release containing this fix due to the low severity, but the patch is available: |
We don't yet bundle version 3.* so there's nothing OpenJ9 can do to help avoid CVE-2023-2975. OpenJ9 will use 3.* when available, but it will be end users that will have to upgrade an installation of openssl 3.* to avoid that issue. |
When we start bundling 3.x for the Oct release we will include the latest CVEs. |
Yes, apologies if I wasn't clear. I meant that when we start bundling 3.x we need to make sure we include this fix. I only mentioned it here because it (currently) needs to be applied manually - it hasn't yet been included in an official OpenSSL release. |
For reference, this is what we did for 1.1.1 to include the latest CVE fix. |
jenkins compile all jdk8,jdk11,jdk17 |
Signed-off-by: Peter Shipton <[email protected]>
jenkins compile all jdk8,jdk11,jdk17 |
jenkins compile all jdk20 |
Maybe you meant to build jdk21 (jdk20 is no longer supported on the main branches)? |
That is true. jenkins compile all jdk21 |
PR builds, which passed compilation on all platforms and versions. https://openj9-jenkins.osuosl.org/job/PullRequest-OpenJ9/4267/ |
See also eclipse-openj9/openj9#14900 Signed-off-by: Peter Shipton <[email protected]>
See also eclipse-openj9/openj9#14900 Signed-off-by: Peter Shipton <[email protected]>
@@ -131,7 +131,7 @@ Now fetch additional sources from the Eclipse OpenJ9 project and its clone of Ec | |||
bash get_source.sh | |||
``` | |||
|
|||
:pencil: **OpenSSL support:** If you want to build an OpenJDK with OpenJ9 binary with OpenSSL support and you do not have a built version of OpenSSL V1.0.2 or v1.1.1 available locally, you must specify `--openssl-version=<version>` where `<version>` is an OpenSSL level like 1.0.2 or 1.1.1. If the specified version of OpenSSL is already available in the standard location (`SRC_DIR/openssl`), `get_source.sh` uses it. Otherwise, the script deletes the content and downloads the specified version of OpenSSL source to the standard location and builds it. If you already have the version of OpenSSL in the standard location but you want a fresh copy, you must delete your current copy. | |||
:pencil: **OpenSSL support:** If you want to build an OpenJDK with OpenJ9 binary with OpenSSL support and you do not have a built version of OpenSSL v3.x available locally, you must specify `--openssl-version=<version>` where `<version>` is an OpenSSL level like `3.0.10`. If the specified version of OpenSSL is already available in the standard location (`SRC_DIR/openssl`), `get_source.sh` uses it. Otherwise, the script deletes the content and downloads the specified version of OpenSSL source to the standard location and builds it. If you already have the version of OpenSSL in the standard location but you want a fresh copy, you must delete your current copy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be updated for Java 21 (Java 20 doesn't build with the current OpenJ9 repository), but that can be done in a later pull request if you like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'll do it separately.
* License: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/LICENSE | ||
* Project: https://www.openssl.org/ | ||
* Source: https://github.com/openssl/openssl or https://github.com/ibmruntimes/openssl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this still here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just being cautious. OpenJ9 has build instructions for OpenJ9 jenkins builds that set v3 but other builds can do something else. Also on some platforms OpenJ9 uses whatever OpenSSL is found installed. I figure we can remove it sometime down the line when we notice, maybe a couple of years, when OpenSSL 1.1 isn't so widely used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with deferring removal of references to version 1.x, but I don't think we can (or want to) make reference to the license of every version of OpenSSL someone might want to build with. I think we should expect those people to know what they're doing and understand the implications of building against some version and/or repository other than what OpenJ9 (advises and) uses.
I also think the comments
If you built an OpenJDK with OpenJ9 that includes OpenSSL v1.x support ...
are (at best) redundant and should also be removed at the same time we update this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't sound like you are asking me to change anything now, if that's not the case pls clarify. The diff between 1.x and 3.x is OpenSSL changed the license, otherwise we wouldn't have two entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't object if you want to remove the references to 1.x now, but I'm not asking you to do so.
The only change I'm waiting for is to fix the typo mentioned in #14900 (comment).
Signed-off-by: Peter Shipton <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No changes have been made that should invalidate the build results mentioned in #14900 (comment).
Update the notices file with the new license for v3. Updated the build instructions.
https://www.openssl.org/source/apache-license-2.0.txt