[Gpg4win-devel] Idea for making logging easier

[Andre Heinecke]

Hi Christoph

On Thursday 30 June 2022 07:54:46 CEST Christoph Klassen wrote:
> log files can be very important for developers to find errors. But when 
> I think of average people using Gpg4win I think it is too complicated 
> for them to enable logging. That's why I reflected about this topic.
> 
> My idea is a log manager which could be opened from Kleopatra. It could 
> look like in attachment [1] (log_manager.png). There you could enable 
> the logging for a component of Gpg4win. Maybe there could be other 
> buttons to, for example, go to the directory where the log files are 
> saved (which would be only one folder for all log files for the sake of 
> simplicity).
> 
> When users press a button to enable the logging a new window appears 
> where they can set how long the component should log events. Also, they 
> can set options that are specific to this component like debug flags for 
> the dirmngr.
> 
> The advantage of this would be that:
> *there is only one place where users can handle log "things"
> *users won't be scared because of a terminal because they don't need it 
> (the manager could restart components like dirmngr automatically)
> *I guess that users would not disable logging after they solved a 
> problem. This is a security risk (because of sensitive information) and 
> consumes space on the hard drive. When they set how long the logging 
> should take place this won't be happening.
> *when the GUI shows options users don't have to use the documentation to 
> find out which options are available (maybe only to see what each 
> options does but tooltips could even handle that)
> 
> One question that I had was: What about the advanced users who want to 
> change anything individually like the directory where to save the log 
> files? --> I think that should not be a problem. If users use the log 
> manager this manager will overwrite settings so that all log files will 
> be saved in one directory (which is also the one that will be opened 
> when users click on "Open log directory"). When advanced users change 
> the log directory in a config that directory will be used. Since 
> advanced users probably won't use the log manager this settings wouldn't 
> be overwritten.
> 
> What do you think of this idea?

Currently you can under Kleopatra under Settings -> Configure Kleopatra -> 
GnuPG System enable logging for each component.

Usually support tells the users which log file they should enable and in my 
experience this works nicely even with non technical users. I usually suggest 
users to set the log level to all. And disable it again after they have done 
the action we wish to debug.

A timed disable is difficult because you would need a monitoring process that 
runs for the specified time and disables logging afterwards. I don't think that 
this is really neccessary.

But I could imagine a tab in the configure kleopatra widget which is dedicated 
to debugging. Like we have in the Outlook config widget. This could go above 
and beyond the current logging in that it could install a Qt logging handler 
(see gpg4win-tools as an example) to log Kleopatras debug output and 
additionally enable GPGME_DEBUG environment variable and a synchronized 
logging for the components using the log socket mechanism. So you would 
configure the GnuPG components to use a log socket to send their output back to 
a listener in Kleopatra which would write it into the specified log file. This 
way you can directly track interactions eg. between dirmngr and gpgsm.

The idea would be just a selection for a log file with a default path set. And 
then to add checkboxes for the components that should be logged. While this is 
a nice little project it is not trivial to syncronize it all that it is 
written into the log file syncronized and not randomly. But it should be easy 
to get started with this, e.g. at first only enable Kleopatra and maybe GPGME 
logging (which is currently very complicated and for Kleopatra requires the 
Dbgview tool). And afterwards add the GnuPG components, too.


Best Regards,
Andre



-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20220701/4df8f730/attachment.sig>