bcpkix-jdk18on resolves wrong dependencies using maven

[GaZaTu]

Since bcpkix-jdk18on v1.80 the dependency of bcutil-jdk18on specifies the following version <version>[1.80,1.81)</version> instead of a static 1.79 like before.
This causes our maven to actually resolve the dependency as 1.80.0.redhat-00001 instead of 1.80. (we're using nexus as our repository proxy)
And this in turn causes our Java9 module loader to not find bcutil-jdk18on because the .jar name is not as expected.

potential fixes:

• either add Automatic-Module-Name to the MANIFEST.MF so the module loader doesn't need to parse the file name
• or fix the version field so it resolves the correct dependency (aka: it shouldn't search for the prefix)

[peterdemaeyer]

I am having the exact same problem, although I think the explanation may be a bit different.

Given:

• A project that has dependencies on 1.80 versions of bcpkix/bcutil/bcprov-jdk18on.

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcpkix-jdk18on</artifactId>
    <version>1.80</version>
</dependency>
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcutil-jdk18on</artifactId>
    <version>1.80</version>
</dependency>
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk18on</artifactId>
    <version>1.80</version>
</dependency>

• Since version 1.80, bcutil-jdk18on and bcpkix-jdk18on declare a version range [1.80,1.81) instead of a plain version 1.79 like before.
• Both versions 1.80 and 1.80.0.redhat-00001 exist in the (local) repository. For example because the build of an unrelated earlier project populated the local Maven repository with version 1.80.0.redhat-00001 of bcprov-jdk18on.

When building the affected project, then it incorrectly picks up the Red Hat versions:

• Because of the version range, Maven's dependency resolution mechanism finds 1.80.0.redhat-00001 and considers it a higher version than 1.80, picking 1.80.0.redhat-00001 to satisfy the dependency instead of the desired 1.80, resulting in actual dependencies:
• bcpkix-jdk18on:1.80
• bcutil-jdk18on:1.80.0.redhat-00001
• bcprov-jdk18on:1.80.0.redhat-00001

While the expected dependencies are:

• bcpkix-jdk18on:1.80
• bcutil-jdk18on:1.80
• bcprov-jdk18on:1.80

The workaround is to add exclusions:

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcpkix-jdk18on</artifactId>
    <version>1.80</version>
    <!-- Avoid version range issues resolving to 1.80.0.redhat-00001. -->
    <exclusions>
        <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcutil-jdk18on</artifactId>
    <version>1.80</version>
    <!-- Avoid version range issues resolving to 1.80.0.redhat-00001. -->
    <exclusions>
        <exclusion>
            <groupId>org.bouncycastle</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk18on</artifactId>
    <version>1.80</version>
    <!-- No need for exclusions here because no transitive dependencies. -->
</dependency>

The drawback of the workaround is that it clutters the pom, adding a maintainability cost.

The fix for the BC project is to revert the version range back to a plain version.

That makes me wonder, why was the version range introduced in 1.80 in the first place?

[reitzmichnicht]

There is an easy fix for it using maven dependency management seciotn:

      <dependency>
        <groupId>org.bouncycastle</groupId>
        <artifactId>bcpkix-jdk18on</artifactId>
        <version>${version.bouncycastle}</version>
      </dependency>
      <dependency>
        <groupId>org.bouncycastle</groupId>
        <artifactId>bcprov-jdk18on</artifactId>
        <version>${version.bouncycastle}</version>
      </dependency>
      <dependency>
        <groupId>org.bouncycastle</groupId>
        <artifactId>bcutil-jdk18on</artifactId>
        <version>${version.bouncycastle}</version>
      </dependency>

You need to specify the version there for all bouncycastle artifacts, then it overwrites the version of the transitive dependencies.

But I'm shocked that a security related library like bouncycastle uses so weak dependency expressions that its possible to sideload bad code from other maven repositories.

[dghgit]

We don't actually use Maven in house, while we prepare pom files, BC because of what it is has few if any dependencies.

The move to ranges was to make it easier to do partial releases, not something we do often, but useful if we need to. We can go back to single release numbers if necessary, but am I to understand that the default Maven approach to this makes it impossible to do this reliably and we need to do a full release every time we fix something? So we do need fixed release numbers?

Actually the other question I have is why is someone else building in our namespace?

[peterdemaeyer]

Yes, I suggest using fixed versions and no version ranges, especially given that it is a pom you publish.
By "partial release" I suppose you mean for example a publishing of bcprov-jdk18on:1.80.1 without republishing a bcutil-jdk18on:1.80.1.
Even when using fixed versions, you don't "need" to republish bcutil-jdk18on:1.80. It would be up to the users to combine a bcprov-jdk18on:1.80.1 with a bcutil-jdk18on:1.80, and that is perfectly acceptable.

About your question "Why is someone else building in our namespace?"
I suppose you're referring to the fact that Red Hat publishes "their" patched artifacts and corresponding version of what you consider "your" namespace org.bouncycastle. They do this in their repository. This is perfectly in line with the design of Maven - to maintain "your" forked/patched versions of open-source libraries and maintain them in your own repository. They augment the version like 1.80.0.redhat-00001 according to what imagine is their standard. Red Hat essentially republishes forks of more or less every common open-source library out there. Generally, they don't even fix anything in those forks, they usually only fix poms and align them to standards. It gives them the option to patch community versions when they need to, which is the spirit of open-source. In case of org.bouncycastle:bcpkix-jdk18on for example, they removed the version range and use a fixed version. I imagine they consider this a "fix for a non-standard pom" (using version ranges in poms you publish is definitely non-standard).

[dghgit]

1.82 has reverted back to the single version form. Now out.