Secure Package Distribution for Haskell(fpcomplete.com)
fpcomplete.com
Secure Package Distribution for Haskell
https://www.fpcomplete.com/blog/2015/05/secure-package-distribution
10 コメント
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.
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/
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.
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
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
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.
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?]
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?
Maybe consider arranging distribution packages to automatically make GPG configuration available, and then default to --verify on in distributions by default?
The language and ecosystem are really mature now. But the main reason to go Haskell is simple and still the same: less bugs.