Re: [pacman-dev] [arch-general] Package signing
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 17:37, 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). This sounds like the best solution proposed so far. +1
On Thursday 29 April 2010 00:37:34 Linas 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).
This idea is certainly worth a try. -- Alekss
On Thu, Apr 29, 2010 at 7:44 AM, Aleksis Jauntēvs <aleksis.jauntevs@gmail.com> wrote:
On Thursday 29 April 2010 00:37:34 Linas 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).
This idea is certainly worth a try.
Hi, guys. I've been studying apt to see how they manage this situation and here are my conclusions until now, together with a draft of a solution for Arch. I would like to thank Linas for the heads up about the web of trust of GnuPG. It is a central part of the solution proposed and is used by Debian and Fedora (possibly for other RPM based distros). I didn't think about the signing of the repo.db. Suggestions are welcome, as always. This email is very long and a ask you to read it all, because I think it is a feasible solution. ------- A simple introduction to the Web of Trust concept A web of trust is the concept used by OpenPGP (and GnuPG) for the management of trust policies in its public key system. As there's no concept of a central authoritative entity, there's the need of some kind of verification of the public keys that we accept in our keyring. Keys can be signed by other users, indicating that they trust in the veracity of the key. But the verification can become cumbersome, as the number of keys exchanged increases. To solve this, the comcept of Web of Trust was introduced. If I trust enough in a friend, I can sign his key in my keyring and tell to gpg that I also trust in the keys that he signs. So, if I verify a file that was signed by a person that my friend trusts, gpg will accept the signature as valid. When I import the third person's public key, gpg will mark it as a valid key. In GnuPG, there'are four levels of trus in a public key: - unknown: I didn't said anything about this key yet - none: i don't trust this public key to sign other keys (this just affects the signature keys, not the signatures of files) - marginal: I have a little trust in this public key to sign other keys - fully: I trust completely in this public key, as if it was my own So, GnuPG can be configured to accept a key as valid if it has 3 marginaly trusted key signatures or 1 fully trusted key signature (this is the default). Or it can be any other combination. The following is my suggestion for the use of GnuPG to sign and manage the pacman's keyring, toghether with the creation of a web of trust for the Arch Developers. It is very similar to what Debian and Fedora do, although there'are some differences, because of our way of doing things. 1. Pacman's keyring Pacman will have a separated keyring, so the root's keyring will not be affected by keys that are intended for use with package signing. This is already implemented in Allan's pacman git branch for gpg support. The directory will be /etc/pacman.d/gnupg/. There will be the public key database, the trust database and a fake private key database, because GnuPG doesn't work very well without one (according to Debian's apt-key script). The keyring will be populated based on the keys from the pacman-keyring package. In this package, there will be a file for the valid keys and one for the removed keys, so that the post-install script can revoke keys that may not be trusted anymore (be it for security reasons or because some developer has left the project). 2. Arch Key Signing keys There will be 3 keys for the sole purpose of signing other developers' keys (hereafter named KSK, Key Signing Keys). They will be created by 3 developers that will be responsible for the role of signing the other developer's keys (and theirs own too). This procedure is very important and must be done with the certainty that the keys being signed are from the person they plead to be. The confirmation of the fingerprints must be done via a secure channel (skype, phone call, secure email or personally). For example, Debian only trust in keys confirmed personaly (by what i could find). We can be a little lenient because the group of developers is reduced. The owners of the KSK must keep them secured and must choose a strong passphrase, so that even in the event of the secret keys being stolen, the risk of a real misuse will be little. In such case, there will be some time for the generation of a new set of KSK and the re-signing of the others developers' keys. With the KSK and the signed developers' keys, the pacman-keyring package will be created and signed with one of the KSK. 3. Package signing by developers When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). At this point, there are three options (that we should choose now) for the format of the signed/signature pair: - detached signature external to the package: the package will stay unchanged and there'll be a new file for the signature. - detached signature internal to the package: makepkg would generate a detached signature, but would tar the package and the signature into a new file, so that both are always toghether (Debian and RPM based distros do that way). This would have a bigger impact on all developer tools and pacman itself. - attached signature: the signature would contain the signed file, and pgp would be used to extract the signed file. Just like the one above, this would require lots of changes on the tools. The cheaper approach is obviously the first option. It will not require lots of changes, but there'll be some. Maybe the convenience of the latter two would compensaate for the trouble of changing the tools? Comments very much appreciated. 3. Instalatino of KSK by the users This is a very sensitive part and must be done with caution, at the risk of driving all the work moot. The KSK should be manually verified by the user before pacman can accept the pacman-keyring package. I believe that the following would be feasible: - the KSK and the corresponding fingerprints would be available in severall channels of Arch: Home page, git repository, forums, etc. - the user downloads the KSK and import them (with a new option of pacman) - pacman shows the fingerprint of each KSK and asks for the approval of the user - if the user confirms, pacman imports the keys to its keyring, setting them as fully trusted After this, the pacman-keyring can be installed and the public keys of the developers can be added by the post-install script. the trusdb will be updated. 4. Package verification When pacman downloads a package, the signature will be downloaded together. Pacman will inform the user if the package's signature is not valid and stop. At this point, the user can delete the package from the cache to force a new download or he can use an option to ignore the signature problem for a specified package. Maybe the option --no-confirm should be ignored in this case, to avoid creating a way to install a package whose signature is invalid without the user actively accepting. Or we should only accept that for packages without signature (the ones with an invalid signature should be never installed). Comments very welcome. 5. Affected tools 5.1 Makepkg There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package. 5.2 devtools I don't know them, so I can't comment. But the upload and repo.db generation will be affected, for sure. 5.3 pacman Pacman could have options to handle the management of the keyring: - approval of KSK - importation/exportation of new keys - alteration of level of trust of keys - removal of keys - update of trusdb 6. Final comments I believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. One possible problem is that gpgme is not able to update a trusdb (or at least i couldn't fine how). Maybe we'll have to use some script for that. ----- Comments and criticism are very appreciated. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
- detached signature external to the package: the package will stay unchanged and there'll be a new file for the signature. - detached signature internal to the package: makepkg would generate a detached signature, but would tar the package and the signature into a new file, so that both are always toghether (Debian and RPM based distros do that way). This would have a bigger impact on all developer tools and pacman itself. - attached signature: the signature would contain the signed file, and pgp would be used to extract the signed file. Just like the one above, this would require lots of changes on the tools.
We have to choose so we can also effectively support unsigned packages. I think there is no reason to sign packages built localy using PKGBUILD froum AUR or elsewhere - the weak point is the build script itself and it is possible that some users will choose not to verify packages upon installation. So I think only first two options are viable.
I believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. One possible problem is that gpgme is not able to update a trusdb (or at least i couldn't fine how). Maybe we'll have to use some script for that. -----
Comments and criticism are very appreciated.
Nice resarch! Generally, this version is ok and I think it solves the package signing - verification functionality but we should cearfuly study this further. Also we cluld try to find a solution for problem when it is possible to install old version of signed packages from the repo. I have created git repository from Alan's gpg branch: http://gitorious.org/pacman-pkgsig -- Alekss
On 01/05/10 14:27, Denis A. Altoé Falqueto wrote:
Hi, guys.
I've been studying apt to see how they manage this situation and here are my conclusions until now, together with a draft of a solution for Arch. I would like to thank Linas for the heads up about the web of trust of GnuPG. It is a central part of the solution proposed and is used by Debian and Fedora (possibly for other RPM based distros).
I didn't think about the signing of the repo.db. Suggestions are welcome, as always. This email is very long and a ask you to read it all, because I think it is a feasible solution.
Hi, Thanks for the comments on the package signing process. It has clarified a few things for me and I think we are on the right track with the work that has been done so far. I have made a few comments below. <snip>
3. Package signing by developers
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). At this point, there are three options (that we should choose now) for the format of the signed/signature pair:
- detached signature external to the package: the package will stay unchanged and there'll be a new file for the signature. - detached signature internal to the package: makepkg would generate a detached signature, but would tar the package and the signature into a new file, so that both are always toghether (Debian and RPM based distros do that way). This would have a bigger impact on all developer tools and pacman itself. - attached signature: the signature would contain the signed file, and pgp would be used to extract the signed file. Just like the one above, this would require lots of changes on the tools.
The cheaper approach is obviously the first option. It will not require lots of changes, but there'll be some. Maybe the convenience of the latter two would compensaate for the trouble of changing the tools? Comments very much appreciated.
The first method is what is currently used on the gpg patches that are available. The signature is made in a separate file and then is inserted in the repo db when the package is added. <snip>
4. Package verification
When pacman downloads a package, the signature will be downloaded together. Pacman will inform the user if the package's signature is not valid and stop. At this point, the user can delete the package from the cache to force a new download or he can use an option to ignore the signature problem for a specified package. Maybe the option --no-confirm should be ignored in this case, to avoid creating a way to install a package whose signature is invalid without the user actively accepting. Or we should only accept that for packages without signature (the ones with an invalid signature should be never installed). Comments very welcome.
Here the default option would be not to install the package with a signature problem so --noconfirm would just result in pacman aborting the transaction.
5. Affected tools
5.1 Makepkg
There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package.
I believe makepkg is good to go with the patches currently available.
5.2 devtools
I don't know them, so I can't comment. But the upload and repo.db generation will be affected, for sure.
repo-add is also mostly good to go (there are some TODOs left, e.g. aborting when the signature verification of the repo fails before adding the package). There needs to be discussion about signing the repo database itself and how that is handled. Does the last person to add a package sign the lot? That might be reasonable given the package signatures have been verified in some sort of chain to the initial signing. But it does mean that developers are signing the entire db when they are only responsible for a small part. I guess that would also require private keys be available on the server creating the repo dbs.... That needs thought. How do other distros handle that? The internal Arch packaging tools would need some very minor changes to upload the signature file but that can be handled at a later date.
6. Final comments
I believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. One possible problem is that gpgme is not able to update a trusdb (or at least i couldn't fine how). Maybe we'll have to use some script for that.
Could the trust database be updated via pacman using post_install on some pacman-keychain package? Allan
On Wed, May 5, 2010 at 3:51 AM, Allan McRae <allan@archlinux.org> wrote:
3. Package signing by developers
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). At this point, there are three options (that we should choose now) for the format of the signed/signature pair:
- detached signature external to the package: the package will stay unchanged and there'll be a new file for the signature. - detached signature internal to the package: makepkg would generate a detached signature, but would tar the package and the signature into a new file, so that both are always toghether (Debian and RPM based distros do that way). This would have a bigger impact on all developer tools and pacman itself. - attached signature: the signature would contain the signed file, and pgp would be used to extract the signed file. Just like the one above, this would require lots of changes on the tools.
The cheaper approach is obviously the first option. It will not require lots of changes, but there'll be some. Maybe the convenience of the latter two would compensaate for the trouble of changing the tools? Comments very much appreciated.
The first method is what is currently used on the gpg patches that are available. The signature is made in a separate file and then is inserted in the repo db when the package is added.
Yes, that's what I thought too. But maybe some day we could use a package layout that would leave a place for embedded signatures, as .deb and .rpm do. Surely, a mid to long term concern.
5. Affected tools
5.1 Makepkg
There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package.
I believe makepkg is good to go with the patches currently available.
I was thinking about makepkg having an option to select the key used to sign the package, with the default behavior being the main key of the user will be used.
5.2 devtools
I don't know them, so I can't comment. But the upload and repo.db generation will be affected, for sure.
repo-add is also mostly good to go (there are some TODOs left, e.g. aborting when the signature verification of the repo fails before adding the package).
There needs to be discussion about signing the repo database itself and how that is handled. Does the last person to add a package sign the lot? That might be reasonable given the package signatures have been verified in some sort of chain to the initial signing. But it does mean that developers are signing the entire db when they are only responsible for a small part. I guess that would also require private keys be available on the server creating the repo dbs.... That needs thought. How do other distros handle that?
Yes, this is a little troublesome right now. I don't know the workflow of the package upload and repo.db creation, but I presume that there'is a script to do it, right? Does repo-add run locally or remotely? I believe that it is run remotely. In that case, is there any synchronization scheme? Because we can have race conditions if two developers are calling it at the same time. I was thinking about generating the sha1 hash of the repo.db on the server and to sign locally just the hash, so the exchange of data between the server and the local machine is minimized. A digital signature is basically just that anyway. We could have a script to help the process, together with synchronization of the repo.db, to avoid race conditions. But that depends on the workflow of the uploading process. Could you explain it to me?
Could the trust database be updated via pacman using post_install on some pacman-keychain package?
Yes, I've already adapted apt-key to do some useful tasks for us (I named it pacman-key -- the originality prize goes to....). I think the model of apt is very interesting. Basically, they have the main keyring in /etc and the official package keeps the current keys in /usr/share/apt/. There's a file for keys to be added and another for keys to be deleted, so when a new keyring package is downloaded, the keys marked to deletion are removed from the main keyring and the new keys are added, if needed. Unfortunately, gpgme can't do some kinds of operations on keyrings, so we need a shell script for that. Aleksis already cloned your gpg branch and created a project on gitorious. I think is easier to make the changes there, test and play with ideans and just after that merge them to your repository. I'm also thinking in putting this proposal in the Arch Wiki, so we can keep up with the changes. And there are lots of details to append to the document. Thanks for the comments. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wed, May 5, 2010 at 2:33 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
I'm also thinking in putting this proposal in the Arch Wiki, so we can keep up with the changes. And there are lots of details to append to the document.
I took the liberty to create a new page on the Wiki. I don't know in which category it should go, though. http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 06/05/10 03:33, Denis A. Altoé Falqueto wrote:
On Wed, May 5, 2010 at 3:51 AM, Allan McRae<allan@archlinux.org> wrote:
5.2 devtools
I don't know them, so I can't comment. But the upload and repo.db generation will be affected, for sure.
repo-add is also mostly good to go (there are some TODOs left, e.g. aborting when the signature verification of the repo fails before adding the package).
There needs to be discussion about signing the repo database itself and how that is handled. Does the last person to add a package sign the lot? That might be reasonable given the package signatures have been verified in some sort of chain to the initial signing. But it does mean that developers are signing the entire db when they are only responsible for a small part. I guess that would also require private keys be available on the server creating the repo dbs.... That needs thought. How do other distros handle that?
Yes, this is a little troublesome right now. I don't know the workflow of the package upload and repo.db creation, but I presume that there'is a script to do it, right? Does repo-add run locally or remotely? I believe that it is run remotely. In that case, is there any synchronization scheme? Because we can have race conditions if two developers are calling it at the same time.
I was thinking about generating the sha1 hash of the repo.db on the server and to sign locally just the hash, so the exchange of data between the server and the local machine is minimized. A digital signature is basically just that anyway. We could have a script to help the process, together with synchronization of the repo.db, to avoid race conditions. But that depends on the workflow of the uploading process. Could you explain it to me?
This is the current Arch package upload procedure. Of course, it is not set in stone and if it requires changes for signing then that is fine. 1) packages are built locally, committed to SVN and uploaded to a staging directory on the main server. 2) on the main server, the dev runs a script that adds the packages in the dev staging area to the repos and updates the repo database. This script does some sort of locking to prevent races conditions. Allan
On Wed, May 5, 2010 at 8:11 PM, Allan McRae <allan@archlinux.org> wrote:
This is the current Arch package upload procedure. Of course, it is not set in stone and if it requires changes for signing then that is fine.
1) packages are built locally, committed to SVN and uploaded to a staging directory on the main server.
I think the preferred way is building in a chroot, isn't it? To avoid having to copy the private key to the chroot environment we have three choices: 1. sign the package before uploading it to the staging area; or 2. change makechrootpkg to also sign the package, calling makepkg to do the signing; or 3. change mkarchroot to bind ~/.gnupg to the corresponding directory of the chroot Maybe 3 is the easier change, but I think it will not work for existing chroots, will it? 1 and 2 are equally efficient, so I think it's no big deal between the two.
2) on the main server, the dev runs a script that adds the packages in the dev staging area to the repos and updates the repo database. This script does some sort of locking to prevent races conditions.
The better is never export the private key. So, does the script that copies the packages runs locally or remotely? If it is remotely (with the user having to log into ssh first), it would be harder to exchange data with the local environment, where the personal keyring is. If it is run locally, we can automate the following workflow: 1. (at the server) check if the repo.db is locked. Just proceed if it is not. 2. (at the server) lock the repo.db to avoid race conditions 3. (at the server) call repo-add to update the repo.db 4. (at the server) generate a sha1 hash for the new repo.db 5. (locally) scp the hash to the local system 6. (locally) sign the hash with the developer's key. This signature can be an attached one, so we send both the hash and the signature on the same file and don't need to change other tools to much. 7. (locally) scp the signature back to the server 8. (at the server) unlock the repo.db To check the validity of the repo.db signature, we can do: 1. pacman downloads the repo.db and the signature 2. gpg extracts the original hash from the signature 3. sha1sum recomputes the hash on the downloaded repo.db 4. the recomputed hash and the signed hash are compared If the comparison is ok, the repo.db is intact. Otherwise, panic!! But this doesn't solve the problem of a replay attack (as pointed by Dan, some emails above), where an evil mirror admin puts an old validly signed repo.db to force some user to download a validly signed old package with an known vulnerability. This is tougher to solve. We would need some guaranteed way to tell if the downloaded repo.db is really the latest..... No ideas for now. Suggestions and comments, please. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 06.05.2010 22:48, Denis A. Altoé Falqueto wrote:
To check the validity of the repo.db signature, we can do:
1. pacman downloads the repo.db and the signature 2. gpg extracts the original hash from the signature 3. sha1sum recomputes the hash on the downloaded repo.db 4. the recomputed hash and the signed hash are compared
If the comparison is ok, the repo.db is intact. Otherwise, panic!!
Why can't you just sign the package, and let the rest of the process be the way it is? I don't understand why you have to sign the DB too. If the package signature is correct you can safely install it without worrying whether the DB is the latest or not. If a developer gets compromised you abandon his old key (post on the ML, news item, ... and tell users to update pacman-keyring maybe you could also use a keyserver here where you just publish a revocation certificate), resign all clean packages and rebuild the rest. Or am I missing something? -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Fri, May 7, 2010 at 7:44 AM, Florian Pritz <bluewind@server-speed.net> wrote:
On 06.05.2010 22:48, Denis A. Altoé Falqueto wrote:
To check the validity of the repo.db signature, we can do:
1. pacman downloads the repo.db and the signature 2. gpg extracts the original hash from the signature 3. sha1sum recomputes the hash on the downloaded repo.db 4. the recomputed hash and the signed hash are compared
If the comparison is ok, the repo.db is intact. Otherwise, panic!!
Why can't you just sign the package, and let the rest of the process be the way it is? I don't understand why you have to sign the DB too. If the package signature is correct you can safely install it without worrying whether the DB is the latest or not.
If a developer gets compromised you abandon his old key (post on the ML, news item, ... and tell users to update pacman-keyring maybe you could also use a keyserver here where you just publish a revocation certificate), resign all clean packages and rebuild the rest.
Or am I missing something?
You're missing something. You have no opened up the possibility of 1. Replay attacks. Serve up an old DB with a package with a now-known security vuln. Even with signing this could be a problem, so... 2. Forging attacks. Generate your own package DB with packages of your choosing. As long as they were built by someone trusted (even if they are years old), nothing can stop this. The **only** thing a package signature guarantees is that the packager says "at the time I built this, it was definitely me that did so", and nothing whatsoever about that package still being good to go. Guys, I sent a link that explains all this: http://www.cs.arizona.edu/stork/packagemanagersecurity/ -Dan
On 06.05.2010 22:48, Denis A. Altoé Falqueto wrote:
But this doesn't solve the problem of a replay attack (as pointed by Dan, some emails above), where an evil mirror admin puts an old validly signed repo.db to force some user to download a validly signed old package with an known vulnerability. This is tougher to solve. We would need some guaranteed way to tell if the downloaded repo.db is really the latest..... No ideas for now.
Add the date when the database was signed (inside of the same signature of course) and when updating the database (not when installing a package) let pacman check if this date is at maximum 1 or 2 days old. This requires low mirror delays though. If there are no updates for 2 days some dev would have to resign the database, but that's quite unlikely and acceptable I think. Pacman should also check if the new date is more recent than the old one. -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Fri, May 7, 2010 at 11:00 AM, Florian Pritz <bluewind@server-speed.net> wrote:
On 06.05.2010 22:48, Denis A. Altoé Falqueto wrote:
But this doesn't solve the problem of a replay attack (as pointed by Dan, some emails above), where an evil mirror admin puts an old validly signed repo.db to force some user to download a validly signed old package with an known vulnerability. This is tougher to solve. We would need some guaranteed way to tell if the downloaded repo.db is really the latest..... No ideas for now.
Add the date when the database was signed (inside of the same signature of course) and when updating the database (not when installing a package) let pacman check if this date is at maximum 1 or 2 days old. This requires low mirror delays though.
If there are no updates for 2 days some dev would have to resign the database, but that's quite unlikely and acceptable I think. Pacman should also check if the new date is more recent than the old one.
I was thinking about something like that, I would choose something like 5 or 7 days. This would give a window of attack of at most 7 days and would give enough time to the mirrors to sync. So, if some package has a known vulnerability, it would be exploitable by replay attack only for the last 7 days. After that, the repo.db would expire and the user would have to download a new one (say, if the mirror is compromised, it would be an indication of that). If the repository activity is really low, it would require a new repo.db being resigned each 5 or 7 days. The only weak point is the source of time to the comparison. Should we force an ntp query? Is it possible to use just a client library to do that or would we need to require a local server? Should we be happy enough with the time on the computer? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Fri, May 7, 2010 at 3:17 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
The only weak point is the source of time to the comparison. Should we force an ntp query? Is it possible to use just a client library to do that or would we need to require a local server? Should we be happy enough with the time on the computer?
Thinking a little more about it, the time on the computer will be enough. We should stress the point that it is a weak point to the user, so he MUST assure the time is right. After all, this is Arch and each user should be responsible for his own system. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Fri, May 7, 2010 at 3:17 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
I was thinking about something like that, I would choose something like 5 or 7 days. This would give a window of attack of at most 7 days and would give enough time to the mirrors to sync. So, if some package has a known vulnerability, it would be exploitable by replay attack only for the last 7 days. After that, the repo.db would expire and the user would have to download a new one (say, if the mirror is compromised, it would be an indication of that). If the repository activity is really low, it would require a new repo.db being resigned each 5 or 7 days.
Just one more note. GnuPG already embeds the current date and time on the signature. So, counting on the correct time on the dev's machines, we could rely on that to do the check. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
4. (at the server) generate a sha1 hash for the new repo.db 5. (locally) scp the hash to the local system 6. (locally) sign the hash with the developer's key. This signature can be an attached one, so we send both the hash and the signature on the same file and don't need to change other tools to much. 7. (locally) scp the signature back to the server
This isn't more secure than having a low trust gpg key at the server just for signing it. Note that the developer is blindly signing whatever the server provides him. He would need to have a local copy of the whole repo and locally compute the hash in order for it to be meaningful. Or have easily updateable signatures, but the packages are already individually signed. I don't see the need for a repo db hash (against malicious users, it can be useful to detect a corrupt download). Repositories with old packages are fine IMHO. I could have a "preferred packages" repo, I could be sharing an old, working package with other people, I may have an install media which contains an outdated repository. Not all usages of a different than the published one have to be malicious. They may be there to avoid a known bug in a newer release. The same attack is even inversely possible, by using a *newer* package (which was briefly on testing) to exploit a bug on it. If our only concern are rogue mirrors of the main repositories, that's quite easy to solve by checking their latest version on a central location, eg. by getting the hash of latest version from a dns record, like clamav does. (That hash could the be shortlivedly signed to avoid dns poisoning, too) I don't see an appropiate way of extending that when users add malicious repositories, although in such case they probably trust the owner key and are already sold. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Fri, May 7, 2010 at 7:37 PM, Linas <linas_fi@ymail.com> wrote: Hi, At first, I was tempted to agree with you in almost all your points. But after a little moment to grasp them, I would like to put the following:
4. (at the server) generate a sha1 hash for the new repo.db 5. (locally) scp the hash to the local system 6. (locally) sign the hash with the developer's key. This signature can be an attached one, so we send both the hash and the signature on the same file and don't need to change other tools to much. 7. (locally) scp the signature back to the server
This isn't more secure than having a low trust gpg key at the server just for signing it. Note that the developer is blindly signing whatever the server provides him. He would need to have a local copy of the whole repo and locally compute the hash in order for it to be meaningful. Or have easily updateable signatures, but the packages are already individually signed.
I don't think so. Maybe the idea was not well explained. In the repository there'll be a set of signed and a set of unsigned packages. We can't guarantee anything for the unsigned ones. For the signed, we know that the current repo.db is signed (not counting the first time) and contains the versions of the packages (along with the information if a package is signed or not - it is important to avoid the user fooling pacman). So, the script will copy the new signed packages from the staging dir to the repository and update the repo.db, changing only the information about the new ones. This will be made on a temporary file (probably with mktemp to make it unpredictable - I don't know the script). The hash is computed on the temporary repo.db and sent through a secure channel (ssh), signed locally and resent through ssh again. Just after that, the temporary files are moved to the final place. I can't see how a mailcious user could cause harm on the signed packages and on the signed repo.db. Again, the first time will be more sensitive, but maybe it could be handled manually to avoid the risk and the next time it would be as described before. But maybe I'm missing something.
I don't see the need for a repo db hash (against malicious users, it can be useful to detect a corrupt download). Repositories with old packages are fine IMHO. I could have a "preferred packages" repo, I could be sharing an old, working package with other people, I may have an install media which contains an outdated repository.
The point about the old install media is strong, the others not so much. If you have a personal repository, you can choose not to sign the repo.db or you can have your own trusted keys. But for the official repositories, I think is valid we have a signed metadata file.
Not all usages of a different than the published one have to be malicious. They may be there to avoid a known bug in a newer release. The same attack is even inversely possible, by using a *newer* package (which was briefly on testing) to exploit a bug on it.
Yes, but a replay attack is made with packages that have known vulnerabilities. Probably all packages we are using now have hidden vulnerabilities but that is not the case of using just the old trusted ones (or we could become Debian :).
If our only concern are rogue mirrors of the main repositories, that's quite easy to solve by checking their latest version on a central location, eg. by getting the hash of latest version from a dns record, like clamav does. (That hash could the be shortlivedly signed to avoid dns poisoning, too)
I don't see an appropiate way of extending that when users add malicious repositories, although in such case they probably trust the owner key and are already sold.
Yes, but going through all this trouble just to sign packages is a half baked solution. If we're going to do it, we should do it all. I was reading the link sent by Dan more throughly today and most of the attacks can be solved just by using signed metadata. And the others can be solved by using metadata with an expiration date, which we're aiming to do too. Thanks for the time to answer and keep it coming. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Fri, May 7, 2010 at 11:11 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote: Guys, I've updated the wiki page for the proposal to add use cases for the operations we have discussed here. The page is at: http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman#Use_... Please, review those use cases carefully and comment. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 06/05/10 03:33, Denis A. Altoé Falqueto wrote:
Aleksis already cloned your gpg branch and created a project on gitorious. I think is easier to make the changes there, test and play with ideans and just after that merge them to your repository.
I suppose... but make sure all patches and development go through this list. It would be no fun to have heaps done then Dan rips your foundation work to shreds! :D Allan
On Wed, May 5, 2010 at 6:16 PM, Allan McRae <allan@archlinux.org> wrote:
On 06/05/10 03:33, Denis A. Altoé Falqueto wrote:
Aleksis already cloned your gpg branch and created a project on gitorious. I think is easier to make the changes there, test and play with ideans and just after that merge them to your repository.
I suppose... but make sure all patches and development go through this list. It would be no fun to have heaps done then Dan rips your foundation work to shreds! :D
Hey now, I never do that! :P On second thought, I think I've ripped apart my own branches on this very issue several times, so don't think that just any code is going to be good enough to get in. This is tricky stuff, especially when balancing being both non-obtrusive yet still secure. -Dan
On Wed, May 5, 2010 at 8:23 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On second thought, I think I've ripped apart my own branches on this very issue several times, so don't think that just any code is going to be good enough to get in. This is tricky stuff, especially when balancing being both non-obtrusive yet still secure.
I agree completely. The most we think about the issue, the better the implementation. I am would like to wait more so that other people can read the proposal and see failing points or suggest the missing parts too. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Allan McRae wrote:
3. Package signing by developers
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). At this point, there are three options (that we should choose now) for the format of the signed/signature pair:
- detached signature external to the package: the package will stay unchanged and there'll be a new file for the signature. - detached signature internal to the package: makepkg would generate a detached signature, but would tar the package and the signature into a new file, so that both are always toghether (Debian and RPM based distros do that way). This would have a bigger impact on all developer tools and pacman itself. - attached signature: the signature would contain the signed file, and pgp would be used to extract the signed file. Just like the one above, this would require lots of changes on the tools.
The cheaper approach is obviously the first option. It will not require lots of changes, but there'll be some. Maybe the convenience of the latter two would compensaate for the trouble of changing the tools? Comments very much appreciated.
The first method is what is currently used on the gpg patches that are available. The signature is made in a separate file and then is inserted in the repo db when the package is added.
I would prefer having the signature along the package. Maybe as a tar extended header. This way you can't lose the detached signature (it also means that you need to download twice as much files).
6. Final comments
I believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. One possible problem is that gpgme is not able to update a trusdb (or at least i couldn't fine how). Maybe we'll have to use some script for that.
Could the trust database be updated via pacman using post_install on some pacman-keychain package?
Allan I don't see how is the pacman-keychain database going to be updated, since we should also allow the user to make manual changes so simply replacing the file wouldn't work.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, May 5, 2010 at 2:38 PM, Linas <linas_fi@ymail.com> wrote:
Allan McRae wrote:
The first method is what is currently used on the gpg patches that are available. The signature is made in a separate file and then is inserted in the repo db when the package is added.
I would prefer having the signature along the package. Maybe as a tar extended header. This way you can't lose the detached signature (it also means that you need to download twice as much files).
Hey, that would be cool! We wouldn't need to change the name structure of the package and would not lose the signature.
Could the trust database be updated via pacman using post_install on some pacman-keychain package?
Allan I don't see how is the pacman-keychain database going to be updated, since we should also allow the user to make manual changes so simply replacing the file wouldn't work.
There'll be a script for that, so users and the post-install script will be able to handle it without getting into the details of keyring manipulation. It will be something like: # pacman-key --import <keyfile> # pacman-key --trust <keyid> post-install would call pacman-key --updatedb and the script would delete the old keys and append the new ones, as I wrote in the reply to Allan. This must be called as root, but pacman is always called as root also, so it is not a problem. In the last case, the user will have to explicitly inform the trust level of the key. We even could automate this, but I don't think is a good idea. The user must have responsibility for his system (Arch Way rules). I'll try to commit it to gitorious as soon as I get home, so you can have a look and the discussion is brought to a more practical level too. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wed, May 5, 2010 at 2:49 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, May 5, 2010 at 2:38 PM, Linas <linas_fi@ymail.com> wrote:
I would prefer having the signature along the package. Maybe as a tar extended header. This way you can't lose the detached signature (it also means that you need to download twice as much files).
Hey, that would be cool! We wouldn't need to change the name structure of the package and would not lose the signature.
In fact, that is not possible. Because the signature is made over a stream of bytes, independent of the real content. So, the signing for a .tar.gz is absolutely identical to a signing to a text file or whatever else. If you sign the .tar file and after that sign and insert the signature inside the .tar, you'll invalidate the signature, because the original stream of bytes is not the same anymore. What we could do in the future is to have a signed package format, with an internal .tar.xz file (the real package) and the signature tarred together. But I think this is the least of our worries.
Could the trust database be updated via pacman using post_install on some pacman-keychain package?
Allan I don't see how is the pacman-keychain database going to be updated, since we should also allow the user to make manual changes so simply replacing the file wouldn't work.
There'll be a script for that, so users and the post-install script will be able to handle it without getting into the details of keyring manipulation. It will be something like:
# pacman-key --import <keyfile> # pacman-key --trust <keyid>
post-install would call pacman-key --updatedb and the script would delete the old keys and append the new ones, as I wrote in the reply to Allan. This must be called as root, but pacman is always called as root also, so it is not a problem.
In the last case, the user will have to explicitly inform the trust level of the key. We even could automate this, but I don't think is a good idea. The user must have responsibility for his system (Arch Way rules). I'll try to commit it to gitorious as soon as I get home, so you can have a look and the discussion is brought to a more practical level too.
I've not yet committed the script, but I'm sending it here (the pastebin will expire in 1 month), so we all can play with it and send suggestions. It is very similar to apt-key, but has some enhancements. One of them is the command to trust in a key. The fingerprint of the key will be shown to the user and the key will be edited in gpg (with the --edit-key command). The user will then confirm if the fingerprint is correct and type 'trust'. gpg will ask him what is the level of trust and the change will be saved on the trust db of pacman. http://pastebin.com/YxGM1Sxq -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wed, May 5, 2010 at 10:18 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote: Just replying to say that I've edited the script, because now I've really tested it :) I think it is working as should now. Suggestion of test: export a key from your personal keyring with $ gpg --export <keyid> > mykey.asc And after import it with the script: $ sudo pacman-key import mykey.asc To trust it: $ sudo pacman-key trust <keyid> The script will show the fingerprint and ask gpg to enter in edit mode for the key. You must type 'trust" and press enter. gpg will ask what is the level of trust you want to assign the the key. I will test more use cases (like signing a third party key and importing it in pacman's keyring to see if gpg will compute the right trust level).
Stay tunned... -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Thu, May 6, 2010 at 12:57 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
I will test more use cases (like signing a third party key and importing it in pacman's keyring to see if gpg will compute the right trust level).
This pastebin is the current development for pacman-key. Still needs some more testing. http://pastebin.com/JcAevBjL -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Friday 07 May 2010 04:10:44 Denis A. Altoé Falqueto wrote:
On Thu, May 6, 2010 at 12:57 AM, Denis A. Altoé Falqueto
<denisfalqueto@gmail.com> wrote:
I will test more use cases (like signing a third party key and importing it in pacman's keyring to see if gpg will compute the right trust level).
This pastebin is the current development for pacman-key. Still needs some more testing.
I did some very basic testing and it looks like it is working ok. Still thinking further - if the signatures are updated with pacman-keyring package, what if user doesn't update often and skips one or more versions of this package? Does this means that user still will have some unremoved signatures in his pacman keyring? Correct me if I understand this wrong. And other question, if some developers key becomes invalid, how to deal with all packages in the repos signed with this signature? -- Aleksis Jauntēvs
On Fri, May 7, 2010 at 9:28 AM, Aleksis Jauntēvs <aleksis.jauntevs@gmail.com> wrote:
Still thinking further - if the signatures are updated with pacman-keyring package, what if user doesn't update often and skips one or more versions of this package? Does this means that user still will have some unremoved signatures in his pacman keyring? Correct me if I understand this wrong.
The nomenclature for the "added" keys file is not really the best. The idea is that it would be the set of current valid keys. So, the updatedb process would just be: current keyring - deleted keys + valid keys. When a key is approved, it goes to the set of valid keys and stays there until it is revoked or disabled by moving it to the deleted keys set. So, even if a user miss a pacman-keyring package update, the next will still contain all valid keys and the result will be correct.
And other question, if some developers key becomes invalid, how to deal with all packages in the repos signed with this signature?
I think they should be at least re-signed by a valid dev key. Maybe, if some package was compromised, it should be rebuilt and re-signed by a valid dev key. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Denis A. Altoé Falqueto wrote:
On Wed, May 5, 2010 at 2:49 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, May 5, 2010 at 2:38 PM, Linas <linas_fi@ymail.com> wrote:
I would prefer having the signature along the package. Maybe as a tar extended header. This way you can't lose the detached signature (it also means that you need to download twice as much files).
Hey, that would be cool! We wouldn't need to change the name structure of the package and would not lose the signature.
In fact, that is not possible. Because the signature is made over a stream of bytes, independent of the real content. So, the signing for a .tar.gz is absolutely identical to a signing to a text file or whatever else. If you sign the .tar file and after that sign and insert the signature inside the .tar, you'll invalidate the signature, because the original stream of bytes is not the same anymore. What we could do in the future is to have a signed package format, with an internal .tar.xz file (the real package) and the signature tarred together. But I think this is the least of our worries.
In fact, for tar.gz it is possible since gzip ignores trailing content after a nul, so the signature could be appended there without interfering with non-aware utils. That possibility was used to create illegal primes on the 09 F9 11... "controversy". See http://en.wikipedia.org/wiki/Illegal_prime I didn't mention it because we are now using xz, and it may not support that. Is anyone here familiar with its format? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Thu, May 6, 2010 at 2:06 PM, Linas <linas_fi@ymail.com> wrote:
In fact, for tar.gz it is possible since gzip ignores trailing content after a nul, so the signature could be appended there without interfering with non-aware utils. That possibility was used to create illegal primes on the 09 F9 11... "controversy". See http://en.wikipedia.org/wiki/Illegal_prime
I didn't mention it because we are now using xz, and it may not support that. Is anyone here familiar with its format?
I would avoid using hacks that depend on compression format. Better stay flexible and compatible.
On 06/05/10 03:38, Linas wrote:
Allan McRae wrote:
The first method is what is currently used on the gpg patches that are available. The signature is made in a separate file and then is inserted in the repo db when the package is added.
I would prefer having the signature along the package. Maybe as a tar extended header. This way you can't lose the detached signature (it also means that you need to download twice as much files).
But you do not need to... you download the repo db (which contains the signature) and the package. Same as always.
participants (8)
-
Aleksis Jauntēvs
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Denis A. Altoé Falqueto
-
Florian Pritz
-
Linas
-
Xavier Chantry