Page Comparison

...

The JarEnforcer is a Maven Enforcer which that, subject to configuration, performs the following tests on a distribution's externally-provided (dependency) jars.

Test Tests that they are signed by with a key which is in an appropriate keyRing, failing if any signatures are missing or not resolvable.
Test Tests that the version is the one specified in the pom file (because maven’s resolution of dependencies is non intuitive). This fails if versions mismatch, or if artifacts are missing.
- As a part of this test it can also do a reverse lookup and provide a trace back of to which pom-specified artifact caused a particular jar to become a part of the distribution
Finally it can check the signature of every

...

jar in your local maven repository. This can be used to check for supply chain attacks via maven plugins.

Configuration

This is done by adding the following stanza to the pom file for the project distribution.

Code Block

language	xml

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <dependencies>
    <dependency>
      <groupId>net.shibboleth.maven.enforcer.rules</groupId>
	  <artifactId>maven-dist-enforcer</artifactId>
  	  <version>2.1.0</version>
    </dependency>
  </dependencies>
  <executions>
    <execution>
      <id>idp-enforce</id>
      <phase>verify</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <jarEnforcer implementation="net.shibboleth.mvn.enforcer.impl.JarEnforcer">
            <enforcerData>${basedir}/src/main/enforcer</enforcerData>
            <parentPomDir>${basedir}/../idp-parent</parentPomDir>
            <jarDirs>${project.build.directory}/${idp.finalName}/bin/lib ${project.build.directory}/${idp.finalName}/webapp/WEB-INF/lib</jarDirs>
            <checkSignatures>true</checkSignatures>
            <checkDependencies>true</checkDependencies>
            <listJarSources>true</listJarSources>
			<artifactMap>${basedir}/src/main/enforcer/artifactMap.properties</artifactMap>
          </jarEnforcer>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

The parameters have the following meaningsupported parameters are:

Element Name	Required/?	Default	Function
parentPomDir	Yes		This is the absolute path to the directory where the parent pom for the project is stored. This is parsed and used to Establish the groupId for all artifacts (to allow signature lookup) Establish which versions of the different artifacts are expected	enforcerData ^{V2 only}	Yes	Absolute path to the folder where the keys (and if required) signatures for jars is located. See below.
dataGroupId ^V33.0 dataArtifactId ^V33.0 dataVersion ^V33.0	Yes		Maven coordinates of the project which contains the keys (and if required) signatures for jars. See below. Supercedes enforcerData
dataKeyRing^{V3 3.0}	Yes		Absolute path to a keyring with keys which will be used to check the validity of the above specified jar file.
tgzFiles^{V3 3.0}	One must be present		Space separated list of tar.gz files to be scanned. Supercedes jarFiles
zipFiles ^V33.0	One must be present		Space separated list of zip files to be scanned. Supercedes jarFiles
checkSignatures		No / “true”true	Whether to run signature checking on the contents
sigCheckReportPath ^V33.0		${project.build.directory}\signatureReport.txt	Where to write the report of the signature checking.
checkDependencies		No / “true”true	Whether to run dependency analysis and report if any versions mismatch
listJarSources		No / “false”false	Whether, as part of the dependency check to do a reverse look up of artefact artifact to source (this is a slow operation)
depCheckReportPath^{V3 3.0}		${project.build.directory}\dependencyReport.txt	Where to write the report of the signature checking.
checkM2		No/”false”false	Whether all the non-source, non-test jar files in the users maven repository (~/.m2/repository) will be checked
m2ReportPath ^V33.0		${project.build.directory}\m2SignatureReport.txt	Where to write the report of the m2 checking.

Expand

title	Advanced checkDependencies Configuration

The checkDependencies test will fail for several reasons. In certain circumstances, some strange configurations are required. Whether these start configurations are fatal or not can be controlled by four further Elements. Each element is a boolean (true/false) and defaults to true

compileRuntimeArtifactFatal. Setting this to false allows an artifact to be declared as runtime scope in some pom files and as compile scope in others. As an example, the IdP sets this element to false to cope with the logback artifacts (logback-classic and logback-core)
multipleJarVersionsFatal. If the sane artifact (with the same or different versions) is found in multiple places in the supplied distribution the enforcer will fail unless this element is set to false. For example until V4.1.5 the IdP shipped with jcommander in the war\WEB_INF\lib folder and the bin\lib folder.
pomVersionMismatchFatal. If the a declaration of the same artifact carries different versions across the pom files then the enforcer will fail unless this element is set to false. For example in the later V4.1 distributions the version of spring (set in the spring-bim file) is overridden in the idp-parent pom.
distVersionMismatchFatal. If the artifact is the distribution has a difference version to that specified in the pom files then the enforcer will fail unless this element is set to false. I can think of no reason why this might be anything but a misconfiguration.

...

Versions Compared

Old Version 13

New Version 14

Key

Configuration