jmailen.org domain is expired
inzlain opened this issue · comments
I've noticed that the domain jmailen.org isn't currently registered. Theoretically, someone could register this domain and try to claim rights to publish under org.jmailen.* GroupIDs on the Gradle Plugins Portal. In practice, I don't think this would be very likely to succeed and someone would probably notice what is going on. However, there is an expectation from Gradle (and also the wider Java ecosystem) that GroupIDs can be verified through domain ownership.
There may also be other risks if you have accounts like GitHub or Gradle Plugins Portal associated with an email address under the jmailen.org domain (i.e. resetting account passwords).
Recommendation: Re-register the jmailen.org domain name
There's never been a jmailen.org internet domain and hence no email addresses there.
Where does it say there's an expectation in the Java ecosystem that package paths correspond to internet domains the author owns? To my knowledge it's never been this way and generally people namespace packages in a unique way that makes sense to them.
Nothing here indicates you need to own a domain name to publish to the gradle plugin portal and in any case, access to login to the gradle portal and obtain a publishing key for your plugin are controlled through other credentials.
See here, specifically:
Plugin IDs should trace back to the author
The group and artifact must reasonably represent the organization, person, and the plugin.
...
Another example would be a corporate plugin, let's say from mybusiness.com; then the plugin ID should look like com.mybusiness.pluginname. In this case, the author should also submit the plugin via a corporate account/email address. We prefer group (as opposed to individual) addresses, to highlight that the organization (or a sub-group of it) is the owner of the plugin.
If we cannot link to the domain, we will ask for proof, in the form of a TXT record added to the DNS entry.
and
Approval Denied
...
Another typical scenario is when a plugin belonging to an organization is being published, but the publishing Plugin Portal account can't be linked to the organization. In such cases you might be asked to prove ownership of the organization's domain by adding some random TXT DNS record to your organization's domain host. Portal administrators will contact you and provide you with the exact record.
I'm not sure exactly when Gradle enacted this policy, but presumably it didn't exist years ago when you initially published the plugin. Maven Central has long had this policy of verifying domain ownership, and other parts of the Java ecosystem including Gradle have generally moved to align with Maven Central.
If I was to publish a brand new plugin today then Gradle would force me to verify domain ownership. You can see an example of this verification process being discussed here.
What I'm concerned about is how Gradle would potentially react to someone who has registered the jmailen.org domain and tries to dispute your ownership/rights to publish plugins under org.jmailen.* IDs. I hope common sense would prevail, but I can see a worst case scenario where you are forced to rename the plugin, or stopped from publishing new versions under this ID.
I still do not believe so. Domains aren't the only way to show ownership. They mention it in the context of a plugin belonging to an organization. For individuals, there are other ways such as:
Ownership can't be established
One typical scenario of this problem is when a plugin gets published from a GitHub (or similar) repository, but the GitHub account can't be linked to the Plugin Portal account doing the publishing. The solution to this is to either use a Plugin Portal account linked to a GitHub account (you can log into the Plugin Portal via your GitHub account) or to make the email address backing your Plugin Portal account publicly visible on your GitHub account.
And of course this plugin id is already associated with my authenticated identity and cannot be taken so easily.
Even on Maven Central I don't believe domains are a requirement -- I believe PGP signatures are the main way. Don't get me wrong, it's extremely common for people to align their package with a domain they own because who doesn't have a project page these days? But you have packages like this which don't: https://mvnrepository.com/artifact/commons-io/commons-io
Feel free to close the issue if you disagree there is a risk here. I don't work for Gradle, so I can't speak for how they interpret or enforce their policies.
My goal was to just make sure you knew about this 👍.