

Secure Package Distribution for Haskell - creichert
https://www.fpcomplete.com/blog/2015/05/secure-package-distribution

======
cies
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.

~~~
SirensOfTitan
I'd recommend Yorgey's cis194 course to start learning:
[http://www.seas.upenn.edu/~cis194/spring13/lectures.html](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.

~~~
murphm8
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/](http://www.seas.upenn.edu/~cis194/)

~~~
SirensOfTitan
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.

~~~
ac
> fmap has a tight relationship with <$>

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

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

~~~
snoyberg
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.

~~~
e12e
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?]

