DISCUSS: Disable hackage-security expiry checks by default #4928
This is a request for end user input. Please use the Github reaction
Stack uses the
Twice now, files from Hackage have fallen out-of-date, which has left Stack users unable to initialize new installations. We have no control over fixing that, and instead need to wait for the Hackage team to update the expired files.
Given that (1) this seems to be a recurring problem without any evidence of automation to solve it that I can see, and (2) I'm unconvinced that there is actually a security benefit to this feature, I propose that, by default, we disable the expiry checks in Stack. I propose we include this in the next point release of Stack, scheduled for the near future.
If you're on this issue and you need a workaround, please see my comment with a workaround.
This was referenced
Jul 1, 2019
We have layers of proxies between us and the internet and things can go wrong. It doesn't make those of us advocating Haskell look very good when suddenly after a weekend long upstream proxy outage that we probably didn't know about builds start failing.
We have sensible policies about the degree of freshness we have to maintain in our build dependencies before we allow ourselves to make a release, but that's release to production and we have tools that gate that for us; inhibiting development and testing is probably not the right outcome of this otherwise well meaning mechanism.
I looked into this a bit more, since I was curious as to why in my testing
From the following comment, it seems that
I'm not sure why there are two different implementations of mirror discovery between the
If that PR is indeed disabling all checks, then I think it is unfortunate from a security standpoint. The only specific check that hackage security does not conduct is the one on mirrors, when it uses dns based discovery, since as that comment notes, there is reason to consider dns-based discovery already authenticated. Disabling all checks -- if that's what's happening here -- opens up the way to rollback-based attacks on the security infrastructure generally.
That said, I think there is low benefit from protecting against such rollback attacks (because we do not currently have infra in place to automate things enough to have only short windows between expiries and resignings, and also because rollback attacks only work in conjunction with other vectors of compromise), but nonetheless, ignoring expiry data altogether seems like it is bypassing some best practices.