3rd party artifacts are indexed together with official library versions - possible security breach

[WojciechMazur]

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=_3 libraryDependencies += "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.

[armanbilge]

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.