Followups to libraries(a)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
