GNOME Bugzilla – Bug 304569
Authorize Password Access preference not remembered
Last modified: 2020-06-06 08:52:11 UTC
Version details: 0.9.0 Distribution/Version: Ubuntu Hoary Start the seahorse-agent and sign a key. The Authorize Password Access dialog will appear. Uncheck 'Always ask me before using a cached passphrase' and click the Authorize button. Now, try singing another key. The Authorize Password Access dialog appears again, with the 'Always ask me before using cached passphrase' checked again.
Odd, this works for me. But it could be that the agent changes I recently committed to the stable branch fix this.
On my new laptop, I experienced this as well. I installed from cvs-HEAD. The gconf key cache_authorize is being reset to TRUE when a request is being made. It is being set to FALSE correctly when the check box is unchecked. A cursory search failed to turn up the culprit in the code.
Killing and restarting seahorse-daemon seemed to fix the problem. I'm not sure how relevant it is, but I restarted seahorse-daemon to enable key sharing after enabling it in preferences.
It seems like seahorse-daemon ignores changes to the preferences after its start. Changing the preference to always ask after the daemon has been started has no affect, the daemon continues providing passphrases without asking. However, in this case the preference isn't set to FALSE every time the daemon is queried.
This bug appears to extend to seahorse-daemon and key sharing in HEAD as well.
This appears to be fixed for me with HEAD, gconf-2.12, and GNOME 2.12. Can anyone confirm this? This leads me to believe it was a gconf bug that has since been fixed.
I may have spoke too soon. It appears fixed when running seahorse-daemon --no-daemonize from the commandline, but appears broken when running as a daemon. There appears to be a similar problem with photo ids not working when seahorse is not run from the command line.
"me too" -- ubuntu breezy here, problem detected when running gajim.
Comment #4 is correct. If the "ask permission" setting is true, it stays true for the rest of the session. If, however, the setting is changed to false before the session starts, it stays false through that session. This could be a weird bug in the notification loop caused by seahorse_check_button_control_toggled changing a gconf setting, causing seahorse_check_button_control_gconf_notify, causing a new gtk_toggle_button_set_active call. GConf is usually smart and breaks these loops, but...
The fix for all of our weirdness related to being run from the command line or not appears to be a regression in gpg in 1.4.2. https://launchpad.net/products/gnupg/+bug/5570 Ryan Lortie (desrt) submitted a patch to the gpg devels which appear to have been mangled by gpg-devel's list software. I'll attach below. I will test and report back.
Created attachment 55852 [details] [review] Patch against weirdness - see above
I'm not quite sure if it's fixed this problem with the agent/daemon, but it has fixed a problem with the photo IDs not working correctly unless seahorse was executed from a terminal.
By commenting out the closeing and opening of the std file descriptors in seahorse-daemon.c I was able to insert some debug statements into the code to see some of what's going on. So far, the seahorse_notify_add is adding the notification, but a negative id is returned. A positive id is properly returned when seahorse-daemon is run with --no-daemonize. More to follow concerning the SETTING_AUTH failing to refresh between the two cases.
This is a complete and utter copout, but adding the --no-daemonize switch to seahorse-daemon in my startup programs seems to do the trick without any apparent side effects. Of course, this behavior with the switch was known before, but I hadn't tested it with the session manager.
Adam, can you still duplicate this problem?
With ssh-agent dbus-launch --exit-with-session seahorse-daemon --execute gnome-session in my .xinitrc file, it appears that the GConf keys are propagating properly.
*** Bug 496393 has been marked as a duplicate of this bug. ***
seahorse-plugins is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/257 It had its last code changes many years ago: https://gitlab.gnome.org/GNOME/seahorse-plugins/-/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.