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