After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759392 - Allow custom gpg binary
Allow custom gpg binary
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
unspecified
Other All
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2015-12-13 00:27 UTC by Ángel
Modified: 2016-01-21 09:04 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
G_IS_EXECUTABLE (906 bytes, patch)
2016-01-21 00:01 UTC, Ángel 		reviewed Details | Review

Description Ángel 2015-12-13 00:27:32 UTC 
It should be possible to choose the path of the gpg program to use.

That is, gpg_ctx_get_executable_name()¹ would check in dconf, and if there's a configured path, use it instead of looking for gpg or gpg2 in the path.

This may not deserve an entry in the UI, though.



¹ evolution-data-server/camel/camel-gpg-context.c
Comment 1 Milan Crha 2016-01-19 18:37:41 UTC 
Thanks for a bug report. I fixed this. The change requires restart of the evolution (or any Camel library user) to take into the effect. Even I claim there a full path is required it's not fully true, but better have it there done this way. The key can be read:
 $ gsettings get org.gnome.evolution-data-server camel-gpg-binary
and wrote
 $ gsettings set org.gnome.evolution-data-server camel-gpg-binary '/usr/bin/gpg2'
There is a limit of 512 letters for the value, which I believe is sufficient.

Created commit d1cb6c3 in eds master (3.19.90+)
Comment 2 Ángel 2016-01-21 00:01:23 UTC 
Created attachment 319471 [details] [review]
G_IS_EXECUTABLE

Thanks Milan!

Looking at  the patch, shouldn't you also include G_FILE_TEST_IS_EXECUTABLE with g_file_test() ?
Comment 3 Milan Crha 2016-01-21 09:04:19 UTC 
Maybe I could, but I'm not going to. I didn't think of it, but it has a difference. The check there is to not point to an unknown file, in that case the user setting is ignored. It'll be better to return errors when users point to a valid file, only without executable flag, instead of silently ignoring it.