Deploy artifacts to maven central
Closed this issue · 12 comments
Describe the bug
It seems version 1.1.2 on https://repo.karuslabs.com/ was re-uploaded with a new version - the files in my Gradle cache diverge from those on the Karuslabs repository; I am seeing differences in elementary, elementary-project, satisfactory, and there may be more.
This is going to throw off all build tools that depend on that repository; e.g. Maven will not re-download anything unless explicitly instructed to, while Gradle will delete unused files after (typically) 7 days of non-use and re-download them later.
I.e. depending on the caching specifics of any build tool, people will see some old version, or a new version, or a mixture of old and new; and they will see different artifacts from different versions of 1.1.2 depending on download history.
A screenshot that shows my Gradle cache (which happens to use the SHA1 hashes as directory names):
Expected behavior
Once a version is uploaded to a Maven repository, it is there for eternity; any modified uploads must use a new version number.
As an exception and as a last resort, one can delete an artifact version from a Maven repository. This can be necessary if a version accidentally contains passwords, private SSH keys, GDPR data, or trade secrets.
Suggestion
Publish your Maven artifacts to Maven Central.
This prevents not just overwrites, but also supply-chain attacks like "hack into https://repo.karuslabs.com/ and insert malware into the .jar files".
If I remember, this was a one-off thing to correct a dependency issue occurring with 1.1.2. The code in both deployments are (almost) identical with the removal of some compile-time scoped annotations.
. Deploying 1.1.3 was also an option but in my rush to fix the issue, I didn't really think too much about it.
That said, it'll be worth investigating deployment to maven central when we are closer to deploying 1.2.0
Maybe it would help to use GitFlow or GitHubFlow for the branching strategy, so that there's a specific release branch on which to make releases.
That way your automation could use those branches to guarantee that releases are only made on those branches and only when tagged with a specific tag (so it would be impossible to release 1.1.2 on a commit that isn't tagged with 1.1.2)
It was moreso that I intentionally redeployed 1.1.2 without thinking too much about the aftereffects rather than an accidental deployment. That said, I feel that the project should towards a more trunk-based development flow.
The original stable branch was created because I disliked having documentation next to code when I first started the project. That view however has since changed (thankfully) in the 1-2 years since. I'm planning to deprecate the stable branch and tag releases on master in the future.
Yea, right now stable acts a bit like the master branch and master like a develop branch. I don't think that there is anything wrong with that divide though, but it would probably be better to keep the industry standards when it comes to naming these.
Publish your Maven artifacts to Maven Central.
This prevents not just overwrites, but also supply-chain attacks like "hack into repo.karuslabs.com and insert malware into the .jar files".
Huge 👍 to that. This library is used in testing parts of the Jenkins ecosystem and it would be really appreciated if this could be deployed to Maven central to avoid configuration of custom mirrors as well as avoiding burden on your own infrastructure.
Additionally it seems your Nexus instance is forbidding Artifactory user agent (used by Jenkinsci infrastructure), which prevents effective proxying of the repository (see jenkins-infra/helpdesk#3115 (comment))
Publish your Maven artifacts to Maven Central.
This prevents not just overwrites, but also supply-chain attacks like "hack into repo.karuslabs.com and insert malware into the .jar files".Huge 👍 to that. This library is used in testing parts of the Jenkins ecosystem and it would be really appreciated if this could be deployed to Maven central to avoid configuration of custom mirrors as well as avoiding burden on your own infrastructure.
Additionally it seems your Nexus instance is forbidding Artifactory user agent (used by Jenkinsci infrastructure), which prevents effective proxying of the repository (see jenkins-infra/helpdesk#3115 (comment))
I'll probably get around to deploying Elementary & Utilitary 2.0.0 this weekend & get the ball rolling on Maven central deployment then. Had to postpone work on it due to school & work commitments.
That said, Satisfactory will probably still remain at 1.1.2 since it is far from complete.
Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?
Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?
It's probably not the user agent but some authentication issue, possibly confounded by firewalls swallowing or mutilating requests.
You'll have to look into the logs of the Pante repository software (Nexus IIRC), and possibly into the logs of your firewall.
@Vlatombe it will help tremendously if you can tell @Pante when exactly the last request was sent, or what public IP or IPs your Artifactory instance is using to talk to the Pante repo (logs tend to contain all sorts of unrelated traffic). @Pante if your firewall was configured competently, then the X-Forwarded-For header will be in your logs. (You may have to configure the web server to show that header; firewalls are expected to add it to requests. The firewalls need to terminate the encryption to do this. If they don't, they need to keep the original IP packet intact, including sender IP, and accept outgoing packets to that IP; in that case, there's no X-Forwarded-For.)
If this sounds complicated: That's why people tend to avoid hosting their own repositories ;-)
Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?
It's probably not the user agent but some authentication issue, possibly confounded by firewalls swallowing or mutilating requests. You'll have to look into the logs of the Pante repository software (Nexus IIRC), and possibly into the logs of your firewall. @Vlatombe it will help tremendously if you can tell @Pante when exactly the last request was sent, or what public IP or IPs your Artifactory instance is using to talk to the Pante repo (logs tend to contain all sorts of unrelated traffic). @Pante if your firewall was configured competently, then the X-Forwarded-For header will be in your logs. (You may have to configure the web server to show that header; firewalls are expected to add it to requests. The firewalls need to terminate the encryption to do this. If they don't, they need to keep the original IP packet intact, including sender IP, and accept outgoing packets to that IP; in that case, there's no X-Forwarded-For.) If this sounds complicated: That's why people tend to avoid hosting their own repositories ;-)
Yikes, I think I'm just going to stick to publishing it on Maven central...
I've submitted the project to Maven Central and it's pending approval, see https://issues.sonatype.org/projects/OSSRH/issues/OSSRH-92508?filter=allopenissues. The downside is that I had to disable HTTPS for repo.karuslabs.com for the time-being in order to add the DNS record... (Don't ask, the hosting infrastructure is ancient)
EDIT: https access is available again.
Hopefully Maven Central will accept HTTP, otherwise the approval should be fast.
This initial approval is typically pretty fast otherwise, it merely checks that you own the domain so that they allow you to grab the group namespace. The actual project uploads don't need this kind of approval, i.e. you should be able to revert to HTTPS quickly.
The actual project uploads don't need this kind of approval
Right, after onboarding you just need to securely manage signing & upload keys (pending sigstore/sigstore-maven#12).
Elementary 2's on Maven central.