Followups to libraries@haskell.org, please. I'm working with Lemmih on the designs for Hackage and Cabal-Get. He's a real trooper, since I'm a total "customer" and have hardly written a line of code for these tools, but keep coming up with new requirements. The basic interaction we would like is this: 1) upload a tarball of a cabal-ized tool to the web site 2) the tarball gets unpacked, the .cabal file is read and added to the database 3) Now, an end user can say "cabal-get pkgname" and it'll download pkgname and all of its build-depends, compile and install them. Use the --user flag if you want to install it all locally. Yay! This actually already works :) The big problem actually is that this is in no way secure, and just begging to be exploited. Boo. I was assuming that we'd add some kind of package signing similar to what Debian does in its apt-secure tool (since I was one of the authors on that tool, I have a good idea about what we need), but I figured we could do that later. But now I'm thinking that this is a stupid idea, and it needs to be secure from the get-go. So here's the new sequence of steps: 1) Generate a gnupg key. preferably get it signed by someone in my web of trust (I'll try to organize a keysigning party at ICFP). We have a core group already by virtue of Debian's web of trust. 2) use cabal-put to sign and upload a package (or get someone with a key to upload your package) 2.a) if you try to upload a new version of a package that's signed by someone else's key, you're out of luck. You'll have to get me to over-ride it or get the original uploader to upload the new version. 3) cabal-get can then be used to download and install as before, but first it checks the signatures of all the packages. If any of them are untrusted signatures (as defined by the cabal-get keyring), then warn the end user. It'll be harder to upload packages, but at least now exploits won't be trivial, and for signed packages, we have something approaching Real Security! What do folks think of that? peace, isaac