Hackage is flooded with old package versions reuploads

[Duncan Coutts]

On Sun, 2015-01-18 at 21:31 -0800, Vincent Hanquez wrote:
> On 18/01/2015 20:23, Roman Cheplyaka wrote:
> > On 19/01/15 01:05, Vincent Hanquez wrote:
> >> This is not harmless. This is a security issue by itself, as now
> >> packages get changes transparently given a url, you might have a
> >> different package one day, which trigger hash check failure. or signed
> >> tag verification failure.
> > Correct me if I'm wrong, but editing version bounds on hackage doesn't
> > actually affect the tarball (and its checksum). The modified cabal file
> > is downloaded separately as part of the index.

> yes, that's right. I meant to say that what you're downloading through 
> cabal get
> tweaked by cabal, but the end result is pretty much the same

> > Not saying it doesn't introduce its own problems, but the hash check
> > should continue to pass.
> of the tarball yes, not of your compilation tree, and maybe not the 
> resulting binary.

So we have thought about it a bit when designing this feature and we
don't think that is correct.

If you freeze your solution (e.g. with cabal freeze) then changes to the
metadata should have no effect on compilation. We're pretty restrictive
about what changes are allowed and we don't think there's anything that
can cause changes except for the versions of deps picked (and hence if
you freeze then nothing).

Apart from version constraints we pretty much only allow tweaks to
metadata like description, maintainer email etc.

If you don't freeze then currently you have no guarantee that you'll not
get different solutions each time you "cabal update" to a new hackage
snapshot (or indeed installing things can change what solutions you get
since we prefer already installed instances).

One caveat is that it's possible to accidentally constrain deps and make
an existing working solution impossible. This could make a frozen
solution no longer build, which is annoying but doesn't make a broken
binary. If this proves to be a real issue then we can deal with it
(simply ignore constraints for frozen solutions).

Duncan