Fork me on GitHub
#clojars
<
2020-10-07
>
didibus05:10:46

Realized after the fact there is a Clojars channel

didibus07:10:10

Okay, my best idea to move forward with something of that sort would be that when someone pushes to Clojars and the groupId doesn't already exists, Clojars would: If groupId is a reverse domain like org.foo Check that the domain http://foo.org has TXT DNS header for http://_clojars.foo.org with value equal to org.foo. If check fails, refuse to create the group. Else if it has a groupId like github-foo Check that the github user foo has a public repo called _clojars with a readme file that contains the value github-foo. If check fails, refuse to create the group. Else proceed to create the group as current assuming other validation pass.

didibus07:10:36

Similar things could be added for gitlab-foo and bitbucket-foo etc.

didibus07:10:41

Now that way, going forward, I know that if I depend on a lib with a groupId that is a reverse domain or a github-foo like format, that the origin was verified and I can trust it comes from the real domain owner or the real repo owner on GitHub.

Alex Miller (Clojure team)12:10:34

Just as a point of comparison, with maven central a human is involved in granting access to new groupids (but I have no idea what level of rigor is involved)

tcrawley12:10:05

You can see an example of the maven central verification process here: https://issues.sonatype.org/browse/OSSRH-60335

tcrawley12:10:41

It is similar to what is proposed above, but with human verification

tcrawley12:10:37

Clojars came about in part as push back to the maven central verification requirements (though, at the time, I think central didn't support com.github.username groups). If we want to move towards verified groups, I think we should push folks to deploy to maven central instead of modifying Clojars to do the same thing

tcrawley12:10:40

Releasing to central is a bit more painful, given that deploys go to a staging repo then have to be released manually. But there is mvn tooling to to that automatically, and it wouldn't be difficult to build a lein/`boot` /whatever plugin to do that (if they don't already exist)

Alex Miller (Clojure team)12:10:04

Actually, it is fairly difficult due to gpg signing

tcrawley12:10:26

Ah, good point

tcrawley12:10:38

Since gpg signing isn't that useful, let's just generate a new gpg key automatically for every deploy :)

didibus17:10:05

Hum, the manual process is also painful. If the above is automated, I can in 5min have a new groupId for my open source project pushed to Clojars. But with Maven Central it takes a few days of turnaround

tcrawley17:10:58

That's definitely true.

tcrawley17:10:26

I'm also considering the effort to build & maintain that system in Clojars

didibus17:10:16

Ya that's a very fair consideration.

Alex Miller (Clojure team)17:10:24

a) you should ideally only have 1 (or small number of) groupIDs

Alex Miller (Clojure team)17:10:52

b) and if a, ~day turnaround is no big deal

Alex Miller (Clojure team)17:10:52

but I do think the automated path via dns is a reasonable automated check and certainly in line with what others things do

didibus17:10:15

It seems Maven established a different convention for github? And they do com.github.user where as right now in the Clojure community I think I saw recommendation for github-user. I think I like the latter better because of the possibility for github to want to own the com.github groupId for their own projects. But I can see an argument for both

Alex Miller (Clojure team)17:10:00

I'm not familiar with the Maven convention if there is one

Alex Miller (Clojure team)17:10:25

the latter recommendation was due to not wanting to stomp on github's own "space"

Alex Miller (Clojure team)17:10:19

and to suggest ways to use other identities as a means of borrowing ownership: twitter-puredanger, gitlab-foo, etc

didibus20:10:09

I'm just going off from that link, seems they approved the creation of groupId com.github.user once the person proved they owned the repo under that user in GitHub. But I like the identityprovider-user approach personally for the same reason that you can't think that's a github published repo

Alex Miller (Clojure team)20:10:32

I never saw that before