cabal icon indicating copy to clipboard operation
cabal copied to clipboard

Name security in additional package repositories

Open michaelpj opened this issue 3 years ago • 2 comments

This might belong in hackage-security, not sure.

Suppose that you want to use an additional package repository P to distribute semi-private packages that you don't want to put on Hackage for some reason. Nonetheless, you still need to use Hackage for everything else.

This opens you up to an attack whereby someone else uploads a package with the same name to Hackage with a higher version number, and you unsuspectingly start using it next time you update your index.

We can't stop people uploading packages to Hackage - this could all happen innocently and the whole point is that you're deliberately not squatting the names on Hackage.

It would be nice if there was a technical solution to this. The options we have today are:

  • Put P last in active-repositories. This means that P will be preferred if there is a name+version clash, but doesn't stop an attacker from uploading a newer version, which won't clash :(
  • Use :override. This makes you secure! It means that you will never pick a version of X from Hackage so long as P contains a version of X. But it prevents you from ever uploading X to Hackage yourself, because your old versions of X will stick around and prevent the newer ones on Hackage from being chosen :(
  • Squat the names on Hackage :(
  • Give up and just hope nobody attacks you :(

:override comes closest to getting us what we want. Possibly there's a design tweak that would make this all work nicely. I don't have an idea right now but I thought I'd open this issue in case anyone else does.

(Q: what do other package distribution systems do in this kind of situation?)

michaelpj avatar Sep 29 '22 10:09 michaelpj

One possible design tweak would be something like :override-if-satisfies. So if P has foo-0.1.0.0 and foo-0.1.1.0, then any package with :override-if-satisfies on P would take foo from P if 0.1.0.0 or 0.1.1.0 satisfy its plan constraints. Then if we are ready to move foo from P to hackage, we can simply release 0.1.1.1 there and tell people to set a lower bound.

shlevy avatar Sep 29 '22 10:09 shlevy

Another design idea: tweak :override so it only triggers if the repository has a non-deprecated version of a package X. Then if you want to move X to Hackage, you just deprecate all the versions in P. This makes some sense, since deprecation is a sort of "soft-removal" that's compatible with the append-only nature of the index.

michaelpj avatar Sep 29 '22 10:09 michaelpj

I think that tweak to override would be a fine and welcome PR. It help solve a use-case and doesn't appear to have any drawbacks.

gbaz avatar Oct 26 '22 17:10 gbaz