8 ms·

Secure Package Distribution for Haskell

48 points by creichert 11y ago

cies 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        > fmap has a tight relationship with <$> Yup, it's really tight: <$> is fmap
    - sridca 11y ago
      > 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/pull/72 https://github.com/bitemyapp/learnhaskell/issues/40 https://github.com/bitemyapp/learnhaskell/issues/40
e12e 11y ago
This is great - but as this is a new command, shouldn't --verify be the default, with --no-verify as an option?
- snoyberg 11y ago
  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 11y ago
    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?]
  - rlpb 11y ago
    > 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?

48 points by creichert 11y ago

cies 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      > fmap has a tight relationship with <$> Yup, it's really tight: <$> is fmap
  - sridca 11y ago
    > 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/pull/72 https://github.com/bitemyapp/learnhaskell/issues/40 https://github.com/bitemyapp/learnhaskell/issues/40

e12e 11y ago

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

snoyberg 11y ago
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 11y ago
  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?]
- rlpb 11y ago
  > 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?