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