[arch-general] Package signing
Hello, The idea is to implement package signing for Arch similar to rpm GPG package signing. Short description follows. Use case for developers: 1. Dev bulds package with f.e. "-sign" switch. 2. Dev enters passphrase. 3. makepkg builds the package and creates detached signature (now we have 2 files *.tar.xz and *.sig). 4. The two files togeather are distributed to the repos as package with signature. Package installation: Pacman additionally downloads the signature the signature file and verifies the package. Problems: 1. Where to store the package signature file? It is more convenient and logical to keep the package as a single file. Rpm packages uses binary format and the signatures are stored inside. 2. GPG key sharing. Rpm-like distros like fedora and RHL use a single key for signing all their stable packages, but I think their build system is centralised. Is it safe to share one key among all package developers? 3.. Implementation: 1. Add package verification suport in lipalpm (using gpgme or gpg executable as rpm does). 2. Add package signing in makepkg script 3. Patch pacman, add option to turn the package signing ON or Off. 4. Add support for signed package distribution if needed (see Problems #1) 5. Include Arch public pgp key in /etc/pacman.d/..(??) Discussion about this and also other ways for package signing(md5,..) are welcome! -- Alekss
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this. I suggest you join the pacman-dev list where all discussion about pacman development occurs. There is also some code floating around that has started to implement this. This is my gpg branch containing those patches - http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg . Allan
On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this.
Yes, the monthly forum threads were a bit tiring. I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?).
On 28/04/10 23:52, Ng Oon-Ee wrote:
On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this.
Yes, the monthly forum threads were a bit tiring.
I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?).
The need for testers usually occurs after implementation! :)
On Wed, 2010-04-28 at 23:56 +1000, Allan McRae wrote:
On 28/04/10 23:52, Ng Oon-Ee wrote:
On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this.
Yes, the monthly forum threads were a bit tiring.
I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?).
The need for testers usually occurs after implementation! :)
Well, it does seem like a multi-part project, so I'm sure even before a total implementation there would be bits and pieces to test (functionality in pacman, for example, that nobody would use because the rest of the supporting cast isn't there yet).
On Wed, 2010-04-28 at 22:03 +0800, Ng Oon-Ee wrote:
On Wed, 2010-04-28 at 23:56 +1000, Allan McRae wrote:
On 28/04/10 23:52, Ng Oon-Ee wrote:
On Wed, 2010-04-28 at 23:39 +1000, Allan McRae wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this.
Yes, the monthly forum threads were a bit tiring.
I wonder what the need would be like for testers. And what testers would actually do (try and break stuff?).
The need for testers usually occurs after implementation! :)
Well, it does seem like a multi-part project, so I'm sure even before a total implementation there would be bits and pieces to test (functionality in pacman, for example, that nobody would use because the rest of the supporting cast isn't there yet).
Hello I also like the idea of package signing for Arch. It would really be great if someone could implement this. I would also update my system to testing just because of this development, if a new pacman version containing this feature would show up.
On Wed, Apr 28, 2010 at 10:39 AM, Allan McRae <allan@archlinux.org> wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this. I suggest you join the pacman-dev list where all discussion about pacman development occurs.
There is also some code floating around that has started to implement this. This is my gpg branch containing those patches - http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg .
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. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wed, 28 Apr 2010 14:18:02 -0300, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> 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. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Apr 28, 2010 at 2:25 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Wed, 28 Apr 2010 14:18:02 -0300, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> 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 -------------------------------------------
On Wed, Apr 28, 2010 at 14:32, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
This could also cause problems when downloading some package that depends on a public key that was not downloaded yet. Adding the keyring to the same rule that prompts you to upgrade pacman before anything else might make sense here.
On Wed, Apr 28, 2010 at 13:18, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
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.
This is pretty sensible, but I think that the second step would preclude having a passphrase on the key, as it would have to be called from a script. Another way to do it might be to have the upload verified by sender key and then have the uploader sign the repo db (during the db-update step probably?). We'd have to have a keyring, but with this method even if the server is compromised the db is safe from tampering, since the keyring is signed by the highest-trust key (phrak, presumably), and that lists the keys which are allowed to sign the repo itself, so there's no way to insert untrusted keys into the keyring or repo. Perhaps the keyring package could require double-signing to also prevent an attack where phrak gets hacked again and loses his key :)
On 28.04.2010 19:18, Denis A. Altoé Falqueto wrote:
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.
If you do it that way you wouldn't have to sign the uploaded packages. I'd publish a list of developers' keys and the user has to add and trust (in GPG terms) those keys. If he trusts them pacman installs packages singed by those keys or keys that can be trusted because they have been signed by them (GPG's web of trust). Otherwise if the (untrusted) sig can be verified pacman could ask and if the sig is broken it could abort. If you do it that way you can also add URLs to binary packages to the AUR and let pacman download them if you trust the sig. C&C welcome. -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Wed, Apr 28, 2010 at 3:30 PM, Florian Pritz <bluewind@server-speed.net> wrote:
On 28.04.2010 19:18, Denis A. Altoé Falqueto wrote:
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.
If you do it that way you wouldn't have to sign the uploaded packages.
I'd publish a list of developers' keys and the user has to add and trust (in GPG terms) those keys. If he trusts them pacman installs packages singed by those keys or keys that can be trusted because they have been signed by them (GPG's web of trust). Otherwise if the (untrusted) sig can be verified pacman could ask and if the sig is broken it could abort.
If you do it that way you can also add URLs to binary packages to the AUR and let pacman download them if you trust the sig.
Your suggestion is similar to Daenyth`s (for what I understand), so I will comment on both together. The central point is the management of the keyring. We could have a single key that all developers share, but this is troublesome as it would require some trusted channel to exchange the password (the first time and in the event of it changing). This approach is what others big distributions do, but the have a different structure than ours. We could have a keyring with all the trusted keys of the developers, but this could bring some problems as the keyring should be very well synchronized with the official one. Including a rule to upgrade the keyring package before others, as pacman. This requires intervention on user`s systems, so I think that it should be avoided, if possible. My idea tries to give the best of both worlds. The management of trusted devs would be made by a few admins and users would just be exposed to an official Arch key that would change just a few times, if it is not compromised. One weak point is the passphrase for the Arch key. It should not be handed over to every dev [1] and should not be used in command line scripts parameters or the cron job. It can be stored in some secure file and applied with gpg`s --passphrase-file <filename> or --passphrase-fd <file descriptor>. So, the effective user of the script would have access to read the passphrase file, but the real user would not. Maybe this is a little overkill, but C&C are very welcome :) [1] Maybe I`m just too paranoid with the dev team, but I don`t think that all of them should have the passphrase (if I were a dev, I wouldn`t want to have it). We have seem the group expanding and losing components. No offence intended. -- ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
I wrote about this topic ~1 month ago. You don't need PKCis or distribute the keyrings themselves. GPG supports transitive trust. The pacman keyring would be installed by default trusting on whatever keys a pacman root signature has signed (there could also be a different master key for community developers). The basic idea here is that you are not trusting the repository, but the individuals themselves. The master key -which can be kept offline and is only used when a developer joins/part- provides a basic default (people we generally trust) but a power user could reconfigure it to not accept packages signed by Pierre, because he distrusts him :), or he can add additional trusted people (a much more likely scenario) by just adding that person key to its keyring. A developer asks you to try a beta package -> You need to do nothing since you already have its key. Fetching from personal repo from a developer -> You need to do nothing since you already have its key. That really smart guy from the forum whose advice you follow blindly. -> Add its key. Packages built by you -> Add your own key. Sysadmin -> Add its key to the computers he administers. Paranoic sysadmin -> Add its key and remove the developers one. Then resign all packages after verifying that they work. I think this is more or less what Florian Pritz proposes, althouugh I think he was thinking in terms of the user gpg, while I would go using a different, pacman gpg. Denis A. Altoé Falqueto wrote:
The central point is the management of the keyring.
We could have a single key that all developers share, but this is troublesome as it would require some trusted channel to exchange the password (the first time and in the event of it changing). This approach is what others big distributions do, but the have a different structure than ours.
With this structure the developers never share the keys. You could even remove the master key and consider someone a developer when n developers signed him. But I find the master key method clearer.
We could have a keyring with all the trusted keys of the developers, but this could bring some problems as the keyring should be very well synchronized with the official one. Including a rule to upgrade the keyring package before others, as pacman. This requires intervention on user`s systems, so I think that it should be avoided, if possible.
There are two cases where the keyring could change due to distro changes. a) Add a new developer. b) Remove a developer. In case (a), pacman would find an unknown signature, an download [on user approval] the public key from the key servers. Case (b) is trickier, since no matter how it is done, I think there will always be a race condition on a roque developer. Luckily, the shouts of such case would make it difficult to have people holding outdated keys. I would probably make the key updating part of pacman -y to ensure that users are not using a revoked key.
My idea tries to give the best of both worlds. The management of trusted devs would be made by a few admins and users would just be exposed to an official Arch key that would change just a few times, if it is not compromised.
Your approach is more insecure, since you are removing the developer key (end-to-end signing) and putting instead a generic one. With the other schema, in case a developer key was compromised, you would only need to untrust that key, not the whole master key which signs everything. Plus, your key is used continously, so it is more exposed (the signing server is compromised, it signs a fake request...). IMHO trusting the individuals also facilitates forking. A derivative distribution could share arch packages by trusting the same devvelopers. With a master key owning everything, the child distro would need to have a second key resigning everything. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, Apr 28, 2010 at 6:37 PM, Linas <linas_fi@ymail.com> wrote:
I wrote about this topic ~1 month ago. You don't need PKCis or distribute the keyrings themselves. GPG supports transitive trust. The pacman keyring would be installed by default trusting on whatever keys a pacman root signature has signed (there could also be a different master key for community developers). The basic idea here is that you are not trusting the repository, but the individuals themselves. The master key -which can be kept offline and is only used when a developer joins/part- provides a basic default (people we generally trust) but a power user could reconfigure it to not accept packages signed by Pierre, because he distrusts him :), or he can add additional trusted people (a much more likely scenario) by just adding that person key to its keyring.
Hi, Linas. Yes, you are right. I'm reading about the transitive trust scheme and it really solves the most of our problems. For the interested, here comes an interesting explanation: http://www.apache.org/dev/openpgp.html#wot-verifying-links About the other comments, in fact, the web of trust explained in the link is the correct implementation of what I've thought. I'll drat a workflow and return in a while. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 28 April 2010 15:37, Linas <linas_fi@ymail.com> wrote: [snip]
Packages built by you -> Add your own key. [/snip]
Please no, it's way too convenient to be able to do makepkg && su -c "pacman -U whatever" and not bother with keys or signing. You should be able to install unsigned packages, maybe with a confirmation from pacman. -- Tavian Barnes
Am 28.04.2010 19:18, schrieb Denis A. Altoé Falqueto:
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.
Finally, someone realizes that. The distrubution and trusting of keys is in fact the most difficult problem we are faced with.
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.
Unacceptable. Servers get compromised way too easily (it happened in the past, and it may happen again). We'd have to store the key without a passphrase on that server for this to work. I'll never support such an approach. We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
Thomas Bächler wrote:
We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel). You might trust the date it if it was already in your local drive before the compromise date, but in such case you probably have it already installed, so you don't need to trust check it. Under which circunstances would you envision the need to trust an old, compromised signature? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Thu, 2010-04-29 at 00:36 +0200, Linas wrote:
Thomas Bächler wrote:
We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel).
You might trust the date it if it was already in your local drive before the compromise date, but in such case you probably have it already installed, so you don't need to trust check it.
Under which circunstances would you envision the need to trust an old, compromised signature?
New install, dev for a coupl of [extra] packages has already left the team. Having to recompile everytime a dev leaves the team is additional (unnecessary) hassle IMO, especially for bigger packages (openoffice and sons, I'm looking at you).
Ng Oon-Ee wrote:
Under which circunstances would you envision the need to trust an old, compromised signature?
New install, dev for a coupl of [extra] packages has already left the team. Having to recompile everytime a dev leaves the team is additional (unnecessary) hassle IMO, especially for bigger packages (openoffice and sons, I'm looking at you).
If the user is trustable, I wouldn't remove the user key until after he doesn't maintain any package any more (even though he can have its access revoked). If you need for some reason to keep them as trusted while revoking the key, you could sign the other dev package, thus taking responsibility on the integrity of that package (some users may disagree and reject your packages because they don't accept your policy). __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Am 29.04.2010 00:36, schrieb Linas:
Thomas Bächler wrote:
We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel).
You are right, if the key has been compromised, you can easily include a fake date. So upon revoking a key, all packages have to be re-signed. This shows again that this is not a topic you can just solve by throwing some code at people. It needs a proper chain of trust and concepts to cover all cases - otherwise, it might be possible to compromise the system, giving users a false sense of security.
On 30/04/10 01:29, Thomas Bächler wrote:
Am 29.04.2010 00:36, schrieb Linas:
Thomas Bächler wrote:
We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel).
You are right, if the key has been compromised, you can easily include a fake date. So upon revoking a key, all packages have to be re-signed.
This shows again that this is not a topic you can just solve by throwing some code at people. It needs a proper chain of trust and concepts to cover all cases - otherwise, it might be possible to compromise the system, giving users a false sense of security.
Has anyone had a good look at the other implementations of package signing (Debian, Fedora, ...) and made a summary of how they handle it?
On Thu, Apr 29, 2010 at 10:40 AM, Allan McRae <allan@archlinux.org> wrote:
On 30/04/10 01:29, Thomas Bächler wrote:
Am 29.04.2010 00:36, schrieb Linas:
Thomas Bächler wrote:
We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more.
You can't trust a package made with a compromised key just because it looks old. That can be falsified. Packages not affected should be resigned by another developer / the new developers key. I would still recompile them, though (withouth necessarily increasing the pkgrel).
You are right, if the key has been compromised, you can easily include a fake date. So upon revoking a key, all packages have to be re-signed.
This shows again that this is not a topic you can just solve by throwing some code at people. It needs a proper chain of trust and concepts to cover all cases - otherwise, it might be possible to compromise the system, giving users a false sense of security.
Has anyone had a good look at the other implementations of package signing (Debian, Fedora, ...) and made a summary of how they handle it?
This is also a resource worth consulting: http://www.cs.arizona.edu/stork/packagemanagersecurity/ -Dan
On Thu, Apr 29, 2010 at 12:40 PM, Allan McRae <allan@archlinux.org> wrote:
Has anyone had a good look at the other implementations of package signing (Debian, Fedora, ...) and made a summary of how they handle it?
(Long email ahead, sorry...) Good idea, indeed. This is what I've found about Debian: http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pa... Basically, they use gnupg and a private web of trust, managed by the apt-key command. They keep a separated keyring and trustdb (which keeps track of the web of trust). So, as I was thinking, they don't use the root's keyring or trusdb. They have a main signing key, that is shipped on the install cd and is installed by default on the keyring of apt-key. The main key is trusted and is used to sign the other keys used by the repositories, building up the web of trust. The repositories keys package is debian-archive-keyring and is used to distribute new keys and remove old ones. Fedora uses the same approach: http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s04.html I think the solution will be something like that. Maybe we could have like 2 or 3 signing keys, with the private part held by 2 or 3 developers. The keys are used to sign each other, so the level of trust can be raised a little, since pgp doesn't have a Certificate Authority concept. These main keys must be verified and trusted explicitly by the root user, at install time or after, in the case of a installed system (I think that this is a little price to pay to increase the security). I think that pacman could have some parameters to manage the keyring, like rpm and apt-key, so the user doesn't need to handle it with gpg. The verification is the process of the user verifying that the fingerprint of a key is correct, based on other channels (website, email, preferably in multiple sources). After the main keys are trusted to accept other keys signed by them, is possible to have a package of developer's keys, with a post-install script to append or remove them from the keyring of pacman and update the trustdb accordingly. We can choose the parameters of the trustdb, so that a developer's key is trusted if it is signed by at least 2 of the 3 main keys, or 1 of the 2 or 3. The developer's keys package should be signed by one of the main signing keys, so it can be trusted by pacman. Another point worth discussing is what will be signed. I think we should sign the repository metadata (repo.db.tar.gz) and each developer would sign his/her package. I have some doubts about the repository metadata signing, because I don't know exactly how the repo.db is created today. Is it made by each developer that uploads a package (in this case, the dev's key should be used to sign the repo.db). Or is it a script in Arch's server? We need to discuss this a little more. For the package signing part, it can be made very easily with this approach. The developer's public key is signed by a number of main Arch keys. The pacman's keyring package is rebuilt to append the new signed public key and is the resulting package is signed by one of the main Arch keys. The package is downloaded by the users and the post-install script updates the keyring and the trusdb. The updating should add new keys and remove the ones that are not present in the package (this will be a little tricky, but we can figure out a way). The keyring package must be updated just like pacman, preferably before pacman's package. The mos sensitive part is the verification of the main Arch keys by the user and the verification of the developer's public keys by the developers that will sign with the main Arch keys. There should be some secure channel of communication to guarantee that the fingerprints will not be changed for malicious purposes. C&C very much appreciated. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wednesday 28 April 2010 16:39:53 Allan McRae wrote:
On 28/04/10 23:32, Aleksis Jauntēvs wrote:
Hello,
The idea is to implement package signing for Arch similar to rpm GPG package signing.
Good to see someone interested in this. I suggest you join the pacman-dev list where all discussion about pacman development occurs.
There is also some code floating around that has started to implement this. This is my gpg branch containing those patches - http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg .
Allan
I examined the patches and I think they will be a good starting point. Thanks! -- Alekss
participants (12)
-
Aleksis Jauntēvs
-
Allan McRae
-
b1
-
Daenyth Blank
-
Dan McGee
-
Denis A. Altoé Falqueto
-
Florian Pritz
-
Linas
-
Ng Oon-Ee
-
Pierre Schmitz
-
Tavian Barnes
-
Thomas Bächler