armanbilge
commented
2 years ago Yes, FTR @vasilmkd (a Scalacheck/Typelevel maintainer) made that snapshot to test the new build/publishing infrastructure while working on https://github.com/typelevel/scalacheck/pull/860. I've also similarly published snapshots of popular projects under my personal groupid purely for testing etc.
Scaladex should definitely beware these "bootlegs". IIUC each scaladex entry is linked to a specific GH repo. I wonder if the groupid of artifacts can be specifically matched to the groupid configured on the default branch of that repo.
Recently I've seen that Scaladex have entries with the non-official version of the library published with unknown to me group ids. An example can be this scalacheck entry - https://index.scala-lang.org/typelevel/scalacheck/scalacheck/1.15-6862df0?binaryVersion=_3 As can be seen the library dependency that is being shown is
libraryDependencies += "io.vasilev" %% "scalacheck" % "1.15-6862df0"which is not matching the groupId of the last official release https://index.scala-lang.org/typelevel/scalacheck/scalacheck/1.15.4?binaryVersion=_3libraryDependencies += "org.scalacheck" %% "scalacheck" % "1.15.4"I believe that it might be an unexpected snapshot release from the unhostile fork of the main repo. However, we need to remember that it is possible to publish a hostile library, which might lead to a security breach of unaware users. Scaladex should have a mechanism that would allow ignoring unexpected group ids. Typically the organization name does not frequently change, so maybe we should check N last releases to make a decision here, with an alternative of manual override.