[Haskell-cafe] Ticking time bomb

Ertugrul Söylemez es at ertes.de
Thu Jan 31 07:27:54 CET 2013

Ramana Kumar <Ramana.Kumar at cl.cam.ac.uk> wrote:

> But if you keep calling cabal a package manager, eventually you'll
> have to write the patches to make it one.

The combination of Cabal, cabal-install and Hackage is a package
distribution system.  As such, it needs the necessary cryptographic
support.  I don't view them as a package management system.

What's important is that many programmers blindly trust the code they
download, install and run from Hackage.  Yes, it's a bad habit, but
seriously, that's the alternative?  Distributions are often some linear
combination of outdated and broken with coefficients near 1.  Let me
restate the important fact with more emphasis:

    People are using Hackage!

In any case there is no valid excuse for the lack of crypto.  It's too
easy to attack Hackage, so we need some crypto regardless of what we
interpret it as.

My proposal is:

  1. Build the necessary machinery into Cabal to allow signing keys and
     packages and verifying the signatures, ideally through GnuPG.
     Cabal would benefit from that even without cabal-install and

  2. Update Hackage to allow uploading signatures along with packages.

  3. Update cabal-install to allow signing packages and optionally
     checking the signatures.  Do not allow signature chains.  Do not
     support CAs for now.

     Have a database of trusted keys.  Could be a directory below
     ~/.cabal with keys as files.

     More detailed (skip to next step, if you're not going to implement
     this):  Before installing anything, build a map from maintainers
     from whom we would be installing packages to the packages they
     maintain.  Maintainers are identified by their keys, not their
     usernames.  If any of the keys is not trusted yet, then print this
     list as readable as possible.  Use colors, etc.  Hypothetical

         % cabal install diagrams
         Resolving dependencies...
         The following maintainers are untrusted:

             Diagrams Project <... at ...> [ABCD1234]:
                 FP: 0000 1111 2222 3333 4444  5555 6666 7777 8888 9999

         Trust them (?/y/n/t)? ?
           y: yes
           n: no (default)
           t: temporarily

         Trust them (?/y/n/t)? y
         Adding to trust db: Diagrams Project <... at ...> [ABCD1234]


     Cabal should ignore the "Maintainer" field in the Cabal file.  Only
     the signature counts here.  Cabal must report a changed maintainer:

         % cabal install diagrams
         Resolving dependencies...
         WARNING: Package 'diagrams-core' has changed maintainer.
             [old key info]
             [new key info]
         Install anyway (y/n)? y
         The following maintainers are untrusted:


  4. Announce the change and urge maintainers to update their packages
     to include signatures.

  5. Wait a few weeks.

  6. Make signature verification the default in cabal-install.

  7. Optionally implement CA support and establish a CA outside and
     offsite of Hackage.  Someone with a good understanding of server
     security and cryptography should do that.  They could be added to
     ~/.cabal/config to make package installations easier.

Steps 1..6 should be done with high priority, otherwise they will never
be finished.  Step 7 is optional.  If you're indeed considering this,
I'm happy to turn this into a set of bug tracker issues and possibly
help with the development.


Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130131/c48c2b22/attachment.pgp>

More information about the Haskell-Cafe mailing list