Tag Archives: session

KDE Plasma users – reconfigure your desktop from scratch when you experience startup delays after system upgrades

Posted on by

This post is basically for KDE Plasma users on Linux systems which are not based on rolling releases, but which get upgraded in the course of defined upgrade cycles of the distribution. It is a kind of reminder about a rather trivial point when you upgrade your Linux system or when someone else has done this for you:

  • It may sometimes be worth the effort to rebuild and reconfigure your KDE Plasma desktop after your Linux OS has been upgraded.

A full upgrade of a modern Linux system comprises the upgrade of very different components. In most cases a change to a newer version of your preferred desktop environment is part of the packet upgrades. Regarding the evolution of KDE/Plasma during the last 20 years, I have several times experienced that the desktop may exhibit problems after such an upgrade. In a few cases the desktop itself and its configuration would struggle with problems, sometimes a certain application or plasmoid had deficits. Such deficits have most often affected the performance or presentation of only the application on the desktop, but sometimes the overall desktop performance was hampered.

Startup times for standard Linux systems are pretty fast these days – including the start of a graphical desktop session. Even on a 12 years old laptop a KDE Plasma desktop based on X11 builds up within 3 secs after passing login credentials – even with reconstructing the status of multiple applications you left open at the end of your last KDE session. Part of the time may go into (Wifi) network access – and the establishment of complex firewall rules during network startup by networkmanager – dependent on your configuration. But under normal circumstances, establishing network connections by networkmanager should not be an obstacle for a fast general start of the graphical desktop.

Therefore, it should make you nervous when you find that starting a KDE Plasma session on a laptop takes around 10 to 20 secs. This was an experience I yesterday had on a system which had been upgraded to Opensuse Leap 15.6 some months ago. The user was frustrated about a long delay during KDE startup – which he could prove by excerpts of logged system messages. Unfortunately, neither the system logs nor the X11 logs indicated clearly what the reason was. In my opinion, this was an indication of some problematic configuration. Even if the KDE desktop appeared to work without problems after its long startup phase. Some app or plasmoid could have waited during the start of the desktop session for a rather long period for a timeout.

I could help my acquaintance. The question who has caused the glitch, the user or the OS provider, most often is relatively unproductive and fruitless. As long as there is no indication of a hacker’s manipulation … Leaving the possibility of a hacker’s interference aside, we first of all want to reconstruct a working graphical environment. If we find the culprit for the problems on our way – the better it is. Nevertheless, for important system exposed for whatever reason to unfriendly attackers, I would recommend to make forensic copies of the system first. Never ever think, Linux is a kind of barrier for experienced hackers …

This post, therefore, is about a possible solution under best circumstances – namely about a systematic reconstruction of your KDE desktop, its layout, plasmoids and applications to avoid configuration “errors” you may have carried around with you since the last or even since some older upgrade.

Continue reading →

After the Bundeswehr Leak and the explanation of the Minister of Defense – some more questions …

Posted on by

Today I heard the explanation of the German Minister of Defense regarding the probable cause of the leak of last Friday. What I understood was:

  • WebEx is hosted in a special variant (WebEx BWI) on servers of the Bundeswehr.
  • Clear rules are in place, but were not followed. One participant attended the WebEx session via telephone.
  • Systems were not compromised.

Are these explanations sufficient? Do they cover all concerns described in my previous post
“Some simple questions after the Bundeswehr Leak …”
on this topic?

In my opinion some questions remained open:

  • Why and by whom was the WebEx session set up such that a participant could access it via telephone at all? With a zero-trust and MLS-based session this should have been excluded …
  • Did the participants get an invitation with an option that offered an access to the session via telephone? If yes: Who sent this information via which channels? Is it excluded that already the invitation was accessible to foreign powers?
  • Why did nobody check by which devices and communication channels the participants were attending the session? At the beginning and during the session? Why did a log- and intrusion system not react?
  • Why did none of the other participants react to the fact that the poor guy in Singapore talked over telephone? Despite the clear rules in place …
  • How did the eavesdropping happen? Were the telephone lines of the hotel tapped? Or did the participant use a wireless headset with Bluetooth?

So, if it was a human failure it may have happened due to mistakes and unawareness on multiple sides – on the side of IT-administrators responsible for the session setup, on the side of the person which sent the respective invitation, on the side of the participant who did not use a BWI- or SINA-device to access the session.

Well, and I would say that when a session running through servers of the Bundeswehr was overheard by Russia, at least the session was compromised. And if someone can access an audio-session, which is enabled by and via a Bundeswehr server and which is intended to be secure, via an open telephone line then something is severely wrong in the overall security measures.

So, my dear Minister, as a concerned citizen I still do not sleep well. More explanations have to follow …