Plugin Portal republication of duplicate upstream codebases

Help/Discuss Plugin Portal
1

Is there a Plugin Portal policy over publications ?

For example… Getting a generic JVM project published at Sonatype OSS used to require the source code be published and the OSS repository performed the automated build of the source, and it was the output artifacts that were then published. This provides audit ability of original project sources, and sources must be presented to make a publication of an OSS project. This policy from maybe a decade ago seems a good thing even before modern security concerns in this area. They may also provide signed artifacts by default in their process.

Does such a policy exist for Gradle Plugin Portal (or at least) the ability to classify (add a sticker, and promote higher ranking, provide filter) projects that have a binary verified sources ? Like a blue-tick style setting for a project, that the portal has performed an extra validation step.

Secondly if I look around the plugin portal, I can clearly see more than one project claim the source repository is the same upstream project, it claims to be a newer version that doesn’t actually existed as a release or tag or branch within that (victim?) target project. So this should also be an additional classification that the github account (or similar) is claimed by the publishing entity that is publishing the GPP entry.

At this stage I am not claiming there is anything concerning or problematic with the additional plugin projects. That would require some kind of bytecode/binary project analysis, however I am concerned they are given as much weight in the published listings as the original, and then appear above (due to newer release date) than the original.

There is also no button within the Gradle Plugin Portal UI to report a concern of this nature even if a concern was found to exist.

Seems very open to security concerns.

Is it possible to publish my Gradle Plugin only from such a verified system (like Sonatype OSS facilities, that build from source and signed the resulting published artifacts, to provide a minimum standard in chain of trust, you have the exact source made available along side the published binary plugin to begin a security validation).

My plugin is an OSS non-commercial effort, so no commercial funding is available to attribute to this area, as this if in effect an enrichment to the Gradle ecosystem that helps Gradle commercial offering and not myself, it seems better to continue to publish only from GHA since at least there is a chain of trust over there when publishing out of an action.

2

Getting a generic JVM project published at Sonatype OSS used to require the source code be published and the OSS repository performed the automated build of the source, and it was the output artifacts that were then published.

When was that the case?
Since I know the Sonatype OSSRH hosting, there is none such policy or even ability.
You claim your namespace for which you have to proof you own the domain at time of registration and then you just publish using Maven or Gradle from anywhere you want.
There are some validations done, like missing content of the POM, or that some sources jar is uploaded, but I doubt even the content is checked.

Like a blue-tick style setting for a project, that the portal has performed an extra validation step.

I don’t think something like that exists. At least I’m not aware of anything like that.

Secondly if I look around the plugin portal, I can clearly see more than one project claim the source repository is the same upstream project, it claims to be a newer version that doesn’t actually existed as a release or tag or branch within that (victim?) target project. So this should also be an additional classification that the github account (or similar) is claimed by the publishing entity that is publishing the GPP entry.

Like on Sonatype OSSRH you have to proof domain ownership to claim a plugin ID for publication. So if a plugin is published under some other plugin ID that is unrelated, that should be a strong sign, that it is a fork or forge.

But if multiple plugins claim to be from the same repository, that could also simply mean that the repository contains multiple plugins. And missing tags for the releases could also just mean that the maintainer did not automate the release process and forgot to push the tag.

Also, on GPP it is encouraged, but not mandatory that a plugin is OSS.

There is also no button within the Gradle Plugin Portal UI to report a concern of this nature even if a concern was found to exist.

The documentation at Gradle - Getting Help links you to the GitHub project where you can open issues and also provides you with an e-mail address you could contact.

it seems better to continue to publish only from GHA since at least there is a chain of trust over there when publishing out of an action.

It is totally up to any plugin maintainer how and from where he builds and publishes is plugins, just like it is also with Sonatype OSSRH. You can build on your local box, you can run some TeamCity server, you can publish from GHA, you can publish from CircleCI, whatever suits you best.