From: Tomi Ollila <tomi.ollila@iki.fi>
To: David Bremner <david@tethera.net>,
 Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
 Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH 7/9] add a gpg_path value for notmuch_database_t
In-Reply-To: <87d1ubdu0k.fsf@zancas.localnet>
References: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net>
 <1449718786-28000-8-git-send-email-dkg@fifthhorseman.net>
 <m21tas7ifa.fsf@guru.guru-group.fi> <87mvtgfws4.fsf@alice.fifthhorseman.net>
 <87d1ubdu0k.fsf@zancas.localnet>
User-Agent: Notmuch/0.21+32~g73439f8 (http://notmuchmail.org) Emacs/24.3.1
 (x86_64-unknown-linux-gnu)
Date: Sun, 13 Dec 2015 13:00:05 +0200
Message-ID: <m24mfmbolm.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Sun, Dec 13 2015, David Bremner <david@tethera.net> wrote:

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> On Fri 2015-12-11 17:02:33 -0500, Tomi Ollila wrote:
>>> The above code finds gpg/gpg2 (when called w/ these args) from
>>> _CS_PATH (seems to be /bin:/usr/bin by default in linux (tried to
>>> look how this set in *BSD -- initially it looks like /usr/local/bin
>>> not included but... maybe we let them to complain if this is the case
>>> ... :/)
>>> ... anyway, the full found path is not set anywhere -- how is it found
>>> when used (exec*p() using $PATH? :O)
>>
>> Hm, according to exec(3):
>>
>>    Special semantics for execlp() and execvp()
>>        The execlp(), execvp(), and execvpe() functions duplicate the
>>        actions of the shell in searching for an executable file if the
>>        specified filename does not contain a slash (/) character.  The
>>        file is sought in the colon-separated list of directory pathnames
>>        specified in the PATH environment variable.  If this variable
>>        isn't defined, the path list defaults to the current directory
>>        followed by the list of directories returned by
>>        confstr(_CS_PATH).  (This confstr(3) call typically returns the
>>        value "/bin:/usr/bin".)
>>
>> So this code probably also ought to be searching $PATH as well.  yuck.
>> You'd think there would be a commonly-available function for doing this
>> specific check without having to actually try to exec() something.
>
> Without weighing in on the advisibility of searching for gpg in $PATH,
> there is a glib function g_find_program_in_path. We're already linking
> to glib (because of gmime mainly, but it's used other places as well).

glib2-2.38 (glib/gutils.c) seems to look in PATH, and if 
g_getenv ("PATH") == NULL uses hardcoded path "/bin:/usr/bin:.";
(it us "security" feature to have '.' last...)

If rest is TL;DR; I'd suggest we use this... since libgpgme has implemented
it IMO too late for use in 2016 (or do additional compat function?)

> The other point that occurs to me is that libgpgme solves this same
> problem in src/posix-util.c. It also seems to search path, at least
> optionally, although only if it cannot find gpgconf.

On Fedora 20 I looked gpgme-1.3.2 sources -- in there I could not find
this search using PATH... gpg-1.3.2 is released 2012-05-02...

Jessie (lib)gpgme 1.5.1 (2014-07-30) seems to have the code David mentioned...
(btw. I was suprisingly hard to search Debian packages; IIRC it was easier)

Ubuntu 14.04 LTS has (lib)gpgme 1.4.3 (ubuntu5). I did not download that
source... but 1.5.1 NEWS indicates that this PATH search has arrived to
1.5.0 (2014-05-21)

This search is different from glib2-version that if getenv("PATH") == NULL
search only "/bin:/usr/bin"