On Tuesday 15 June 2010 18:47:41 Denis A. Altoé Falqueto wrote: > 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). I dont think that repo.db should be signed and it is enough to sign only the packages. As I understand so far the only reason to sign repo.db file is to prevent "replay" situations in repos. Maybe it is possible to avoid this by comparing repo.db's between enabled repos in the mirrorlist when doing db sync. Ofcourse the status between repos is not consistent all the time but the situation should be ok if the repos are stable and mantained. If the core.db files does not match then the warning is issued to the user. > 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. I completely agree with this. As someone before said - we can not just throw some code at people and make them think that everything is secure now. -- Aleksis Jauntēvs
