Maven 3.8.1 and HTTP Repositories

Hi all,

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.,

<url>http://mavenrepo.openmrs.org/nexus/content/repositories/modules</url>

To

<url>https://mavenrepo.openmrs.org/nexus/content/repositories/modules</url>

in the POM should get things back up and running.

1 Like

Thanks @ibacher for tracking out this, we have been facing this kind of acatastrophy while debugging refapp distro

Thanks @kdaud who already fixed this for RATEST-129: Resolving arttifacts for referenceapplication-ui-tests module by kdaud · Pull Request #377 · openmrs/openmrs-distro-referenceapplication · GitHub

3 Likes

thanks @ibacher for sharing this

Thanks @ibacher for this!

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

@kdaud https://mavenrepo.openmrs.org is the canonical repo for OpenMRS… just in case JFrog also decides to drop Artifactory, so I’d recommend using https://mavenrepo.openmrs.org/public.

2 Likes

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.

2 Likes

@ibacher we’re having trouble finding a suitable replacement for the rubygems dependency that’s included in a few modules (e.g. appointment-schedulingui, registrationapp). Looks like the cert for https://rubygems-proxy.torquebox.org is invalid: Changing rubygems link to work with later Maven versions by kfb19 · Pull Request #117 · openmrs/openmrs-module-registrationapp · GitHub

Looks like we’re in good company, though. Do you think this workaround from another project could work for us: Investigate using a local lightweight proxy rather than Torquebox · Issue #364 · jruby-gradle/jruby-gradle-plugin · GitHub

cc @katebelson

@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:

1 Like

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.