A couple quick points:
- The IHG proposal is partly motivated by staying backwards-compatible, but I think we shouldn't put a premium on this. Non-https versions of cabal should imo be deprecated once there's an alternative, so most people will need to upgrade anyway. We can run an "old-hackage" instance for those who can't.
- To the extent that it doesn't become an impedence mismatch, deduplicating effort with revision control systems (e.g. git) seems very desirable:
a) It can reduce maintainers' work -- e.g. It's probably a long road getting maintainers to all sign their packages and others' revisions, but the majority are already doing this with git.
b) It's easier to trust -- the amount of vetting and hardening is orders of magnitude more, and Cabal/cabal-install is already a complex machine
c) It's already been built -- including (conservatively) hundreds of security corner-cases that would need to be built/maintained/trusted (see "it's easier to trust")
Nix is an example of a package manager that very succesfully defers part of its workload to git and other vcs.
Tom
El Apr 16, 2015, a las 12:02, Duncan Coutts
On Thu, 2015-04-16 at 14:39 +0200, Mathieu Boespflug wrote:
I'd like to step back from the technical discussion here for a moment and expand a bit on a point at the end of my previous email, which is really about process.
I should apologise for not publishing our design earlier. To be fair I did mention several times on the commercialhaskell mailing list earlier this year that we were working on an index signing based approach.
Early on in the design process we did not appreciate how much TUF overlaps with a GPG-author-signing based approach, we had thought they were much more orthogonal.
My other excuse is that I was on holiday while much of the recent design discussion on Chris and your proposals had been going on.
And finally, writing up comprehensible explanations is tricky and time consuming.
By ultimately these are just excuses. We do always intend to do things openly in a collaborative way, the Cabal and hackage development is certainly open in that way, and we certainly never hold things back as closed source. In this case Austin and I have been doing intensive design work, and it was easier for us to do that between ourselves initially given that we're doing it on work time. I accept that we should have got this out earlier, especially since it turns out the other designs do have some overlap in terms of goals and guarantees.
Ok, end of meta point, I for one am keen to dive back into the technical points that have been brought up in this thread already. :)
Incidentally, having read your post on splitting things up a bit when I got back from holiday, I agree there are certainly valid complaints there. I'm not at all averse to factoring the hackage-server implementation slightly differently, perhaps so that the core index and package serving is handled by a smaller component (e.g. a dumb http server). For 3rd party services, the goal has always been for the hackage-server impl to provide all of its data in useful formats. No doubt that can be improved. Pull requests gratefully accepted.
I see this security stuff as a big deal for the reliability because it will allow us to use public untrusted mirrors. That's why it's important to cover every package. That and perhaps a bit of refactoring of the hackage server should give us a very reliable system.
-- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe