Hi everyone,
As far as I know, Hipparchus’ CI/CD pipeline only publishes artifacts to our Nexus instance, not to the Sonatype site. The advantage of modifying the CI/CD script to publish artifacts to both repositories would be, as with Orekit, to have the same artifacts in both cases, with the same checksum and cryptographic signature.
We don’t publish to SonaType? How do the artifacts become publicly available?
Sorry, I really do not have time to look at this right now, hence I just ask.
From my understanding, we publish the artefacts to sonatype during release process. But the other artefacts (e.g., snapshots) are only published to our nexus by the CI
Sure, artifacts are published on Maven Central. However, as far as I know, and as with Orekit, it is not those generated by the CI/CD pipeline that are published, but others that the person publishing the new version generates on their computer. This is a source of confusion and a problem from a supply chain security perspective:
Sébastien, do you know how we should modify our CI (probably the maven.yml file) to publish the artefacts on both Nexus and Sonatype?
And off course to publish on Sonatype only the build from main branch
That is THE question (after the question about life, the universe, and everything, the answer to which is already known). I have to investigate this point because the artifacts released on Sonatype are cryptographically signed. So, we have to handle properly (without leaking secrets) the GnuPG key in the CI/CD pipeline.
What I did in the Orekit case was to put the key in the environment variables used by gitlab CI.
I thought it was safe as I think I recall other passwords/keys were already there.
That’s something I probably missed but who sign the arfefacts if they are automatically generated by the CI?
Since the changes I made in Orekit, it is the CI that signs the artifacts.
In fact, it generates and then signs by itself. This is done so during the vote, people vote on already signed artifacts. The release manager does not generate anything by himself or herself, only the CI generates (and signs) binaries.
Ok that’s interesting. So, if generating manually the Sonatype artefacts can cause security issues due to conflicts with the ones generated on Nexus, we could try this strategy for Hipparchus
You can look at the release profile in pom.xml, the configuration of the maven-gpg-plugin.
It now uses bc as the jar signer (BouncyCastle) and signs artifacts automatically during the verify phase.
I definitly have to follow a Devops lecture somewhere on Internet 
Can someone with admin rights remove the hipparchus 4.0.2 artefacts on Orekit Nexus ?
Thank you
Bryan
Done. For your information, since Bryan is familiar with Nexus, I created an admin account for him so that he can work independently on this release (in case he needs to delete other artifacts).