New post since above is so big:
I’ve found the problem!
This is a two-fold problem:
-
$PATH
does not have/usr/local/bin
in it for PHP-FPM. Thus,php-gnupg
cannot find GPG by default. (side-note: suggestion to add a custom$PATH
orfile_name
(accepted bygnupg()
ctor) to config?) - The
gpgme
library itself has a bug, which ultimately made the one of the first things I tried (settingfile_name
in thegnupg()
ctor) a no-op. Explanation follows.
In short:
- The PHP module calls
gpgme_ctx_set_engine_info
to setfile_name
when it’s provided. - That ultimately calls
_gpgme_set_engine_info
. - Said function has a bug (see lines 405-413):
When GPG cannot be found in the path, the context is initialized with a single protocol:Spawn
. So when the PHP module (or anyone else, for that matter) tries to set the info forGPGME_PROTOCOL_OpenPGP
, it cannot find the appropriate protocol in the list of infos. So the entire thing fails withGPG_ERR_INV_ENGINE
. This is the bug ingpgme
. - Back at the PHP module, the result of
gpgme_ctx_set_engine_info
is not checked, so the error is silently ignored. In other words, we have agpgme
context with no valid engines/protocols.
I’m unsure whether ignoring this return value is a bug inphp-gnupg
or by design (and if it’s by design, it’s poor design). - When a
$_gpg->import($key)
is ultimately attempted, there is no validOpenPGP
protocol, since only the (very minimal)Spawn
protocol is present. Hence,GPG_ERR_UNSUPPORTED_PROTOCOL
.
The solution is to fix $PATH
for my php-fpm install; nevertheless, a “proper” fix would be to make gpgme
support file_name
properly and maybe add a configuration option to Passbolt, for the path to gpg
/gpg2
(because even if it’s available in $PATH
, perhaps a different version would be desired).
Though for now, that’s impossible, and only the path to the GPG executable is possible. (since $PATH
is the only way to make this work in all cases at the moment)
Bug tickets: