Ramana Kumar
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 Hackage. 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 example: % cabal install diagrams Resolving dependencies... The following maintainers are untrusted: Diagrams Project <...@...> [ABCD1234]: FP: 0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 monoid-extras-0.2.2.2 dual-tree-0.1.0.1 diagrams-core-0.6.0.1 diagrams-lib-0.6.0.1 diagrams-svg-0.6.0.1 diagrams-contrib-0.6.0.1 diagrams-0.6 Trust them (?/y/n/t)? ? y: yes n: no (default) t: temporarily Trust them (?/y/n/t)? y Adding to trust db: Diagrams Project <...@...> [ABCD1234] [install] 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. Greets, Ertugrul -- 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.