https://bugs.kde.org/show_bug.cgi?id=514517

michaelk83 <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.kde.org/show_b
                   |                            |ug.cgi?id=514443,
                   |                            |https://bugs.kde.org/show_b
                   |                            |ug.cgi?id=514326
                 CC|                            |[email protected]

--- Comment #2 from michaelk83 <[email protected]> ---
I'm not really familiar with the details of DrKonqi, kded, kwin/x11/wayland, or
Qt internals, but to the best of my understanding:

- As I noted in the other issues, the failure in DrKonqi and kded is the same.
- Specifically, it happens in a core component of Qt (`QApplication`), because
(as you noted) a display is not available.
- For this particular Qt component, this is probably "as designed": it's not
intended to be used outside of a GUI context.
- When logged out (or at some stages of logging out/in), a display is not
available because it likely requires a fully initialized user session. Not
logged in => no session => therefore, no display. This should also be "as
designed".
- When the screen is simply locked, this isn't related to "a security issue in
connection with ksecretd", as ksecretd is not responsible for anything of that
sort. It's simply a daemon for storing app secrets, nothing more.
- But as I understood, this may be related to other security considerations of
the _display server_ (access to the display is restricted when locked), or just
simple practical considerations (how the lock screen is handled).
- Rewriting kded or DrKonqi to not use `QApplication`, or to use some other
component when outside of a GUI session, is likely a monumental task that's not
worth the developers' effort. So I expect this will be a "won't fix".

Note also that this is a) an edge case that shouldn't happen under most
circumstances. As in: you're not supposed to have things crashing outside of an
active session, and you're normally not supposed to start GUI processes when
the session is locked (or is still initializing or tearing down). And b) this
would behave the same for any such crash - it just happened to be ksecretd in
your case.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to