[arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)

Dimitrios Apostolou jimis at gmx.net
Wed Jun 16 18:09:56 EDT 2010


On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:
> 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).

As far as I know, Fedora uses a different model: a build server and 
release-wide keys. Search for "Fedora koji" and "Fedora keys" for more 
info. However I don't know how do developers submit RPM spec files to the 
build server, /maybe/ their own keys are used there.

About debian I don't have a clue.


Dimitris


>
> 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
> -------------------------------------------
>


More information about the arch-general mailing list