I created a repository on Gitorious and pushed a couple of commits to the openpgp branch [1]. (There is nothing related to cabal-install yet, so apologies for off-topic.) [1] https://gitorious.org/hackage-server/hackage-server/commits/openpgp

I’ve just pushed the commit [1] allowing to cache OpenPGP public keys on ‘cabal update’. (Note that I haven’t written the needed code for ‘cabal install’ yet, so the rest of this message is only about ‘update’.) After talking to people on #gnupg (thanks!), I decided to abandon the previous idea of relying on a “positive certification of a User ID and Public-Key packet” [2] in order to determine whether a certain key is trusted. Key changes must be treated with care, so now a user must manually mark each key contained in the index tarball [3] as trusted or untrusted. This is tedious, but there are workarounds (like sharing the list of (un)trusted keys with people you trust). I also assume this should happen rarely after the initial update. A short demo follows. First, you need to obtain the source code from this repository [4] and switch to the ‘openpgp’ branch. Configure and install as usual, then run these commands: $ dist/build/hackage-server/hackage-server init $ dist/build/hackage-server/hackage-server run --static-dir=datafiles Register a couple of test accounts [5] (this process requires sendmail). And don’t forget to upload a public key at the temporary page. Keep the server running because it currently cannot recover public keys after shutdown. Clone this repository [6], checkout the ‘openpgp’ branch, and build it. Create a test config file. In mine, these lines differ from the defaults: remote-repo: localhost:http://localhost:8080/packages/archive remote-repo-cache: /home/nikita/cabal/test-cabal-dir/packages world-file: /home/nikita/cabal/test-cabal-dir/world After that you should be able to see something similar: $ dist/build/cabal/cabal \

--config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \ --ignore-sandbox update Downloading the latest package list from localhost Do you trust the following key of test01? (yes/no/Skip) Test Key (do not use) 1024 bit RSA key B10D 6514 06C6 9846 F0BF C2E6 1E50 C29A F1EE 591F, created: 2014-06-21 11:38:39 UTC yes Marking the key as trusted. Do you trust the following key of test02? (yes/no/Skip) Test Key2 (do not use) 1024 bit RSA key E2C2 CA45 9442 3F0D 58D3 059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC s Skipping the key.

(See the code in ‘IndexUtils.hs’ for the list of supported commands.) “Yes” writes the key into ‘test-cabal-dir/packages/localhost/public-keys’, which may later be used by ‘cabal install’ to verify a signature. (This is not implemented yet.) “Skip” (or any unrecognized command) simply prints the message. So the question will be asked again when ‘cabal update’ is run: $ dist/build/cabal/cabal \

--config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \ --ignore-sandbox update Downloading the latest package list from localhost Do you trust the following key of test02? (yes/no/Skip) Test Key2 (do not use) 1024 bit RSA key E2C2 CA45 9442 3F0D 58D3 059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC no Marking the key as untrusted.

“No” adds the fingerprint to ‘test-cabal-dir/packages/localhost/untrusted-fingerprints’. After that a user will never be asked about this key: $ dist/build/cabal/cabal \

--config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \ --ignore-sandbox update Downloading the latest package list from localhost

A warning is raised if a trusted key is already present in the cache: $ cd /home/nikita/cabal/test-cabal-dir/packages/localhost/public-keys $ mv test02-public.txt test01-public.txt $ cd - $ dist/build/cabal/cabal \

--config-file=/home/nikita/cabal/test-cabal-dir/test-cabal-config \ --ignore-sandbox update Downloading the latest package list from localhost Warning: the cache already contains the following public key corresponding to test01: Test Key2 (do not use) 1024 bit RSA key E2C2 CA45 9442 3F0D 58D3 059A EFAC 5E0D E4B2 0BFE, created: 2014-06-21 23:39:41 UTC Do you trust the following key of test01? (yes/no/Skip) Test Key (do not use) 1024 bit RSA key B10D 6514 06C6 9846 F0BF C2E6 1E50 C29A F1EE 591F, created: 2014-06-21 11:38:39 UTC C-c C-c

(“Yes” would replace the existing key.) That’s all for now. Any comments are appreciated. Next I’m planning to make this process optional (via a command line flag) and augment ‘cabal install’ to use this. It also bothers me that ‘hackage-server’ and ‘cabal-install’ have nearly the same code in ‘OpenPGP.hs’. I’ll try to contribute it to ‘hOpenPGP’, so it can be imported from there. [1] https://gitorious.org/cabal/cabal/commits/openpgp [2] https://tools.ietf.org/html/rfc4880#section-5.2.1 [3] http://localhost:8080/packages/index.tar.gz [4] https://git.gitorious.org/hackage-server/hackage-server.git [5] http://localhost:8080/users/register-request [6] https://git.gitorious.org/cabal/cabal.git

I’ve been extremely busy recently, so I only answer the questions for now. Please speak up if you see a possibility for an attack, or if something is not clear or not efficient.

If you go for GPG, here's some issues to consider: * Who is allowed to sign for each package? Do we place any restriction or is any sufficiently trusted user allowed to upload any package? (I know the server will try to prevent this, but I'm talking about crypto level assurance here, not just server permission checks). If we do try to restrict it then we need some equivalent of the maintainer groups so I can allow other certain people to upload "my" package.

Each Hackage user should be able to upload their public key. Each Hackage package must have a “signed?” flag or an equivalent (which will be set automatically). While uploading a package, a user should be able to choose whether to sign it or not. If a package is signed, the maintainers have the permission to sign. If it’s necessary to add a maintainer, the uploader lists a username in a file, signs it, and uploads. (Is there a better way to achieve the same thing?) The server checks the signature, parses the file, and adds the usernames to the maintainers group. Since it’s important to sign the file locally, there should be a convenience tool allowing to select the usernames. An error must be raised if the file is not signed; the server must not allow such uploads. Each user of the said list must have a public key on Hackage. If not, the server must show an error message. If a key is not known, the server must check whether it’s signed by a previously known key corresponding to the package.

* How to require some packages to be signed while not requiring all packages to be signed. In particular, once we opt-in to signing a particular package, we want to make sure it's signed from then on, and not allow a non-signed version of the package (which would otherwise be an obvious attack).

When a user runs ‘cabal update’, it fetches a list of packages along with the “signed?” flags and the keys corresponding to each package. If the cache is empty, the information is written to disk. If not, it is compared with the previous version. If a package that was signed previously is not signed, an error must be raised. People will be able to share such files (if they want) in order to bootstrap securely.

* How to distribute the web of trust among end users (as opposed to authors) to minimise effort.

I’m not sure. Maybe we shouldn’t bother (at least for now). If someone wants to check a fingerprint, for instance, they can ask on haskell-cafe or #haskell.