I'm surprised nobody had "ē" in their password to notice this earlier.
Kids find a security flaw in Linux Mint by mashing keys
51–60 of 340 posts
Re: Kids find a security flaw in Linux Mint by mashing keys
#52Earlier quoted context omitted.
Can anyone explain why a crash in xscreensaver results in the computer being unlocked? It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
KDE has a failsafe mechanism. If the screen locker has crashed, it shows a black screen of death with a huge error message. > The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session. I think it's a reasonable design.
No, it's not failsafe. I know a person where only one screen of two got locked, the second one remained operational.
Re: Kids find a security flaw in Linux Mint by mashing keys
#53In middle school long ago, I was using one of the library search computers. They ran Windows XP and were locked down to the point where you couldn't open anything except the software that was running and you had no access to the desktop. One day I was rapidly mashing the "Search" button in the native book-searching software they were using - for no reason at all - and it suddenly opened an Explorer window out of nowh…
Classic thing was to write file:///C:\ (or something similar, I do not remember it anymore) on computers with only kiosk mode IE on them to access the local file system. :)
Re: Kids find a security flaw in Linux Mint by mashing keys
#54Earlier quoted context omitted.
KDE has a failsafe mechanism. If the screen locker has crashed, it shows a black screen of death with a huge error message. > The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session. I think it's a reasonable design.
No, it's not failsafe. I know a person where only one screen of two got locked, the second one remained operational.
Okay, let's call it an "incomplete failsafe". I don't want to discuss the correct terminology, but the idea itself.
Re: Kids find a security flaw in Linux Mint by mashing keys
#55Earlier quoted context omitted.
Because X11 is such a joke. The problem is solved by wlroots and layer-shell, other Wayland compositors probably have similar things. Swaylock works 100%ly reliable until now (For me). I had problems with every other X11 screenlocker I used in the past. My unusual setup with a docking station and two monitors on it often caused crazy bugs. Edit: For me stuff
It seems like most of the complaints I see about distros have actually been solved problems for years but held back by poor distro defaults. I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
Other commenters link to similar issues with Wayland screen lockers. So I am not sure how the current shiny fixes things.
> python 2
In contrast to Wayland that can be installed in parallel to python 3. So the only reason to remove it is if you enjoy breaking working software.
Re: Kids find a security flaw in Linux Mint by mashing keys
#56Earlier quoted context omitted.
I clicked the link specifically seeking out this testicle in an egg cup, however, all I got was an article on XScreenSaver. How do I get the testicle in an egg cup?
Make sure your browser sends in the Referer header. Otherwise, this is the image that gets displayed: NSFW. This is a testicle in an egg cup. https://cdn.jwz.org/images/2016/hn.png
Thank you! I'm using plain Safari with no extensions.
An interesting website and blog, I like it! I wonder what their problem with HN is, although I don't mind being a testicle!
Re: Kids find a security flaw in Linux Mint by mashing keys
#57Earlier quoted context omitted.
It seems like most of the complaints I see about distros have actually been solved problems for years but held back by poor distro defaults. I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
But then you are breaking enterprise stuff !!!1!11!
My favourite moment was when fedora turned on CGroups v2 after every distro waited years for docker to update to it. Docker was broken on fedora until you manually turned v1 back on but then docker suddenly upgraded to support v2.
Re: Kids find a security flaw in Linux Mint by mashing keys
#58Does anyone know why lockscreens in Linux have been such a joke? I remember trying Ubuntu couple years ago and when waking up my laptop it would show me my entire desktop with all the information displayed right there in the open for about 10-20 seconds before suddenly engaging the lockscreen. All you had to do was close the lid and open it again and you could just copy whatever was on the screen before the lock scre…
Bad design in X11 which can't be fixed. https://news.ycombinator.com/item?id=25801693
The underlying design issues are:
a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.
b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.
Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).
An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.
Re: Kids find a security flaw in Linux Mint by mashing keys
#59Earlier quoted context omitted.
It seems like most of the complaints I see about distros have actually been solved problems for years but held back by poor distro defaults. I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
Other commenters link to similar issues with Wayland screen lockers. So I am not sure how the current shiny fixes things. > python 2 In contrast to Wayland that can be installed in parallel to python 3. So the only reason to remove it is if you enjoy breaking working software.
Its not that they still had python 2, its that the binary "python" referred to python 2 on ubuntu (it might even still be like this) while other distros had it pointed to python 3.
Re: Kids find a security flaw in Linux Mint by mashing keys
#60Earlier quoted context omitted.
KDE has a failsafe mechanism. If the screen locker has crashed, it shows a black screen of death with a huge error message. > The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session. I think it's a reasonable design.
No, it's not failsafe. I know a person where only one screen of two got locked, the second one remained operational.
That might be a kde limitation in general. The amount of "fun" I had dealing with two screens on kde is outright endless. Not sure they even test that kind of configuration, 640x480 pixels should be enough for everyone.