[Haskell-cafe] Improvements to package hosting and security

[amindfv at gmail.com]

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 <duncan at well-typed.com> escribió:

> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe