JRE RPM packages are not signed

[karianna]

          > @persicsb Can you check the F37 repos?

I can verify the following:

1. The temurin-{8,11,17,19}-{jdk,jre} packages are present in the repository and can be downloaded.
2. The temurin-{8,11,17,19}-jdk packages can be installed.
3. But the temurin-{8,11,17,19}-jre packages are not signed, thus cannot be installed.

Please check the signing of the JRE packages.

Originally posted by @persicsb in #566 (comment)

[bviktor]

Works for me.

[persicsb]

Works for me.

Are you sure you are installing the JRE packages?

I downloaded all the packages manuall, and verified, that Signatures are missing:

Example for temurin-17-jre (same for the others):

rpm -qpi temurin-17-jre-17.0.6.0.0.10-2.x86_64.rpm 
Name        : temurin-17-jre
Version     : 17.0.6.0.0.10
Release     : 2
Architecture: x86_64
Install Date: (not installed)
Group       : java
Size        : 139960620
License     : GPLv2 with exceptions
Signature   : (none)
Source RPM  : temurin-17-jre-17.0.6.0.0.10-2.src.rpm
Build Date  : Tue 07 Feb 2023 06:02:13 PM CET
Build Host  : 0c51bbb3850b
Relocations : /usr/lib/jvm/temurin-17-jre 
Packager    : Eclipse Adoptium Package Maintainers <[email protected]>
Vendor      : Eclipse Adoptium
URL         : https://projects.eclipse.org/projects/adoptium
Summary     : Eclipse Temurin 17 JRE
Description :
Eclipse Temurin JRE is an OpenJDK-based runtime environment to execute
applications and components using the programming language Java.

See, that it has Signature: **none**

Compare this to the JDK packages (Termurin 11 as an example):

rpm -qpi temurin-11-jdk-11.0.18.0.0.10-2.x86_64.rpm 
warning: temurin-11-jdk-11.0.18.0.0.10-2.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 65f8f04b: NOKEY
Name        : temurin-11-jdk
Version     : 11.0.18.0.0.10
Release     : 2
Architecture: x86_64
Install Date: (not installed)
Group       : java
Size        : 323175372
License     : GPLv2 with exceptions
Signature   : RSA/SHA256, Tue 24 Jan 2023 05:08:16 PM CET, Key ID 843c48a565f8f04b
Source RPM  : temurin-11-jdk-11.0.18.0.0.10-2.src.rpm
Build Date  : Tue 24 Jan 2023 04:58:51 PM CET
Build Host  : e2bd3e07d4ef
Relocations : /usr/lib/jvm/temurin-11-jdk 
Packager    : Eclipse Adoptium Package Maintainers <[email protected]>
Vendor      : Eclipse Adoptium
URL         : https://projects.eclipse.org/projects/adoptium
Summary     : Eclipse Temurin 11 JDK
Description :
Eclipse Temurin JDK is an OpenJDK-based development environment to create
applications and components using the programming language Java.

It has a proper RSA/SHA256 signature with key ID 843c48a565f8f04b.

[persicsb]

I checked, and the build script seems fine: https://github.com/adoptium/installer/blob/master/linux/jre/redhat/build.gradle#L72

I guess this is a misconfiguration for the build host or the CI pipeline, as the gppKey variable comes from the GPG_KEY environment variable, set in: https://github.com/adoptium/installer/blob/master/linux/build.gradle#L44

[bviktor]

You're absolutely right, I use -jdk, not -jre, my bad. JRE fails for me as well.

fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "Failed to validate GPG signature for temurin-8-jre-8.0.362.0.0.9-2.x86_64: Package temurin-8-jre-8.0.362.0.0.9-2.x86_64.rpm is not signed"}

[iamperson347]

Just as an FYI (based on linked issue I submitted) - this also affects Centos and RHEL.

[persicsb]

Just as an FYI (based on linked issue I submitted) - this also affects Centos and RHEL.

I guess all RPM-format JRE packages are affected.

The real question is: why are JRE packages present? Does anyone use them?

[bviktor]

I don’t think that’s the scope of this issue.

[jerboaa]

See #591 and #430. It's an intentional change. /cc @ascheman. I don't think there is anything wrong with the JRE packages, there might be an issue with the signing setup in CI which don't account for them I guess.

[ascheman]

I seem not to have access to the respective Jenkins executions (are they run on ci.adoptium.net?). If the manually triggered Jenkins job for the RPM JREs was parameterised with its default settings, the GPG signing should have been executed, cf. line 244 of the Jenkinsfile. You need to explicitly switch off GPG signing (cf. line 43) to prevent this.

Could someone with proper access permissions please check the parameter settings for the RPM JRE builds (should still be visible in the Jenkins build history)? If it was switched off, please re-exec with GPG signing.

