Gpgtools GPG Keychain Access → 1.2b5

Comments and changes to this ticket

• 

  Support December 17th, 2014 @ 11:21 AM

  Assigned to Tender discussion #25.

• 

  steve December 23rd, 2014 @ 10:48 PM

  • Title changed from “move "Algorithm Preferences" rom right-click menu to top menu > Key” to “move "Algorithm Preferences" from right-click menu to top menu > Key”

• You flagged this item as spam.
  

  Helmut K. C. Tessarek December 29th, 2014 @ 08:18 PM

  I'd like to express my opinion on this topic as well.

  Although the item Algorithm Preferences seems to be an expert setting, it is still specific to a certain key. Thus it should remain in the context menu. Everything that is related to a specific key should be in the context menu, because that's what a context menu is for: to allow people to quickly access all functions pertaining to the item in context.

  There are of course several ways to handle basic/expert settings:

  • general preferences setting (depending on it the menu and context menu changes)
  • sub menus

  I don't think that it is necessary to hide expert settings though. At least not in this project. If you had hundreds of functions/actions that relate to an item, it would be a different story.

  If you really want to hide/mask expert settings, please create a sub menu (less work than a general preferences setting). In that case people can at least access it via the context menu.

  I'd rather be concerned about the naming of the menu items. They should be consistent. e.g.: Update from Keyserver vs Update from key server.

• You flagged this item as spam.
  

  Mento January 23rd, 2015 @ 02:14 PM

  • State changed from “new” to “invalid”
  • Assigned user set to “Mento”

  Algorithm Preferences was already an expert setting. I forgot to change this in the context menu.

  enable expert settings using: "defaults write org.gpgtools.gpgkeychain showExpertSettings -bool yes".

• 

  steve January 23rd, 2015 @ 04:32 PM

  • State changed from “invalid” to “verified”
  • Tag cleared.
  • Milestone set to “1.2b5”

  Setting this to verified.

  It was an issue because the item did exist. Now it's gone (as expected), thx mento!

  For expert users who want to play with this expert setting I've created a KB explaining how to activate this option: http://support.gpgtools.org/kb/gpg-keychain-faq/activate-gpg-keycha...

• 

  steve January 23rd, 2015 @ 05:12 PM

  • Title changed from “move "Algorithm Preferences" from right-click menu to top menu > Key” to “remove "Algorithm Preferences" from right-click menu and top menu > Key to hidden expert settings”

• You flagged this item as spam.
  

  Helmut K. C. Tessarek January 23rd, 2015 @ 06:44 PM

  Hi guys,

  Can we please have a discussion about this? Any chance you can revert this change?

  Please let me try to explain:

  In my previous comment I mentioned the possibility to move it to expert settings, but this was before I realized that you put it in the same category as removal of last self-signature and revocation of last self-signature. While these two are really expert settings (which I'd rather call debug or dangerous actions/settings), Algorithm Preferences is a basic functionality which you hide away. The use of Algorithm Preferences might not be as common as other actions, but important nontheless.

  Making it only available with 2 dangerous actions, which can really screw things up, is wrong. These 3 items do not belong in the same category.

  Please reconsider this change. Or at least let us discuss it.

• 

  Luke Le January 23rd, 2015 @ 06:47 PM

  I actually quite agree with Helmut here.
  The more sensitive thing would be to handle these settings separately, so each item receives its own defaults command or at least split between "dangerous" settings and less used settings.
  In GPGMail we're using the one setting per "expert" feature approach which worked quite well in the past.
  Should we switch to that, the knowledge base entry should highlight which features are more dangerous to use.

• You flagged this item as spam.
  

  Helmut K. C. Tessarek January 23rd, 2015 @ 07:00 PM

  Hiding those 2 items with a defaults option is totally valid, but Algorithm Preferences should not be hidden at all.

  I can assure you that people will be searching for this, if you remove it. Especially since the gpg defaults are rather weak. I know that there are global settings as well, but this is even more advanced and no standard user would want to meddle with that.

  There are no 100 actions possible so having this in the context menu and the menu is perfectly fine. People who don't know what it is, don't have to use it. It's not dangerous anyway and you can cancel the action.

  I'd go even further and add another context menu for ownertrust and add subitems with a checkmark. But that's a different story.

• 

  steve January 30th, 2015 @ 12:07 AM

  Follow up on splitting the hidden expert settings here: https://gpgtools.lighthouseapp.com/projects/65684-gpg-keychain-acce...

  The global defaults we use follow https://help.riseup.net/en/security/message-security/openpgp/best-p...

  I don't consider those weak. Can you double check, your gpg conf matches that when using the latest nightly suite?

  We'll remove it for now. I'll personally take care of users asking where the heck this setting went :)

• You flagged this item as spam.
  

  Helmut K. C. Tessarek January 30th, 2015 @ 12:16 AM

  Hi Steve,

  I'm not talking about the defaults you are using, but gpg itself. Anyhow, this is not really the issue.

  Algorithm Preferences does not fall into the category dangerous settings, but rather an advanced (if even so) setting. This was actually my main concern. You removed standard functionality from the GUI. Why do you think people want to use a GUI? So that they don't have to remember a million options and parameters on the command line.

  You still have to differentiate between dangerous operations, advanced, and expert settings. You don't. You put them all in the same category.

• 

  steve June 18th, 2015 @ 01:35 PM

  • State changed from “verified” to “released”

  [bulk edit]