Automatic Feedback on Plugin Publication
Table of Contents
Introduction
New Gradle plugins undergo a manual inspection before they get approved to be published in the Plugin Portal. Most of the performed checks are now fully automated in order to reduce wait time for plugin authors and reduce the risk of human errors. This blog post describes the new automation affecting community plugin authors and explains that it is important for the security of the ecosystem.
Plugin Publishing Security #
One of our priorities at Gradle is reducing the risk of supply chain attacks. Such insidious attacks can have a very large scale and impact. For example, a malicious community plugin may potentially infect a large number of software systems built with Gradle. You can read more about such attacks and some examples in the following blog posts.
During the past year, we at Gradle have been gradually ramping up our efforts to mitigate the risks associated with supply chain attacks. In the context of the Plugin Portal, our main objectives were:
- stronger enforcement of plugin domain ownership
- preventing plugin code dependencies from shadowing other, “real” dependencies of builds
When a new plugin is published on the Gradle Plugin Portal it goes through a manual review process. This usually happens only for the initial version. A Gradle engineer inspects the metadata and decides whether to publish it to the portal or request changes to it.
To give you a better understanding of what kind of sanity checks the engineer is doing, here are some examples:
- Is the plugin being published to misleading GAV (group, artifact, version) coordinates?
- Does the publishing user belong to the organization owning the plugin?
- Does the plugin have a clear and useful description?
- Does the plugin have the right tags?
- Is the link to the documentation valid and accessible?
Even though this approach has been working pretty well, it unnecessarily increases the time it takes to provide feedback to plugin authors, either to fix problems they might have or to get their plugins published on the Portal. The manual aspect also meant that human errors were still possible.
Full Automation #
We have decided to automate most of the approval checks as part of the plugin publication process. Publishing will now fail if any of the checks are unsuccessful and the approval process won’t even start. This provides immediate feedback to the plugin author if any obvious issues are present, instead of the current need to spend time waiting upon a manual review (and rejection).
Most of the checks are run on the server side, so the set of conditions that can be verified is pretty extensive. One of the effects of server-side checking is that these checks will be performed regardless of which version of the Plugin Publishing Plugin the author is using.
We understand that having publications refused by automatic checks might create a bit of frustration at first, but we would like to emphasize that the criteria for accepting plugins remain the same. Any plugin automatically rejected now would have been refused anyway during the previous manual approval process but after a longer delay. By providing immediate feedback, plugin authors can fix issues with plugin approval while the code is still fresh in the heads, instead of picking things up again later.
Moreover, the checking process attempts to provide comprehensive messages about all the problems it finds, not just the first one it comes across, so the number of retries should be minimal.
We have also added a Troubleshooting Guide to the plugin publication documentation, to help solve the most frequent problems.
Exceptions #
While the automation is extensive, not all plugin approval checks are safe to do in this manner. Some things will always require human judgment. We hope that, even though these changes do not remove the need for a manual approval process, they should greatly increase the number of plugins that can be approved without requiring further change. This should help plugin authors successfully publish much more quickly.
One further thing to note is that most of the automated checks still only run on the initial version of plugins, so publishing updates to plugins should remain as simple as it has been until now.
References #
- Hacker Lexicon: What Is a Supply Chain Attack?
- Yet Another Case for Using Exclude Patterns in Remote Repositories: Namespace Shadowing (a.k.a. “Dependency Confusion”) Attack
- Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies - The Story of a Novel Supply Chain Attack