Hackage is flooded with old package versions reuploads

[Duncan Coutts]

On Sun, 2015-01-18 at 16:57 -0800, Vincent Hanquez wrote:
> On 18/01/2015 15:51, David Feuer wrote:
> >
> > It would be best to be sure to make the maintainer (if there is one) 
> > aware of such changes. That said, not every package has a responsive 
> > maintainer, and *someone* has to do this work, and do it promptly. A 
> > signed hash failure does not introduce a security hole, unless you 
> > count a sort of semi-manual, avoidable denial of service.
> >
> Not sure how you got "security hole" from what I said, but a failing 
> hash or signature, means that the build system breaks while cabal 
> install stuff and that I have to manually inspect what the change is. If 
> you can't pin down a special tarball when doing a download (i.e. it can 
> changes under your feet, one day to the other), then it's an issue.
> 
> Lots of people would be *horrified* to download some 
> {c,c++,python,ruby,...} library-a.b.c.tar.gz and found anything changed 
> inside without changing the exact name for it.

Indeed they would be horrified and quite rightly so.

Fear not, we're not completely nuts. We have been working with packaging
with distros and cabal/hackage for some years now :-)

Hackage has always followed the rule that package tarballs never change.
Distros must be able to rely on this. I used to work on gentoo packaging
and that was one of their big issues. Some annoying upstream
distributors would have a policy of changing their tarballs and that
would just force all downstream distributors to make their own snapshots
and mirrors. All very annoying. So, no, that's why hackage has always
and will always provide immutable package tarballs.

The metadata editing works by keeping the metadata separate from the
tarballs.

As for security, Austin and I are currently working on an improvement
for the IHG. We're following the approach of server-based index signing,
which will also rely on those stable tarball checksums.

Duncan