[jerboaa]

@sxa @steelhead31 Could one of you have a look, please? Thanks!

[sxa]

I seem not to have access to the respective Jenkins executions

https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new is not restricted in terms of being able to view it - which job were you looking at?

Unfortunately we don't seem to keep a huge amount of history on those jobs (That should be fixed...) but the RedHat= ones I can see were all executed with the enableGpgSigning flag set (Althoguh a couple of them show a red failure status without any obvious re-run - I suspect @steelhead31 is in a better position to comment on that since he ran most of them)

[steelhead31]

I'll take a look once I've finished my current issue... Im fairly certain I ran them all with the signing flag set, however there were a number of bugs in the new jre installers, so it may be that it didnt work entirely correctly..

[sxa]

We should also verify the SLES ones since they are built separately

[Jeeppler]

The real question is: why are JRE packages present? Does anyone use them?

Those JRE packages are fairly new. They are easy to install and quite handy if you want to run Temurin on a Linux system (VM, container etc.).

[bviktor]

Just a note, I took a quick look around, and indeed the Jenkins jobs appear to have the GPG signing arg set, even on JRE builds.

But the Jenkinsfiles and Bash scripts etc all have nice little checks like

if (gpgFile) {
...
}
else {
...
}

So the jobs won't fail if the file is not present. I'm assuming the key mounts are messed up somewhere during the Docker build, but that's just what it is, a pure guess.

And I agree that the solution is to fix the signing of the JRE packages and not the removal of them.

[ascheman]

Just a note, I took a quick look around, and indeed the Jenkins jobs appear to have the GPG signing arg set, even on JRE builds.

But the Jenkinsfiles and Bash scripts etc all have nice little checks like

if (gpgFile) {
...
}
else {
...
}

So the jobs won't fail if the file is not present. I'm assuming the key mounts are messed up somewhere during the Docker build, but that's just what it is, a pure guess.

Yes, but it is only called with this method parameter set, if the GPG key is available, otherwise the Jenkins credential helper should already fail. Additionally, it is the very same path which is used for JDKs.

It was introduced by me to test on a Jenkins without proper GPG keys available, but the change only set the GPG_KEY parameter as optional (but it's existence is guaranteed by the caller of the method).

[sxa]

The real question is: why are JRE packages present? Does anyone use them?

There were quite a few people who missed them when we initially made the decision not to produce JRE downloads in JDK11+, so I suspect the answer is still "yes".

Ref: https://adoptium.net/blog/2021/12/eclipse-temurin-jres-are-back/

[steelhead31]

I've identified the root cause of this issue, and its related to docker caches being out of date, and not being updated. Im working on a fix, which should prevent this issue going forward.

[steelhead31]

All JDK/JRE RPMS for Java versions 8,11,17 & 19 have been signed and re-uploaded to artifactory.

[bviktor]

Can confirm.

TASK [bviktor.thirdparty : Install Eclipse Temurin 8] **************************
changed: [127.0.0.1]

TASK [debug] *******************************************************************
ok: [127.0.0.1] => (item=java) => {
    "msg": [
        "openjdk version \"1.8.0_362\"",
        "OpenJDK Runtime Environment (Temurin)(build 1.8.0_362-b09)",
        "OpenJDK 64-Bit Server VM (Temurin)(build 25.362-b09, mixed mode)"
    ]
}

TASK [bviktor.thirdparty : Install Eclipse Temurin 11] *************************
changed: [127.0.0.1]

TASK [debug] *******************************************************************
ok: [127.0.0.1] => (item=java) => {
    "msg": [
        "openjdk version \"11.0.18\" 2023-01-17",
        "OpenJDK Runtime Environment Temurin-11.0.18+10 (build 11.0.18+10)",
        "OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (build 11.0.18+10, mixed mode)"
    ]
}

TASK [bviktor.thirdparty : Install Eclipse Temurin 17] *************************
changed: [127.0.0.1]

TASK [debug] *******************************************************************
ok: [127.0.0.1] => (item=java) => {
    "msg": [
        "openjdk version \"17.0.6\" 2023-01-17",
        "OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)",
        "OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)"
    ]
}

Thanks a lot!

[steelhead31]

A little more detail about the root cause..
Basically the copying of the GPG key from Jenkins to the docker container was being skipped, as docker believed it was in the cache.... it wasnt . I had a look on the docker container created by the installers job showed the .rpmmacros file was missing this detail...  disabling the cache ensure it gets copied each time,,

[bviktor]

Ah yes, it's always the cache, I just added --no-cache to my image builder scripts a couple of days ago for the same reason :D Thanks a lot for resolving the issue this fast!