[pacman-dev] [PATCH 2/6] Remove use of gpgme

[Denis A. Altoé Falqueto]

On Thu, Jul 8, 2010 at 10:45 AM, Xavier Chantry
<chantry.xavier at gmail.com> wrote:
> This patch in itself doesn't make much sense. Instead you would want
> to have one self-contained patch that does a simple conversion from
> gpgme to gpg cli.
> This move could be split in several steps, but then only in the last
> step which completely removes the gpgme dependency, you can also
> remove the checking of configure.ac

I see. I was so eager to keep the patches minimal, that I've broke it
too much. I'll update the patchset.

> Anyway, this is not a light step we are talking about here, it's a big
> implementation change which causes a complete rewrite.
> Rewrite are not bad, sometimes they are very good and much needed. But
> I am still waiting for a better and more verbose justification.

One of the biggest limitations of gpgme is a lack of thorough
configuration. We can just tell where the home directory for gpg is
and what executable for gpg will be used. There is not way to
configure how to trust keys signed by other keys, unless you use a
configuration file in the home dir of gpg. I've saw some people on the
net suggesting that this configuration would be another possible point
of failure, so I've tried to avoid it. That's why I hardcoded the
options, mainly the --no-options flag.

But when I try to justify it to myself, I also have some difficulty.
Should we just accept the limitations in configuration and stick with
the defaults (for example, names of files in the keyring directory,
number of signatures in a key to make it reliable, etc). I think I can
reimplement gpgme support easily if we decide for it.

> Dan, you mentioned some times ago you also spotted some limitations in
> gpgme, does it match Denis' description ? Is there really no way
> around ?
>
> And as always, I don't think that re-implementing the wheel without
> even knowing the good and bad sides of the existing implementations is
> a good idea. It would be interesting to know what the other package
> managers use.

I've read the source of apt at deep and they don't use gpgme too. They
use a stripped down version of gpg, called gpgv, which comes with the
gnupg package. The gpgv executable does not care for the web of trust
of the keyring, so I think that it is not a good idea to use it. You
can check the man page for gpgv, but, basically it just checks if a
key is present in the specified keyring. I am looking through rpm
right now to see how it deals with it, but a fast look through the
documentation doesn't show signs of use of a web of trust.

The thing about the web of trust is very important. I think we should
use it because it takes off the responsibility from the developers to
the users. The trust problem is complex, we should not hide this
complexity from the users.

And it gives more flexibility too. If a person wants to publish a
repository and wants to sign it, he can publish a single key to be
trusted explicitly by the user. Or he can have a complex structure
with master keys and keys signed by them, as the current proposal
suggests. The bottom line is that the user must explicitly trust a key
before it can be used. The simple fact of being present in a keyring
should not be enough to trust a key.

I'll reply latter with results from the rpm analysis.

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------