[Haskell-cafe] Improvements to package hosting and security

[Gershom B]

On May 3, 2015 at 5:14:58 AM, Mathieu Boespflug (mboes at tweag.net) wrote:

> The more general point here is whether leveraging (arguably standard)
> third-party commands and/or C code in order to keep our maintainance
> burden low, and pick up many robust features for free to boot, is a
> good approach. I believe that it is. Our infrastructure and tooling is
> cracking at the seams as it is (cabal-install mysteriously dropping
> HTTP connections and corrupting .cabal files when behind a corporate
> firewall, updates to hackage-server inadvertently reversing the order
> of revisions, low availability of Hackage, ...). Leveraging Git would
> solve all mentioned problems, plus give us incremental updates for
> free, plus give us package index signing for little effort.

This seems to me to be mixing apples and oranges and pears and artichokes. The primary reason for hackage downtime in the past was instability of our hetzner box. Migrating to rackspace did wonders for us. Regardless, choice of hardware/webhost is orthogonal to git. You then list a logic bug in a version of hackage server. Logic bugs, as I’m sure you’re aware, can be introduced anywhere that code is written. No proposal put forward involves not writing and running code, so while we can work on better regression test suites, code-review procedures, etc., this has very little to do with adoption of git (especially as I understand the reverse in revision order was a bug on _display_ which this proposal doesn’t address at all). Finally, you discuss cabal-install having trouble behind firewalls. I agree with this being a problem, and I want us to work on this. However, git is again not a magic bullet. I’ve had firewalls where I run into trouble with git too, or with mercurial, or where certain website/firewall combinations meant, mysteriously that curl would work but not wget, or vice versa. I think the plans to expand the choice of transports for cabal-install will improve things in this regard, and could in fact lay the basis for adding git as an additional transport as well.

In summary: You point to real problems that have occurred (of them, only the first [firewalls] is an ongoing issue). There are many other problems you did not point to, but that are also problems, and remain problems. Moving to git as a transport could potentially address some problems, with certain other tradeoffs in terms of other tooling choices we would have to make. However, I don’t think that migrating to git will solve any of the problems you mentioned above in your parenthetical. It _does_ help with the incremental fetch issue (though there are other ways to do that), and it _is_ a way to tackle the index signing issue, though I’m not sure that it is the best way (in particular, given the difficulty of configuring git _with keys_ on windows).

Cheers,
Gershom