[Gpg4win-devel] on the allow-mark-trusted removal

[Marc Mutz]

Hi all,

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 
_public API_.

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).

Thanks,
Marc

-- 
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