[pacman-dev] Finishing off the package signing issue -- Update

[Dan McGee]

On Wed, Jun 1, 2011 at 9:28 AM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> On Wed, Jun 1, 2011 at 3:07 AM, Allan McRae <allan at 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