[pacman-dev] Finishing off the package signing issue -- Update
All, I examined the code in pacman's git master branch, and I found that it appears nearly finished. There are some issues, both blocking and non-blocking. Note that the following statements are to be interpreted as suggestions and may be revised if anyone has objections; if there are no objections, then this is the course of action that should be taken. Blocking: 1) The option/function naming conventions need to be unified, per https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . This will be significantly harder to fix once the signing feature is shipped. 2) A means of initially installing keys and of updating the list of keys must be created. This will be implemented as a package called pacman-keys. [1] 3) The Arch Developers must create keys. The page https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages must be finalized, and then an informational email can be posted to arch-general. 4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made. 5) The existing packages and databases on the central repository need to be signed. A single developer can do this. 6) The entire signing process needs to be tested, and pactest tests should be written for it. 7) The pacman manpage should be reviewed and finalized. Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience. 2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package. 3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized. 3) The page http://www.archlinux.org/download/ needs to be made to use HTTPS. This can be done independently of package signing implementation, but is necessary for complete security. 4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keys package. 5) Further issues are given at https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . I have not had a chance to investigate these issues, but they appear to be non-blocking. Questions: 1) I am unsure as to who has access to the central repository regarding blocking issue 4, so if someone could clarify, I would appreciate it. 2) pacman-key should be updated after pacman but before any other packages. I am not sure if the SyncFirst field in /etc/pacman.conf supports this behavior. If not, the two packages will be both placed in this field and will be designed to install properly in either order until the SyncFirst functionality can be improved. 3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure. 4) I haven't yet had a chance to see how the documentation is, but pacman's manpage should be reviewed before shipping; manpages for developer-side tools can be reviewed after shipping. 5) I'm not sure what "output when downloading signature file - name when downloaded" from https://wiki.archlinux.org/index.php/User:Allan/Package_Signing means. I think it means that there is no indication when a database signature is being downloaded. I realize this message was rather long and does not have any patches attached to it. I apologize, but I felt that these basic points should be straightened out as development work continues. Tomorrow, I will transcribe some of the information in this email to https://wiki.archlinux.org/index.php?title=Pacman_package_signing, with expanded information on outstanding issues. If you are interested, please adopt an issue and also inform others so that work is not duplicated. If you have information that may be useful to others working on package signing, please place it on this page. I am working on blocking issue 1 and will be done fairly soon. I will then start to work on 2 and 3. 6 and 7 are big issues, so if anyone wants to help out, that'd be a good place. 4 and 5 require action of the Arch Developers; I only list them for completion. [1] This package will place keys (as generated by gpg --export) into the /etc/pacman.d/gnupg/pacman_valid_keys and /etc/pacman.d/gnupg/pacman_revoked_keys directories. The .INSTALL file will update the /etc/pacman.d/gnupg/trustdb.gpg according to the directories' contents. The PKGBUILD for this package will download valid and revoked keys from an HTTPS page on archlinux.org. Before the package is updated, the HTTPS page will be updated, so that the package will contain the changes when built on the developer's machine. The PKGBUILD cannot just copy keys out of the trustdb (with a special option to add or revoke keys for developers) because the PKGBUILD should be able to make the package even when the package isn't already properly installed. Or maybe it can just copy them; I'm too tired right now to decide which is best. Carpe Noctem, Kerrick Staley
On Mon 30 May 2011 at 04:43 -0500, Kerrick Staley wrote:
Blocking: 1) The option/function naming conventions need to be unified, per https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . This will be significantly harder to fix once the signing feature is shipped.
There is not really a problem there (at least, it doesn't get worse currently).
2) A means of initially installing keys and of updating the list of keys must be created. This will be implemented as a package called pacman-keys. [1]
3) The Arch Developers must create keys. The page https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages must be finalized, and then an informational email can be posted to arch-general.
This process is already ongoing.
4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made.
Your proposed method of exchanging keys is absolutely against all my principles. The maintainer of the keyring already knows the list of developers (which is publicly available on archlinux.org). He/She adds keys according to a trust level, which is evaluated according to key signatures made by CACert and/or other Archlinux developers.
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
There is absolutely no way I sign a package that I didn't build myself, unless I feel personally linked to it. Moreover, a signed database is sufficient to initiate the process. Signed packages are an additional and independent security.
6) The entire signing process needs to be tested, and pactest tests should be written for it.
7) The pacman manpage should be reviewed and finalized.
Nothing specific to signing here, just the usual release process of pacman.
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keys package.
This doesn't seem necessary if the pacman-keys package is itself signed.
Questions: 1) I am unsure as to who has access to the central repository regarding blocking issue 4, so if someone could clarify, I would appreciate it.
2) pacman-key should be updated after pacman but before any other packages. I am not sure if the SyncFirst field in /etc/pacman.conf supports this behavior. If not, the two packages will be both placed in this field and will be designed to install properly in either order until the SyncFirst functionality can be improved.
3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure.
I don't know what you mean, our signatures are uploaded along with packages.
4) I haven't yet had a chance to see how the documentation is, but pacman's manpage should be reviewed before shipping; manpages for developer-side tools can be reviewed after shipping.
This is part of the usual release process of pacman. -- Rémy.
All, On Mon, May 30, 2011 at 6:50 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made.
Your proposed method of exchanging keys is absolutely against all my principles. The maintainer of the keyring already knows the list of developers (which is publicly available on archlinux.org). He/She adds keys according to a trust level, which is evaluated according to key signatures made by CACert and/or other Archlinux developers.
We'll assume that only trustworthy individuals can currently access the central repository server, because it's probably true [1]. Therefore, we can accept a key given by anyone who can access this server, without any need for further verification; this can expedite the key verification process. I am unfamiliar with CACert, but it doesn't seem useful because it only verifies the supplied email address, and email is assumed to be an insecure channel (plus, the name needs to be verified).
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
There is absolutely no way I sign a package that I didn't build myself, unless I feel personally linked to it. Moreover, a signed database is sufficient to initiate the process. Signed packages are an additional and independent security.
They have to be signed somehow. If a db has packages with hashes but not signatures, and pacman accepts these packages as long as the db is signed, then whoever signs the db effectively is signing for all the unsigned packages. However, the method you suggest is equally acceptable, so we will add SHA256 hashes to the repos, and pacman will accept packages with valid hashes from a signed db, until all packages are signed, at which point pacman's behavior will be changed to not accept such packages.
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keyshas package.
This doesn't seem necessary if the pacman-keys package is itself signed.
You're right. The idea was that since pacman-keys will be initially installed without a signature check, taking this measure will make it more difficult for any currently compromised mirrors to tamper with the updates that add package signing. However, it will not make the system theoretically more secure, and in retrospect the practical benefits seem slim as well.
3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure.
I don't know what you mean, our signatures are uploaded along with packages.
I meant "keys", not "signatures"; sorry. On Mon, May 30, 2011 at 10:27 AM, Dave Reisner <d@falconindy.com> wrote:
Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience.
I consider this a blocker. Also note that if this had a simple solution, it would have been done by now. Ideas welcome.
As I said, we can fix this after shipping the initial signing-related updates. Ship early/ship often, simplicity is far more important than completeness, and all that jazz. I'd argue further, but in the interest of saving your time and mine, let's let Dan decide.
2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package.
I consider this a blocker. To roll out a tool which implements a standard procedure, but which is only half complete, is a waste.
We won't ship pacman-key out at all until it is working well. In the meantime, end-users can get its functionality if needed by manually invoking gpg.
... Not a concern to be addressed on pacman-dev. ...
tl;dr. You seem to have issues separating what happens here on pacman-dev from what happens in Arch Linux. Although the majority of pacman's userbase _is_ indeed Arch Linux, we maintain portability to OSX, cygwin, and the BSDs. Anything to do with Arch Linux packages _specifically_ has no effect on our ability to roll out a new release of pacman.
Security is a system, not a line of code, and other distributions will need to implement a secure system if they want to use pacman as their package manager. Hence, broader discussion about the implementation of signing should take place on this list; anything specific to Arch can be generalized to other distributions. You're correct in that we don't have to wait on the infrastructure to ship an updated pacman, but I'm personally only interested in achieving a working implementation of package signing on Arch Linux, and so I will frame my discussion appropriately. Perhaps I could have clarified that "Blocking" and "Non-Blocking" are relative to this goal.
Your original statement implied that you would be providing some sort of 'course of action'. All I see is a high level analysis of what we already know, with nothing in the realm of deliverables.
Where "we" is non-inclusive of myself and other developers new to this issue. I'm trying to save others the work of extracting this information for themselves and also to lay out a plan for future work. Sincerest love, Kerrick Staley [1] Also, any development we do operates under the assumption that an attacker will not be able to tamper with any packages before we get the signing feature shipped out and working. If an attacker can access the central repository and has a key they would like added to all Arch systems, they can just edit the .INSTALL of the most recently updated package so that it installs the key; tricking the pacman-keys maintainer is unnecessary. This is an unlikely situation, but I felt it would be best to supplement the "it's probably true" justification with a logical one. See "Reflections on Computing Trust" by Ken Thompson for a discussion of a related issue.
s/non-inclusive/exclusive/ I shouldn't write things at 4:30 AM. On Wed, Jun 1, 2011 at 12:56 AM, Kerrick Staley <mail@kerrickstaley.com> wrote:
All,
On Mon, May 30, 2011 at 6:50 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made.
Your proposed method of exchanging keys is absolutely against all my principles. The maintainer of the keyring already knows the list of developers (which is publicly available on archlinux.org). He/She adds keys according to a trust level, which is evaluated according to key signatures made by CACert and/or other Archlinux developers.
We'll assume that only trustworthy individuals can currently access the central repository server, because it's probably true [1]. Therefore, we can accept a key given by anyone who can access this server, without any need for further verification; this can expedite the key verification process. I am unfamiliar with CACert, but it doesn't seem useful because it only verifies the supplied email address, and email is assumed to be an insecure channel (plus, the name needs to be verified).
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
There is absolutely no way I sign a package that I didn't build myself, unless I feel personally linked to it. Moreover, a signed database is sufficient to initiate the process. Signed packages are an additional and independent security.
They have to be signed somehow. If a db has packages with hashes but not signatures, and pacman accepts these packages as long as the db is signed, then whoever signs the db effectively is signing for all the unsigned packages.
However, the method you suggest is equally acceptable, so we will add SHA256 hashes to the repos, and pacman will accept packages with valid hashes from a signed db, until all packages are signed, at which point pacman's behavior will be changed to not accept such packages.
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keyshas package.
This doesn't seem necessary if the pacman-keys package is itself signed.
You're right. The idea was that since pacman-keys will be initially installed without a signature check, taking this measure will make it more difficult for any currently compromised mirrors to tamper with the updates that add package signing. However, it will not make the system theoretically more secure, and in retrospect the practical benefits seem slim as well.
3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure.
I don't know what you mean, our signatures are uploaded along with packages.
I meant "keys", not "signatures"; sorry.
On Mon, May 30, 2011 at 10:27 AM, Dave Reisner <d@falconindy.com> wrote:
Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience.
I consider this a blocker. Also note that if this had a simple solution, it would have been done by now. Ideas welcome.
As I said, we can fix this after shipping the initial signing-related updates. Ship early/ship often, simplicity is far more important than completeness, and all that jazz. I'd argue further, but in the interest of saving your time and mine, let's let Dan decide.
2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package.
I consider this a blocker. To roll out a tool which implements a standard procedure, but which is only half complete, is a waste.
We won't ship pacman-key out at all until it is working well. In the meantime, end-users can get its functionality if needed by manually invoking gpg.
... Not a concern to be addressed on pacman-dev. ...
tl;dr. You seem to have issues separating what happens here on pacman-dev from what happens in Arch Linux. Although the majority of pacman's userbase _is_ indeed Arch Linux, we maintain portability to OSX, cygwin, and the BSDs. Anything to do with Arch Linux packages _specifically_ has no effect on our ability to roll out a new release of pacman.
Security is a system, not a line of code, and other distributions will need to implement a secure system if they want to use pacman as their package manager. Hence, broader discussion about the implementation of signing should take place on this list; anything specific to Arch can be generalized to other distributions. You're correct in that we don't have to wait on the infrastructure to ship an updated pacman, but I'm personally only interested in achieving a working implementation of package signing on Arch Linux, and so I will frame my discussion appropriately. Perhaps I could have clarified that "Blocking" and "Non-Blocking" are relative to this goal.
Your original statement implied that you would be providing some sort of 'course of action'. All I see is a high level analysis of what we already know, with nothing in the realm of deliverables.
Where "we" is non-inclusive of myself and other developers new to this issue. I'm trying to save others the work of extracting this information for themselves and also to lay out a plan for future work.
Sincerest love, Kerrick Staley
[1] Also, any development we do operates under the assumption that an attacker will not be able to tamper with any packages before we get the signing feature shipped out and working. If an attacker can access the central repository and has a key they would like added to all Arch systems, they can just edit the .INSTALL of the most recently updated package so that it installs the key; tricking the pacman-keys maintainer is unnecessary. This is an unlikely situation, but I felt it would be best to supplement the "it's probably true" justification with a logical one. See "Reflections on Computing Trust" by Ken Thompson for a discussion of a related issue.
On 2011/6/1 Kerrick Staley <mail@kerrickstaley.com> wrote:
tl;dr. You seem to have issues separating what happens here on pacman-dev from what happens in Arch Linux. Although the majority of pacman's userbase _is_ indeed Arch Linux, we maintain portability to OSX, cygwin, and the BSDs. Anything to do with Arch Linux packages _specifically_ has no effect on our ability to roll out a new release of pacman.
Security is a system, not a line of code, and other distributions will need to implement a secure system if they want to use pacman as their package manager. Hence, broader discussion about the implementation of signing should take place on this list; anything specific to Arch can be generalized to other distributions. You're correct in that we don't have to wait on the infrastructure to ship an updated pacman, but I'm personally only interested in achieving a working implementation of package signing on Arch Linux, and so I will frame my discussion appropriately. Perhaps I could have clarified that "Blocking" and "Non-Blocking" are relative to this goal.
Hello Kerrick, As you say, pacman is not a system, just lines of code, it provides tools to use gpg as a security system, and any system discussions go to arch-general@archlinux.org. Few Archlinux developers, as far as I know, read the pacman-dev mailing-list. Rémy.
On 01/06/11 15:56, Kerrick Staley wrote:
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
There is absolutely no way I sign a package that I didn't build myself, unless I feel personally linked to it. Moreover, a signed database is sufficient to initiate the process. Signed packages are an additional and independent security.
They have to be signed somehow. If a db has packages with hashes but not signatures, and pacman accepts these packages as long as the db is signed, then whoever signs the db effectively is signing for all the unsigned packages.
However, the method you suggest is equally acceptable, so we will add SHA256 hashes to the repos, and pacman will accept packages with valid hashes from a signed db, until all packages are signed, at which point pacman's behavior will be changed to not accept such packages.
Seem that somebody might have already thought about a transition period where only some packages are signed by allowing VerfiySug to take values Optional and Always...
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keyshas package.
This doesn't seem necessary if the pacman-keys package is itself signed.
You're right. The idea was that since pacman-keys will be initially installed without a signature check, taking this measure will make it more difficult for any currently compromised mirrors to tamper with the updates that add package signing. However, it will not make the system theoretically more secure, and in retrospect the practical benefits seem slim as well.
Why would it be installed without a signature check? I'm assuming that any user can download the "pacman-keyring" package (because that is the more likely name than pacman-keys....) and its signature and do some manual verification. In fact, I do not see the point of installing such a package at all without a signature check as that is a fail from the start.
On Mon, May 30, 2011 at 10:27 AM, Dave Reisner<d@falconindy.com> wrote:
Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience.
I consider this a blocker. Also note that if this had a simple solution, it would have been done by now. Ideas welcome.
As I said, we can fix this after shipping the initial signing-related updates. Ship early/ship often, simplicity is far more important than completeness, and all that jazz. I'd argue further, but in the interest of saving your time and mine, let's let Dan decide.
2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package.
I consider this a blocker. To roll out a tool which implements a standard procedure, but which is only half complete, is a waste.
We won't ship pacman-key out at all until it is working well. In the meantime, end-users can get its functionality if needed by manually invoking gpg.
Hmm... we can ship pacman early and often without full functionality but not pacman-key. Good thing for consistent policies... I'd say all the patches needed for pacman-key to be production ready are already on the mailing list. And it is actually quite functional as it currently is in git. I have been using it to manage my pacman keyring for months. Allan
On Mon, May 30, 2011 at 04:43:02AM -0500, Kerrick Staley wrote:
All,
I examined the code in pacman's git master branch, and I found that it appears nearly finished. There are some issues, both blocking and non-blocking. Note that the following statements are to be interpreted as suggestions and may be revised if anyone has objections; if there are no objections, then this is the course of action that should be taken.
Blocking: 1) The option/function naming conventions need to be unified, per https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . This will be significantly harder to fix once the signing feature is shipped.
Any suggestions you might have in patch form are more than welcome, and will help get the ball rolling.
2) A means of initially installing keys and of updating the list of keys must be created. This will be implemented as a package called pacman-keys. [1]
Not a concern to be addressed on pacman-dev.
3) The Arch Developers must create keys. The page https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages must be finalized, and then an informational email can be posted to arch-general.
Not a concern to be addressed on pacman-dev.
4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made.
Not a concern to be addressed on pacman-dev.
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
Not a concern to be addressed on pacman-dev. Also, insane.
6) The entire signing process needs to be tested, and pactest tests should be written for it.
Standard release practice.
7) The pacman manpage should be reviewed and finalized.
Standard release practice.
Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience.
I consider this a blocker. Also note that if this had a simple solution, it would have been done by now. Ideas welcome.
2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package.
I consider this a blocker. To roll out a tool which implements a standard procedure, but which is only half complete, is a waste.
3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized.
Standard release practice.
3) The page http://www.archlinux.org/download/ needs to be made to use HTTPS. This can be done independently of package signing implementation, but is necessary for complete security.
Not a concern to be addressed on pacman-dev.
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keys package.
Not a concern to be addressed on pacman-dev.
5) Further issues are given at https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . I have not had a chance to investigate these issues, but they appear to be non-blocking.
Questions: 1) I am unsure as to who has access to the central repository regarding blocking issue 4, so if someone could clarify, I would appreciate it.
2) pacman-key should be updated after pacman but before any other packages. I am not sure if the SyncFirst field in /etc/pacman.conf supports this behavior. If not, the two packages will be both placed in this field and will be designed to install properly in either order until the SyncFirst functionality can be improved.
3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure.
4) I haven't yet had a chance to see how the documentation is, but pacman's manpage should be reviewed before shipping; manpages for developer-side tools can be reviewed after shipping.
5) I'm not sure what "output when downloading signature file - name when downloaded" from https://wiki.archlinux.org/index.php/User:Allan/Package_Signing means. I think it means that there is no indication when a database signature is being downloaded.
I realize this message was rather long and does not have any patches attached to it. I apologize, but I felt that these basic points should be straightened out as development work continues.
Tomorrow, I will transcribe some of the information in this email to https://wiki.archlinux.org/index.php?title=Pacman_package_signing, with expanded information on outstanding issues. If you are interested, please adopt an issue and also inform others so that work is not duplicated. If you have information that may be useful to others working on package signing, please place it on this page.
I am working on blocking issue 1 and will be done fairly soon. I will then start to work on 2 and 3. 6 and 7 are big issues, so if anyone wants to help out, that'd be a good place. 4 and 5 require action of the Arch Developers; I only list them for completion.
[1] This package will place keys (as generated by gpg --export) into the /etc/pacman.d/gnupg/pacman_valid_keys and /etc/pacman.d/gnupg/pacman_revoked_keys directories. The .INSTALL file will update the /etc/pacman.d/gnupg/trustdb.gpg according to the directories' contents. The PKGBUILD for this package will download valid and revoked keys from an HTTPS page on archlinux.org. Before the package is updated, the HTTPS page will be updated, so that the package will contain the changes when built on the developer's machine. The PKGBUILD cannot just copy keys out of the trustdb (with a special option to add or revoke keys for developers) because the PKGBUILD should be able to make the package even when the package isn't already properly installed. Or maybe it can just copy them; I'm too tired right now to decide which is best.
tl;dr. You seem to have issues separating what happens here on pacman-dev from what happens in Arch Linux. Although the majority of pacman's userbase _is_ indeed Arch Linux, we maintain portability to OSX, cygwin, and the BSDs. Anything to do with Arch Linux packages _specifically_ has no effect on our ability to roll out a new release of pacman. Your original statement implied that you would be providing some sort of 'course of action'. All I see is a high level analysis of what we already know, with nothing in the realm of deliverables. regards, dave
On 30/05/11 19:43, Kerrick Staley wrote:
3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized.
I had pretty much declared makepkg and repo-add completely finished, including documentation. Did you have anything that actually needed adjusted in the current documentation? Allan
On Wed, Jun 1, 2011 at 3:07 AM, Allan McRae <allan@archlinux.org> wrote:
As I said, we can fix this after shipping the initial signing-related updates. Ship early/ship often, simplicity is far more important than completeness, and all that jazz. I'd argue further, but in the interest of saving your time and mine, let's let Dan decide. ...
We won't ship pacman-key out at all until it is working well. In the meantime, end-users can get its functionality if needed by manually invoking gpg.
Hmm... we can ship pacman early and often without full functionality but not pacman-key. Good thing for consistent policies...
I'd say all the patches needed for pacman-key to be production ready are already on the mailing list. And it is actually quite functional as it currently is in git. I have been using it to manage my pacman keyring for months.
Allan, The point is that while the features of pacman-key and user-signature-verification are useful, they are nonessential and shouldn't delay the launch of the package-signing feature if incomplete. You seemed to indicate that pacman-key isn't ready for use ("a key management tool call pacman-key is implemented. It still needs work and there are a bunch of patches on the mailing list for it. I hope to find time to finalise this in the near future..."), and I don't see why adding a thin layer of abstraction on top of GnuPG's functionality is needed, especially since users will not normally have to manually administer pacman's keyring. It's not a priority for me personally, and if it's not done when everything else is, then the signing feature can ship without it. On Wed, Jun 1, 2011 at 3:09 AM, Allan McRae <allan@archlinux.org> wrote:
On 30/05/11 19:43, Kerrick Staley wrote:
3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized.
I had pretty much declared makepkg and repo-add completely finished, including documentation. Did you have anything that actually needed adjusted in the current documentation?
No; I just noticed some unfinished areas in the pacman documentation and added this provision to the TODO list for completeness. -Kerrick Staley
On Wed, Jun 1, 2011 at 9:28 AM, Kerrick Staley <mail@kerrickstaley.com> wrote:
On Wed, Jun 1, 2011 at 3:07 AM, Allan McRae <allan@archlinux.org> wrote:
As I said, we can fix this after shipping the initial signing-related updates. Ship early/ship often, simplicity is far more important than completeness, and all that jazz. I'd argue further, but in the interest of saving your time and mine, let's let Dan decide. ...
We won't ship pacman-key out at all until it is working well. In the meantime, end-users can get its functionality if needed by manually invoking gpg.
Hmm... we can ship pacman early and often without full functionality but not pacman-key. Good thing for consistent policies...
I'd say all the patches needed for pacman-key to be production ready are already on the mailing list. And it is actually quite functional as it currently is in git. I have been using it to manage my pacman keyring for months.
Allan,
The point is that while the features of pacman-key and user-signature-verification are useful, they are nonessential and shouldn't delay the launch of the package-signing feature if incomplete. You seemed to indicate that pacman-key isn't ready for use ("a key management tool call pacman-key is implemented. It still needs work and there are a bunch of patches on the mailing list for it. I hope to find time to finalise this in the near future..."), and I don't see why adding a thin layer of abstraction on top of GnuPG's functionality is needed, especially since users will not normally have to manually administer pacman's keyring. It's not a priority for me personally, and if it's not done when everything else is, then the signing feature can ship without it.
The delays are as follows, and have nothing to do with pacman-key: * gpg locking sucks, it would be nice to not have to lock the trustdb when running unprivileged. * Lazy DB loading makes things much more difficult. I'm not willing to sacrifice this for signing, so striking a balance between when we check sigs and ensuring frontends (and our backend code!) are well aware the database won't be loaded due to a failed signature check is really important. This is probably the single biggest blocker, and perhaps why those not involved until now seem to think this is going at a snail's pace. If you'd like to see how big of a task this is, I will send my three different approaches in various stages of completion to the mailing list, none of which I am super happy with. * The download code still isn't quite where I think it needs to be for us; although this may not a blocker it gives some very confusing user output (extension stripping, 404's, etc.) and will likely lead to several bugs filed, which just costs us time down the road if we don't fix it now. * Architecting checks to be done in parallel in the future; we had a demo patchset posted for this when only doing md5 checks but I want to make sure we can do this again later for all types of package verification. -Dan
participants (5)
-
Allan McRae
-
Dan McGee
-
Dave Reisner
-
Kerrick Staley
-
Rémy Oudompheng