passbolt_api
passbolt_api copied to clipboard
passbolt
Make passbolt work without the php gnupg extension
Make passbolt work without the php gnupg extension
Many php webhosters don't come with the php gnupg extension but you can relatively easily copy a binary distribution of gpg to them. It would be great if passbolt would support this alternative method of using gpg.
This MR is based on the MR from sknss: https://github.com/passbolt/passbolt_api/pull/260
- [x] bug fix
- [ ] change of existing behavior
- [ ] new feature
Checklist
- [ ] User stories are present (given, when, then format)
- [ ] Unit tests are passing
- [ ] Selenium tests are passing
- [ ] Check style is not triggering new error or warning
What you did
- Added an extra GPG backend in src/Utility/OpenPGP/Backends that uses the "pear/crypt_gpg" library.
- Added the pear/crypt_gpg library to composer.
What is needed for this to be ready? My organization requires this so I'm happy to work on it
@luishfonseca If you install via source, you can add the patches to your instance anytime if needed.
@garrettboone thanks, I'm aware and that's what I plan to do while this isn't merged. But it would be better if future admins at my organization didn't have to worry with patching source code.
Related forum discussion: https://community.passbolt.com/t/as-an-admin-i-can-install-passbolt-without-the-need-of-gnupg-extension/176
@luishfonseca ( cc @pabloelcolombiano) we do not have plans to support this as it would mean adding Crypt_GPG to the list of dependencies and track the issues related to their dependencies / PHP version support, etc. We do not have the bandwith for this at the moment.
However we are open at allowing to specify/load a class that implements OpenPGPBackendInterface dynamically via the OpenPGPBackendFactory (with class name specified as a global config option / or loaded via the dependency injection system (cakephp container)). That would allow you to develop a custom openpgp backend and let it live in a plugin that you maintain, thus removing the need for a patching process. This is something we have on our internal roadmap for this year, but you're welcome to proceed with it if you are interested (with a new PR). We can discuss this further if you need clarification on the approach.
