Gradle plugin uses a proprietary dependency

[daniel-beck]

Service(s)

Artifactory, GitHub, plugins.jenkins.io, Update center

Summary

https://plugins.jenkins.io/gradle/ bundles https://search.maven.org/artifact/com.gradle/develocity-maven-extension per https://github.com/jenkinsci/gradle-plugin/blob/bb0dee0f5e6d66e3c3f43d3870f09ca948dc493c/build.gradle.kts#L124 whose proprietary license is not compliant with the Jenkins project's license requirements:

https://www.jenkins.io/project/governance/#license:

We encourage hosted plugins to use the same MIT license, to simplify the story for users, but plugins are free to choose their own licenses, so long as it’s an OSI-approved or public-domain-equivalent license or dedicated to the public domain.

https://www.jenkins.io/doc/developer/publishing/preparation/#license:

All plugins distributed by the Jenkins project need to be free and open source software. This applies to the plugin source code as well as all its dependencies.

While the metadata from the POM is ambiguous (linking to general TOS), the jar includes a file that states

Develocity Maven Extension
==========================
Copyright (c) 2024 Gradle Inc.
All rights reserved.

Use of this software is subject to the Develocity Software Agreement
located at https://gradle.com/help/legal-gradle-software-license-agreement

From my reading (not a lawyer etc.) we may even be in violation of these license terms due to section 7, even if we're a "Customer" for the purposes of this license:

Except as otherwise expressly permitted in this Agreement, Customer shall not, and shall not permit any other person to: (a) transfer, rent, sell, assign, distribute, lease, provide access to or otherwise make available the Software to any other person, (b) copy, reproduce, modify, adapt, create derivative works of the Software, except to the extent prescribed by law (c) use the Software for the benefit of any third party, (d) incorporate the Software into a product or service that Customer provides to a third party

---

Next steps:

First, we need to poke maintainers to give them an opportunity to fix their plugin / license terms, or tell me I'm wrong.

If that doesn't work, give Gradle plugin maintainers an opportunity to migrate to their own Jenkins plugin distribution mechanism if they want, and then stop distributing on our side:

1. Suspend from update center distribution
2. Remove release permissions via RPU
3. Possibly mark deprecated (mixed results with nexus-jenkins-plugin previously, TBD)
4. Move Maven artifacts from releases to a private repo
5. Archive the GitHub repository

Previous, similar issues: #3989, #3742

Reproduction steps

No response

[daniel-beck]

First, we need to poke maintainers to give them an opportunity to fix their plugin / license terms, or tell me I'm wrong.

Active folks in the plugin repo: @alextu and @welandaz recently, @wolfs previously.

[oleg-nenashev]

Hi @daniel-beck . Thank you for raising the issue. I forwarded it to the stakeholders internally. Please give us a few days to discuss the matter and follow up with the response

[oleg-nenashev]

We're looking into the options how to go forward. Given the complexity of the problem, including various distributions and use-cases on our customer-side, it would be nice if we had a few weeks to discuss the solution and to plan the new implementation without a rush. Would the Jenkins Security Team be ok with that @daniel-beck ?

@daniel-beck @Wadeck If you could please also do a private follow-up on CloudBees Assurance Program and SLAs for our joint customers, it would be great. Happy to do by email (onenashev at gradle dot com) or via Slack Connect.

[daniel-beck]

it would be nice if we had a few weeks to discuss the solution and to plan the new implementation without a rush.

Seems reasonable to me, I wouldn't want to break things for everyone here -- this is a very popular plugin after all.

Would the Jenkins Security Team be ok with that

JST is basically uninvolved. I opened this issue as a contributor.

private follow-up on CloudBees Assurance Program and SLAs for our joint customers, it would be great

I'll poke someone at CloudBees about this.

[welandaz]

Hey @daniel-beck!
We’ve just released a new version of Jenkins Gradle Plugin 2.13, which no longer bundles the proprietary dependency. Instead, it is downloaded at runtime if a user enables a certain aspect of the plugin’s functionality (e.g. auto-injection of the Develocity Maven Extension)

Will the older versions still be available for download from https://plugins.jenkins.io/gradle? If possible, we'd like to keep them as in later versions, we’ve bumped the Jenkins requirement, so not all users can update to 2.13 immediately.

[daniel-beck]

Instead, it is downloaded at runtime if a user enables a certain aspect of the plugin’s functionality (e.g. auto-injection of the Develocity Maven Extension)

This looks like a reasonable approach. Thanks for the good turnaround here.

Will the older versions still be available for download from https://plugins.jenkins.io/gradle?

Unfortunately we'll need to remove them. Is it feasible to create a 2.12.0.1 release from 2.12, with this change backported? That should take care of the vast majority of your users with its 2.303.3 core dependency (instead of 2.401.3), insofar as they're being offered a compatible release. Anyone on CasC or similar expecting specific versions to exist will encounter an issue.

[welandaz]

Ok, understood.

We will then backport this feature to the 2.12 version and release it as 2.12.0.1. Would you happen to know by when the older versions have to be deleted?
Also, will users who have them installed get some notification? (just asking in case there is some flow to this process).

We were also wondering if it's allowed to attach the .hpi files to the plugin's GitHub releases page? The question is: if the .hpi files are removed from the Plugins Index, is it allowed for us to attach them to the GitHub releases we do? (in case users want to have that specific version and are willing to install it manually). If not, do we also need to clear the releases page of those older releases?

[alextu]

