Q1. What is the problem that you are trying to solve?
It is not always practical to add system-level extension like GnuPG. Moreover, it exists some composer module like https://github.com/phar-io/gnupg which can be used instead.
Q2 - Who is impacted?
Anyone who wants to install Passbolt but don’t have access to set system-level extension.
Q3 - Why is it important and/or urgent?
It reduces the requirements needed for Passbolt installation, for instance by allowing its installation on cheap shared hosting, and thus helping its adoption.
Q4 - What is your proposed solution? (optional)
use a composer module to wrap gnupg binary instead of relying of extension
@samuel thanks for the suggestions. Some thoughts in random order:
pure php implementation should be possible but it will be slower.
we need to put some process in place to consider also is the security of these libs, like how should we review them / make sure they are maintained etc.
In the long run it will also increase integration testing effort (we’ll have to run all testsuites against different backend). The full testsuite runs in about 30min now. That’s already quite bit.
We have a similar issue with the plugin but the other way around. Some people are pretty vocal (e.g. gave bad reviews…) because we don’t support native gnupg integration.
I’ve heard some folks are working on a rust clone of gnupg
@samuel it comes it with own set of problems too, most of the support we get is related to php-gnupg and keyring access/management. So yeah, no perfect solution for now.
@2mt.Heuser do you have some pointers on how to switch to libsodium and still maintain compatibility with OpenPGP? One of the goal of this project is to avoid non interoperable crypto.
@remy Not really no. Sorry… I just stumbled into here while browsing around and having worked with sodium the last weeks on some tinker project (sharing secrets that burn/get destroyed after being opened)
I thought it would be at least a possibility to migrate from one to the other in the future.
It’s not back<>forth compatible, afaik, but would be something like a migration where the server de/encrypts from one to the other once.
(A bit like when frameworks/shops/whatever updated from md5 to sha etc. and users had to reset their passwords once so a new hash could be generated)
And as sodium is finally native, has strong algorythms and doesn’t rely on extensions & binaries, PB could be hosted even on hosts where there’s no option to get those things up&running. (7.2. is not available everywhere but as LTS shifts and 7.0/5.6 end soon, hosters will have to adapt to keep their clients happy)
@2mt.Heuser there was some discussions on pure php openpgp implementation lib to use libsodium for some of the crypto. Not sure where it’s at. https://github.com/singpolyma/openpgp-php
For me migrating away from openpgp standard is not on the menu (though I can see the benefits of what you are suggesting).
Maybe it’s even possible to make the php-gnupg extension optional by falling back to using gpg via shell_exec or similar? That might already help people who can use gpg via the console but have no gnupg extension installed (and can’t due to no root access).
Just a quick idea I had without even knowing in which way the php extension is used by passbolt and if that can be achieved via a console gpg call.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)