On Tue, Jun 15, 2010 at 12:34 PM, Denis A. Altoé Falqueto <denisfalqueto@xxxxxxxxx> wrote: > On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@xxxxxxxxx> wrote: >>> I think that we should avoid signing files remotely. >> Is there any precise reason? If it is because "that remote place could be >> compromised" well any dev computer could be compromized too ! > > The main reason is that we would need to keep a copy of the private > key for each sining key in the remote machine. Of course, the private > key is encrypted with the passphrase (a good one, if possible). That > would mitigate an immediate use of a compromised private key, but with > time, it can be cracked and used to sign files on behalf the real > owner of the key. You don't want to let the card of your bank account > on two places, do you? Even though theoretically only you have the > PIN. Just appending this. The proposed model is based on the web of trust. We would trust on some keys to sign other keys. The main keys would be kept by some high trusty developers. They would sign the public keys of the other developers (and their personal keys too) with the main ones. We, mortal users, would trust the main keys to sign the others, and files signed by the developers' keys would be considered valid, by transitivity of the trust model. So, if a developer's key is compromised, it would be enough to generate another, submit to the key signers and resign the packages affected. In the current workflow, the package building is made in chroots, in the machine of each developer (sound reasons given by Ionut, above). The package would be signed after him testing it. The package would be upload to a staging area and the repo.db would be created. At this point, the repo.db should be signed, but exactly how is the real problem. I have some ideas, as explained in the wiki page, but I don't have the time and my skills are not so wonderful. This is done by Debian and Fedora, at least (those were what I've searched. Others may do it the same way). And one more thing: the implementation is not the main concern. The process is. That's why we muse discuss it thoroughly. A good plan will lead to a good and secure implementation. We should not rush anything. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
