Secure Package Distribution for Haskell | Hacker News Reader

Secure Package Distribution for Haskell

fpcomplete.com

48 pointscreichert10 comments

This is one of a series of innovations happening recently to improve Haskell's package ecosystem (which was not tooo bad to begin with). If "cabal hell" or anything like that has even ruined your attempt at Haskell: this is the time to try again.

The language and ecosystem are really mature now. But the main reason to go Haskell is simple and still the same: less bugs.

I'd recommend Yorgey's cis194 course to start learning: http://www.seas.upenn.edu/~cis194/spring13/lectures.html

Each `lecture` is comprised of recommended reading material (sourced from LYAH, RWH, Typeclassopedia, and others) and some reasonably difficult homework problems that build on the learned concepts.

Do you recommend Spring 2013 for a reason?

The Spring 2015[1] has a similar but different set of lectures/assignments. Do you think that is better/worse?

[1] http://www.seas.upenn.edu/~cis194/

They're likely both good starting points. From a cursory glance of Spring 2015, here's why I like 2013 more:

2013 starts with Functor and builds into Applicative then Monad. I like this a lot, as each builds on each other: fmap has a tight relationship with <$>, and Monad is pretty much Applicative with bind (>>=). Applicative is a Functor and Monad is an Applicative (as of 7.10 I think).

I'm by no means super experienced here, but the 2013 course was the first learning text that really got me into Haskell.

> fmap has a tight relationship with <$>

Yup, it's really tight: <$> is fmap

> Do you recommend Spring 2013 for a reason?

There were discussions on preferring Spring 2013 to 2015 here: https://github.com/bitemyapp/learnhaskell/pull/72 https://github.com/bitemyapp/learnhaskell/issues/40

This is great - but as this is a new command, shouldn't --verify be the default, with --no-verify as an option?

Even without --verify, stackage-update is providing a far more secure setup than what you get from cabal update today (since it downloads over SSL). I didn't want to make GPG configuration an impediment to people using this tool, thereby pushing them towards something even less secure.

Longer term, we need a better answer, most likely using a config file to state your preference, and eventually switching the default to --verify.

I don't want to re-hash an old argument, but in my opinion dropping the gpg-key at a well known location secured by ssl (or better yet, bundled with all binary packages of haskell), and using gpg for trust is better in many ways.

Suddenly secure off-line distribution (think CDs), bittorrent, plain http/ftp... becomes [ed:trivial to] secure (if not private).

And anchoring everything at a gpg key makes the trust chain simpler. No longer can a rouge CA distribute signed software updates, you only have to trust your kernel, haskell and gpg -- not the usually large and somewhat arbitrary bundle of CA certs that come with the OS etc.

[Ed: not to mention: the gpg signing key can live "mostly offline" - the ssl key is "always online". Only the server hosting the gpg key (if first-trust is anchored in ssl) is critical for distribution]

[Ed2: You already ask people to install trusted binaries (to boostrap cabal/haskell) -- surely a gpg-implementation can be squeezed in there?]

> I didn't want to make GPG configuration an impediment to people using this tool...

Maybe consider arranging distribution packages to automatically make GPG configuration available, and then default to --verify on in distributions by default?

Reply on news.ycombinator.com