One solution might be to build the packages on kiwilight, then mount the directory of built packages with sshfs. You could then run the signing script locally. I don't know much bandwith that will use, but I think it's worth trying. In the worst case scenario, it will be equivalent to downloading the packages. Whether or not that's a problem depends on your connection.
I don't see how that could be anything else but the worst case, GnuPG on the machine needs to consume the entire package in order to create the digest, hence all built packages must be downloaded :-(
I understand that such a solution is not ideal. but is it not possible in the absence of other solutions? Aside from ghc itself, are there any really big packages? For ghc, if you are still using the one from community then it is already signed.
Could you simply make kiwilight the main host and have xsounds mirror it? The process would then be the following: 1) ssh into kiwilight, build, and move to haskell/$arch if necessary 2) mount haskell/$arch via ssh and run the signing script locally
You would then have a fully signed repo in haskell/$arch that can be mirrored by xsounds.
Of course I could. It could be argued that since the building happens on kiwilight we all are forced to trust all (root) users of that system anyway. Adding a signature (which is created on kiwilight) won't decrease the trustworthiness of the packages, but a signature would mean that the trustworthiness is kept as the packages are copied over to xsounds.
I find security to be very tricky, so any comments and corrections to my thinking is more than welcome.
This may well be the best solution. Kiwilight is already run by a trusted user, so I think it can be trusted as much as [community] can, provided that no one else has root access. You should ask Kaiting about that. I think this is a scenario for using subkeys. As I understand it, you should generate a new local master key for package signing. From that key you can then generate a signing subkey that you can upload to sign packages on kiwilight. I have never used subkeys myself, so I have no practical advice to give. This page from the Debian Wiki may be a good starting point: http://wiki.debian.org/subkeys By keeping the master key yourself, you can always revoke the signing subkey, regardless of what happens on the server. I would use a relatively strong password on the uploaded key for added security. /X