Control of origin and integrity of Jenkins plugins

Using Jenkins
1

Hello

I’m currently reviewing our integration pipeline with an emphasis on controls against supply chain attacks. Looking at Jenkins plugins, I’m wondering how we can make sure a plugin version has been built from the tagged source code in git hub.
On one hand, the contributor commits the code and tag it in Jenkins · GitHub.
On the other hand, unless I missed something, the contributor builds and pushes the hpi in Index of /download/plugins.
How are we sure that the hpi pushed is indeed built from the tagged source code and it has not been modified?

Thank you in advance for your thoughts on this topic.

2

You can build the plugins from source code at the tagged location and compare the resulting build with the delivered plugin binary.

I did something like that for 100+ plugins and found that so long as I used the same major version of Java as the original maintainer used to build the release, I could confirm that the plugin I built matched the plugin as delivered by the maintainer.

See the Maven – Guide to Configuring for Reproducible Builds for more information on reproducing builds with Apache Maven.

If you’re interested in the topic for other portions of the tool chain, see https://reproducible-builds.org/ . I have very much appreciated the work of openSUSE:Reproducible Builds - openSUSE Wiki .

At a high level, maintainers “own” their plugin and historically have released them from their own machines. You can see who is a maintainer with permission to release on the plugin’s page on plugins.jenkins.io (or GitHub - jenkins-infra/repository-permissions-updater: Artifactory permissions synchronization tool and data set ).

JEP-229: Continuous Delivery of Jenkins Components and Plugins is being used in more and more Jenkins plugins to deliver plugin releases automatically on each merge of a relevant commit to the primary branch of the plugin repository. Progress will continue in that area as more and more plugins adopt the technique.

3

Thank you very much for your thorough and helpful answer!

JEP-229 is indeed a very good initiative that in most part answers my concern, looking forward it to be the unique way to publish plugins.

As per your suggestion to rebuild the plugin, in fact, I thought about that possible workaround: prevent any automated plugin installation (with a firewall rule), review the source code of the desired plugins, build them and install them manually. I wondered if it was a bit too much, but it is not far from what you suggest.