It’s me again reporting on yet another breaking change to our build infrastructure! This time, caused by a new update to Maven, specifically Maven 3.8.1, which was created in response to CVE-2021-26291.
Basically, with Maven 3.8.1, Maven repositories that use an http link instead of https are blocked by default. While locally it’s fairly simple to stick with Maven 3.6.3 or earlier, where we’ll get bit is with GitHub Actions (or, in a few cases Travis); both of these services seem to have updated the version of Maven in their base images to 3.8.1.
When this issue occurs there’s usually a tell-tale error in the build output like this:
Unresolveable build extension: Plugin org.openmrs.maven.plugins:maven-openmrs-plugin:1.0.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.openmrs.maven.plugins:maven-openmrs-plugin:jar:1.0.1: Could not transfer artifact org.openmrs.maven.plugins:maven-openmrs-plugin:pom:1.0.1 from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [openmrs-repo (http://mavenrepo.openmrs.org/nexus/content/repositories/public, default, releases)] -> [Help 2]
Note the mention of the maven-default-http-blocker and the apparent attempt to connect to http://0.0.0.0/. The easy way to resolve this is to update the POM of the file you’re working on to use an HTTPS rather than HTTP link. Both our Maven repo (https://openmrs.jfrog.io/artifactory/public/) and our Maven proxy (https://mavenrepo.openmrs.org/public/) have valid SSL certificates, so just changing, e.g.,
I think it would be a better approach changing the url to JFrog for time efficiency during the ci-build plan rather than JFrog which redirects to the previous one
Alright, I’ve created some scripts that fix this issue where it can be fixed and have applied it to repos in the OpenMRS organisation with some minor fallout I’m working to fix right now.
The scripts I used can be found here on GitHub and are licensed under the same license as OMRS.
@isears - a few modules have recently started replacing the rubygems dependency with an alternative approach, using either npx or using a different plugin. See some of the conversation here:
Also, at least for GitHub Actions, I have done this in the past to pin to using Maven 3.6.3 which doesn’t have this issue.
You’re right, though, that we could probably eliminate the need the for the insecure server. While we could proxy things, as we do for mavenrepo.openmrs.org, we could also just upload the necessary artifacts to our Maven instance. I’ll see if I can get this working.
The solution @mseaton points to, though, is what we should be adopting long-term, as the Sass Ruby Gem is no longer maintained.