On Wed, Apr 28, 2010 at 2:25 PM, Pierre Schmitz <pierre@xxxxxxxxxxxx> wrote: > On Wed, 28 Apr 2010 14:18:02 -0300, Denis A. Altoé Falqueto > <denisfalqueto@xxxxxxxxx> wrote: >> Hi, Allan and Aleksis. >> >> I was thinking about this problem for sometime and the more complex >> part is the key distribution and trusting. Now I maybe came to >> something usefull. >> >> I'm thinking about a two way signing process. The dev signs the >> package and send it to the server. The server would have a script or a >> cron job to verify if the signature is valid and is from someone >> trusted [1]. If so, the original signature is discarded and a new one >> is made, with an official Arch key. >> >> So the problem of distributing keys is solved. We just need to >> distribute and trust the official public key of Arch. If some new >> developer comes to the team, its digital fingerprint is added to the >> list of trusted devs. If someone is removed, its fingerprint is >> removed. The users will trust in anything the server has signed, >> because the physical access to the private key is kept safe (so we >> hope :)). If some developer loses the confidence in his key, he can >> generate another and send the fingerprint to the admin, so it can be >> added toe the trusted list. >> >> I am willing to help with any efforts in this area. I'm already >> subscribed in pacman-dev and if this discussion pops up there, count >> me on. >> >> [1] - there should be a list of fingerprints of trusted devs, only >> writeable by a few admins. > > Why not just use openssl instead of gpg then? You have a root cert which > sings the individual pub keys of every dev. To verify the packages users > just have to trust the root cert. This does even support some kind of > revoke etc.. (you could even sign the root cert by an external entity like > cacert to make it even more secure. > I didn't understand your reasoning completely, so what follows may be flawed. Could you expand it a little? It seems that openssl can sign a digest (probably a sha or sha1) and it can verify it, but it needs access to the private key to do the signing and the public key to do the verification. You wrote about signing public keys of developers. This signed pk`s would be distributed over to the users? I was thinking in something that would isolate the users from the changing group of developers. This could also cause problems when downloading some package that depends on a public key that was not downloaded yet. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
