Bug 2382208

libinput 1.28.901 and 1.28.902 *potentially* log key presses as part of a mistakenly enabled debug message. While this definitely happens the number of affected users is likely quite small. Whether the logs show up anywhere instead of being just discarded depends on the compositor settings.

A check of the git repositories of the more common compositors shows:
- kwin: possibly affected.
  kwin always calls libinput_log_set_priority() but passes the log messages
  to qCDebug(KWIN_LIBINPUT). Unless you have enabled the "kwin_libinput" log
  category the messages should have been discarded.
- mutter: not affected
  mutter does not call libinput_log_set_priority() and thus defaults to INFO,
  debug logging is thus not enabled
- wlroots: not affected
  wlroots calls libinput_log_set_priority(ERROR), debug logging is thus not
  enabled
- Xorg via xf86-input-libinput: possibly affected
  The xf86-input-libinput always enables debug logging and passes the messages with
  verbosity X_DEBUG to the server. This is filtered by the server unless
  --verbose 10 or --logverbose 10 or higher was given by the user (the default
  for both is 3).

If you use a compositor other than the above, check if libinput_log_set_priority() is called with LIBINPUT_LOG_PRIORITY_DEBUG and if so whether those logs are stored to disk.

If you have recently used `libinput debug-events --verbose` on a keyboard device and posted those online, double-check those recordings. libinput record output is not affected. The libinput debug-events output without --verbose is not affected.

Reproducible: Always

Steps to Reproduce:
Easily visible when running libinput debug-events --verbose and checking the output of the events. This itself is not a leak (unless the output is uploaded somewhere public) but the same sequence goes to the compositor and may end up in the system logs, depending on the compositor settings.



Additional Information:
Due to a mixup of #if and #ifdef the meson "internal-event-debugging" option was
always interpreted as true and all evdev events were printed as part of the
debug-priority log output. Since those include the keyboard key codes, this may
result in sensitive data such as passwords ending up in the logs.