Jwz: I told you so, 2021 edition
web.archive.org
web.archive.org
Testing it again in Firefox took me to the landing page. Maybe it doesn't redirect every single time.
It is plainly obvious why Google's browser might not want to do something like that.
Orders of magnitude smaller than xscreensaver. You can easily read the code and understand what it does.
After all, most people stick to the defaults.
Also, the suckless community os one of the more toxic ones out there...
WONTFIX
https://github.com/dstat-real/dstat/issues/156
For anyone who (like me) hadn’t come across this before, it might be interesting to read.
Wrap it in something that's actually uncrasheable, and that will reload it unless XSS exits with code 0 or something
Or have a syscall to "freeze" the user (this is why Windows required Ctrl-Alt-Del to login - so that the login input was gatekept), but yeah, X11 is a mess
Sort of what https://github.com/google/xsecurelock recommends doing.
Also, xsecurelock doesn't run the input and PAM auth in the same process as the lock, making input bugs (https://news.ycombinator.com/item?id=21224179) harmless as well.
I don't know if this is the default or if I did something to enable it, though. It could be this only happens if you use the "switch user without logging out" function.
Coincidentially, Windows does something similar a lot. UAC prompts run on a different Desktop which is completely separate, the log in screen is separate, as well as the secure attention screen (what you get when you press Ctrl-Alt-Del).
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308572
If you go back to an older GNOME version you can probably also find the current Cinnamon bug in there, it is in libcaribou after all.
Cinnamon at least makes operating like a classic DE a first order priority and it works nice across multiple screens.
KDE does the same but aesthetically KDE drives me crazy for some reason starting with the complete lack of standardisation on padding and going down hill from there.
- There's no hibernate button. You can hibernate... by running "sudo pm-hinernate" on terminal.
- There's no session save, like, really.
- pm-hibernate sometimes fails without a single error message. Turns out it would refuse to run when the kernel was updated, OK fine that makes sense, except that the error message is redirected to /var/log/something and hidden beneath hundreds of lines of noise.
The only nice thing about it is that fractional scaling mostly works, which is nice, because I happen to have one 1080 and one 4K monitor. I'm sorely tempted to move to KDE but then I couldn't figure out how to make fractional scaling work there.
It's a total mess.
Note how starting from Plasma 5, KDE doesn't officially come with a screen saver installed anymore, and only has a screen locking mechanism (kscreenlocker, which isn't exempt from its own share of bugs BTW).
Alas, one just had a filesystem corruption bug caused by a slightly weird input and the other shits all over a different subsection of their userbase with every new major release between breaking their workflow and bugs like this one, where you can "hold enter to root".
This doesn't mean there aren't genuine annoyances, much like with any desktop OS, but it has already "arrived" and it can be used successfully for gaming, editing, browsing, printing, listening to music, watching movies, coding, etc.
That's troubling. How do people expect the GPL to be respected when distributions don't respect other people's licenses?
[1] https://web.archive.org/web/20210116154429/https://gitlab.gn...
The belief of being able to re-license BSD code is quite prevalent in the Linux community and is often espoused here on Hacker News.
Easy: they are different groups of people. The people who expect/want the GPL to be respected and the people who strip other people's licenses with reckless abandon are not the same people.
The same could happen with any license, there's nothing in the GPL which can make you more prone to disrespecting other author's software.
Which line of the BSD license allows you to remove the BSD license from the source file? Since the license specifically says "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."
so long as you retain the original copyright notice.
Which they did not retain.
> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Then, they also removed the copyright notice...
> I would gladly meet the liar for a cage fight, winner takes all.
swaylocker, the wayland screen locker I'm currently using has the exact same architectural flaw: crash the dialog and get access to the desktop.
https://github.com/swaywm/swaylock/issues/162 https://github.com/swaywm/swaylock/issues/158 https://github.com/swaywm/swaylock/issues/10
I’ve also seen this argument from the systemd crowd (spoiler alert: the logind ecosystem is also unreliable).
Supposedly Gnome is better but I have no idea.
EDIT: I also found this looking through github issues. It's not only a know issue, it's a WONTFIX:
>> This also brings up a good point. If sway detects that swaylock (or whatever locking process is used) didn't exit cleanly, it should try and recreate it, so we don't just end up giving the a malicious user access to the session.
> I don't think this is worth it
https://github.com/swaywm/sway/issues/2031#issuecomment-3920...
In that PR they changed the render loop rather than implement the "not worth it" suggested solution. At no point was it marked as WONTFIX.
> But if xscreensaver crashes, the screen is unlocked, and our attacker is now logged in as the person who locked their screen.
EDIT: To clarify I meant that jwz' blog post is the one which implies otherwise.
Xscreensaver attempts to mitigate this by being as simple as possible to prevent crashes. swaylock doesn't do this either, apparently. Several crashes have been reported in the past year alone.
I was just expressing disappointment in the lack of interest in fixing #1.
It seems that wayland architecture can solve this only when a compositor directly contains screen locking code. And it also means that every wayland compositor have to do this separately (btw is there any reusable library covering this functionality?) and that independent wayland screen lockers (such as swaylocker) have the same problem as X server implementations.
It took a few times of trying to figure out if I had forgotten to lock it to figure out how they did it.
They were bored and upset it was locked, and just kept typing characters into the dialog box for 5 minutes.
After they were gently scolded for breaking the spirit of the rules, I praised them for being clever hackers, and explained what exactly they had done.
Albeit, it'd probably be a Vec instead of a slice.
There has been discussion of actually locking the PC when the lock screen is enabled. When you use full disc encryption, it would evict the key from memory when the lock screen goes up. Then, with your password it will unlock the disc and the screen. For this, you'd need to move the login manager to the unencrypted partition and tie the user accounts to the hard disc encryption - I think Windows' BitLocker already does that. In the Linux world, you encrypt the disc before much of the OS loads (from a framebuffer or command line prompt).
And one day later, it appears the answer is apparently not: https://secret.club/2021/01/15/bitlocker-bypass.html