[Gpg4win-devel] on the allow-mark-trusted removal
marc.mutz at kdab.com
Thu Jan 27 13:07:34 CET 2011
I've been made aware of the removal/renaming of allow-mark-trusted into
no-allow-mark-trusted. I think we need a graceful-failure mode in this patch
before the release.
Let me first say that I understand the intention of the patch and I think the
change of the default from allow-mark-trusted=false to
allow-mark-trusted=true is a good one.
I am concerned about existing gpgconf clients, though. Since the
auto-generated gpgconf dialog in KMail and Kleopatra was too hard to use,
many of its settings have been moved out into a separate "S/MIME Validation"
page. This necessitated the use of well-known option names to address the
underlying gpgconf options, among them (for Kleopatra, at
least), 'allow-mark-trusted'. Since, among others, KDE versions for the past
seven years have depended on these names (if not necessarily
on 'allow-mark-trusted' itself), the option names in gpgconf are effectively
This patch would break this public API.
While easily fixed for future gpgconf clients, this breakage would cause
problems for _existing_ clients, among them Kontact for Windows, which uses
gpg4win for its crypto support.
While it's true that existing clients should check for the existence of
options before displaying a UI for changing them, it's a fact that at least
some existing clients don't do so (completely).
Let me therefore propose a graceful failure mode:
Keep the allow-mark-trusted option, but set it to no-change. Calculate its
value based on the value of no-allow-mark-trusted.
This will cause existing clients to display the correct value to the user,
while preventing her from making changes that wouldn't have any effect, or
would cause an error, if attempted.
To suppress the duplicated option in current and future gpgconf clients'
auto-generated GUIs, there are two ways:
1. Set its level to invisible or internal
2. Create and use a new 'deprecated' flag.
3. Both (1) and (2) together.
(1) has the better chance of working with existing clients, assuming that they
ignore the level when directly addressing well-known options, but take it
into account for auto-generated GUIs.
(2) is conceptually cleaner, but requires changes in gpgme, and all clients.
Options deprecated this way should probably be supported until an incompatible
version of gpgpg is released (if any).
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
More information about the Gpg4win-devel