
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