Unfortunately we'll need to remove them. Is it feasible to create a 2.12.0.1 release from 2.12, with this change backported? That should take care of the vast majority of your users with its 2.303.3 core dependency (instead of 2.401.3)

Is installing a plugin depending on old Jenkins even possible?
I tried installing a locally built 2.12.0.1 plugin on a Jenkins 2.30x instance. It tries to resolve the latest plugin dependencies, which require a more recent Jenkins version, so the whole thing fails. It does not respect the "pinned" versions in the metadata file. Is it the expected behavior?
I know that in the past, I've used the plugin-installation-manager-tool to install a set of fixed plugin versions, but that seems tedious in this case: we would need to provide all the transitive dependencies of this published version and the manual procedure to install it.
@daniel-beck What's your take on that?

[MarkEWaite]

Is installing a plugin depending on old Jenkins even possible?

Yes, though you've chosen a very old base version for your test and the Jenkins update center no longer provides plugin compatibility data for that very old base version.

I have a historical list of plugins that I was able to use with Jenkins 2.303.3. I used that list with the following script to download and run Jenkins 2.303.3:

#!/bin/bash

# Gradle plugin uses a proprietary dependency
#
# https://github.com/jenkins-infra/helpdesk/issues/4263

JENKINS_WAR_VERSION=2.303.3
JENKINS_WAR=jenkins-${JENKINS_WAR_VERSION}.war
PLUGIN_MANAGER_VERSION=2.13.0
PLUGIN_MANAGER_JAR=jenkins-plugin-manager-${PLUGIN_MANAGER_VERSION}.jar

if [ ! -f ../$PLUGIN_MANAGER_JAR ]; then
  wget https://github.com/jenkinsci/plugin-installation-manager-tool/releases/download/${PLUGIN_MANAGER_VERSION}/$PLUGIN_MANAGER_JAR
  mv $PLUGIN_MANAGER_JAR ..
fi
if [ ! -d plugins ]; then
  mkdir plugins
fi
java -jar ../$PLUGIN_MANAGER_JAR --jenkins-version $JENKINS_WAR_VERSION --latest false --plugin-download-directory plugins --plugin-file plugins.txt

if [ ! -f ../$JENKINS_WAR ]; then
  wget https://get.jenkins.io/war-stable/${JENKINS_WAR_VERSION}/jenkins.war
  mv jenkins*.war ../$JENKINS_WAR
fi

JENKINS_HOME=. /opt/jdk-11/bin/java -jar ../$JENKINS_WAR

I tried installing a locally built 2.12.0.1 plugin on a Jenkins 2.30x instance. It tries to resolve the latest plugin dependencies, which require a more recent Jenkins version, so the whole thing fails. It does not respect the "pinned" versions in the metadata file. Is it the expected behavior?

Yes, that is expected because the Jenkins update center only provides data for (roughly) the last 12 months of Jenkins releases.

I know that in the past, I've used the plugin-installation-manager-tool to install a set of fixed plugin versions, but that seems tedious in this case: we would need to provide all the transitive dependencies of this published version and the manual procedure to install it.

The script above uses the plugin installation manager tool to download all the transitive dependencies. I've included the gradle plugin in an updated plugin list and confirmed that Jenkins 2.303.3 starts with that configuration.

[alextu]

Thanks for the very detailed answer! I'll adapt the script for my case so we can release a tested 2.12.0.1 soon.

[daniel-beck]

Is installing a plugin depending on old Jenkins even possible?

Jenkins project update center infrastructure only supports the last 13 months of Jenkins releases with tailored plugin releases. Right now, this is 2.420 or newer. Anything older gets offered the oldest available release, in this case a version depending on 2.401.x.

It'll be added for manual download to lists like https://updates.jenkins.io/download/plugins/gradle/ or https://plugins.jenkins.io/gradle/releases/ but that's cumbersome due to those plugin dependencies. It's only really easy in instances that have the latest currently available release already.

(Obligatory note as a security team member: Nobody should run Jenkins older than 2.452.3. Older than 2.426.3 is insanity.)

[MarkEWaite]

As far as I can tell, this issue is ready to be closed because there is no further work for the Jenkins infra team. @daniel-beck do you agree that this infra help desk issue can be closed or would you prefer to keep it open until the changes are implemented in update center?

[alextu]

We've just released 2.12.0.1 which contains the same change for older Jenkins versions. We assume the update center will still consider 2.13.1 the latest version, right? 😅

We consider it closed on our side, thanks for the help.

[timja]

As far as I can tell, this issue is ready to be closed because there is no further work for the Jenkins infra team. @daniel-beck do you agree that this infra help desk issue can be closed or would you prefer to keep it open until the changes are implemented in update center?

Old versions still need removing from artifactory right? #4263 (comment)

[daniel-beck]

would you prefer to keep it open until the changes are implemented in update center?

The latter.

Old versions still need removing from artifactory right?

Yes, that's basically how I would implement the update center changes. No Maven artifacts means no need to separately suspend distribution of individual releases.

(I think at this point most of the task list in the original comment is obsolete as the plugin was adapted to comply, and all we need to do is make non-compliant releases unavailable.)

[daniel-beck]

I archived all past releases of org.jenkins-ci.plugins:gradle in the private repo helpdesk-4263-gradle. Versions 1.12 and older (2011 and earlier) have a different group ID, but we only delete early 2.* anyway so they will remain public.

Fix versions are 2.12.0.1 and 2.13 and newer, earlier 2.x releases will be deleted.

Right now I'm trying to figure out whether Artifactory's "Delete Versions" popup is broken for everyone or just me; the checkboxes behave like radiobuttons.