6 ms·
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 wa
by 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 agoI 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?