[pacman-dev] [PATCH 2/6] Remove use of gpgme
gpgme is very good when the keyring is the default, or if the requirements are simple. But for a specialized keyring, like pacman's, it is not flexible enough. This patch removes the checking of configure.ac. Signed-off-by: Denis A. Altoé Falqueto <denisfalqueto@gmail.com> --- configure.ac | 4 ---- lib/libalpm/alpm.h | 1 - lib/libalpm/error.c | 2 -- 3 files changed, 0 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index b6ce68b..008975b 100644 --- a/configure.ac +++ b/configure.ac @@ -154,10 +154,6 @@ else fi AM_CONDITIONAL(INTERNAL_DOWNLOAD, test "x$internaldownload" = "xyes") -# Check for gpgme -AC_CHECK_LIB([gpgme], [gpgme_check_version], , - AC_MSG_ERROR([gpgme is needed to compile pacman!])) - # Checks for header files. AC_CHECK_HEADERS([fcntl.h glob.h libintl.h limits.h locale.h string.h strings.h sys/ioctl.h sys/param.h sys/statvfs.h sys/syslimits.h sys/time.h syslog.h wchar.h]) diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 2ce049d..d72cb8e 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -550,7 +550,6 @@ enum _pmerrno_t { /* External library errors */ PM_ERR_LIBARCHIVE, PM_ERR_LIBFETCH, - PM_ERR_GPGME, PM_ERR_EXTERNAL_DOWNLOAD }; diff --git a/lib/libalpm/error.c b/lib/libalpm/error.c index 907a9f2..1fccc46 100644 --- a/lib/libalpm/error.c +++ b/lib/libalpm/error.c @@ -158,8 +158,6 @@ const char SYMEXPORT *alpm_strerror(int err) /* obviously shouldn't get here... */ return _("download library error"); #endif - case PM_ERR_GPGME: - return _("gpgme error"); case PM_ERR_EXTERNAL_DOWNLOAD: return _("error invoking external downloader"); /* Unknown error! */ -- 1.7.1
On Wed, Jul 7, 2010 at 7:43 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
gpgme is very good when the keyring is the default, or if the requirements are simple. But for a specialized keyring, like pacman's, it is not flexible enough. This patch removes the checking of configure.ac.
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 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. 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.
On Thu, Jul 8, 2010 at 10:45 AM, Xavier Chantry <chantry.xavier@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 -------------------------------------------
On Thu, Jul 8, 2010 at 11:32 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
I'll reply latter with results from the rpm analysis.
I couldn't find any traces of gpgme in rpm-4.8.1 sources. They seems to use NSS [1] instead. [1] http://www.mozilla.org/projects/security/pki/nss/ -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
participants (2)
-
Denis A. Altoé Falqueto
-
Xavier Chantry