This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-07
Channels
- # announcements (10)
- # beginners (155)
- # bristol-clojurians (1)
- # calva (49)
- # chlorine (36)
- # cider (10)
- # clara (6)
- # clj-kondo (14)
- # clojars (28)
- # clojure (226)
- # clojure-australia (1)
- # clojure-berlin (12)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-uk (32)
- # clojurescript (9)
- # conjure (21)
- # crux (3)
- # datascript (3)
- # datomic (43)
- # emacs (3)
- # figwheel-main (16)
- # fulcro (17)
- # graalvm (9)
- # helix (4)
- # lambdaisland (3)
- # malli (13)
- # off-topic (12)
- # pathom (7)
- # re-frame (10)
- # reitit (9)
- # rewrite-clj (2)
- # shadow-cljs (41)
- # spacemacs (6)
- # specter (3)
- # test-check (5)
- # tools-deps (9)
- # tree-sitter (1)
- # vim (15)
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.
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.
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)
You can see an example of the maven central verification process here: https://issues.sonatype.org/browse/OSSRH-60335
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
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)
Since gpg signing isn't that useful, let's just generate a new gpg key automatically for every deploy :)
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
but I do think the automated path via dns is a reasonable automated check and certainly in line with what others things do
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
and to suggest ways to use other identities as a means of borrowing ownership: twitter-puredanger, gitlab-foo, etc
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
ah I see they do have an example at https://central.sonatype.org/pages/choosing-your-coordinates.html
seems like there are a lot of those out there https://repo1.maven.org/maven2/io/github/