Hipparchus 4.0.1 Signatures and Jars

Hipparchus development
1

Hi,

I’m trying to verify the signatures on the recent Hipparchus release, but the jars from packages.orekit.org fail to validate. The signatures on maven central are valid.

curl -O https://packages.orekit.org/repository/maven-public/org/hipparchus/hipparchus-ode/4.0.1/hipparchus-ode-4.0.1.jar.asc
curl -O https://packages.orekit.org/repository/maven-public/org/hipparchus/hipparchus-ode/4.0.1/hipparchus-ode-4.0.1.jar
gpg hipparchus-ode-4.0.1.jar.asc

Gives the error message:

gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: assuming signed data in 'hipparchus-ode-4.0.1.jar'
gpg: Signature made Fri 21 Mar 2025 01:28:23 PM EDT
gpg:                using RSA key 12D16069219C90212A974D119AE296FD02E9F65B
gpg: BAD signature from "Luc Maisonobe (CODE SIGNING KEY) <luc@apache.org>" [unknown]

Looking closer the jar files on maven central are different from the ones in packages.orekit.org, but the asc files are the same. SHA1 for packages.orekit.org:

a1223aa3e60e0c7df0f3c4905db29b6c9a8b3679  hipparchus-ode-4.0.1.jar
eba6b4870634243677996f4901d8758744c6739c  hipparchus-ode-4.0.1.jar.asc

and for maven central:

f9a2772eb0b8903d68b29343660b5638907623ff  hipparchus-ode-4.0.1.jar
eba6b4870634243677996f4901d8758744c6739c  hipparchus-ode-4.0.1.jar.asc

So which jar is the Hipparchus 4.0.1 release? Should the asc files on packages.orekit.org be updated to match maven central? CC @luc since his key is involved.

Regards,
Evan

1 Like
2

I have no idea about what went wrong!
There was a strange problem with 4.0 (the staging repository disappeared before release), but nothing strange occurred for 4.0.1 as far as I remember.

3

Strange, maybe one was from CI and the other from what you built?

4

This worries me, the binaries published on our Nexus instance may have been compromised. :confused:

5

Do you want me to generate a 4.0.2 just for the sake of rebuilding everything from scratch?

6

There is something I don’t understand.
How does packages.orekit.org get the signatures? Does it download from sonatype or does it build the packages by itself from the CI?
If it downloads, it should have the same files and signatures as sonatype. If it build, it should not even have signatures because they require the private key to generate.

7

As the GitHub Actions pipeline uses the ci-deploy profile, it only pushes artefacts to the Orekit Nexus instance.
Cf. :

If I’m not mistaken, the Hipparchus packages are only pushed to the Sonatype repository when the release profile is used. This is what the script release.sh does:

I therefore conclude that the packages being pushed onto the two repositories are not the same, but rather two different packages from two different builds made in two different contexts. :confused:
It is not surprising that they do not have the same checksum, but the accompanying signature should be different.
It is a process that can be improved…

8

Yes. In fact I do generally not use the script but runs the command lines one by one, following the release guide. And it is during these steps that at some point I have to provide the signature private key.

Yes. I think this is correct as long as we are dealing with unsigned snapshot artifacts, but should probably not be done with official release. And in any case, the signatures from the released artifacts should not be copied from Sonatype, and I guess the only way they can get in our repository is if they are imported.

Another possibility would be to sign the artifacts automatically when we build them in the CI, probably using specific keys for that (distinct from release keys). I think some projects do automated signing, but to be honest I always found it scary as to me it implies some private keys are lying around unencrypted in an (hopefully secured) computer.

9

I share your concern, but there are probably strategies that can be used to make the process safer and build a little confidence. I would need to do some research and look at what projects such as SLSA are proposing.