Jwz: I told you so, 2021 edition(web.archive.org)
web.archive.org
Jwz: I told you so, 2021 edition
https://web.archive.org/web/20210116101222/https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
11 comments
Archive org link because Jamie has strong feelings about being linked from HN (even down to blocking the folk on Twitter who do so).
Thanks, I was wondering what in the world was up with that.
This is what happens if you link to his website from HN. Arguably NSFW: https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
I Got the proper page?
I found when using Firefox, it did take me to the proper page. When using Google chrome, was redirected to the landing page I was referring to. Which browser did you use?
Testing it again in Firefox took me to the landing page. Maybe it doesn't redirect every single time.
Testing it again in Firefox took me to the landing page. Maybe it doesn't redirect every single time.
It works by detecting the HTTP Referer header. Under certain circumstances of privacy, Firefox strips the header. For example: https://blog.mozilla.org/security/2018/01/31/preventing-data...
It is plainly obvious why Google's browser might not want to do something like that.
It is plainly obvious why Google's browser might not want to do something like that.
https://tools.suckless.org/slock/
Orders of magnitude smaller than xscreensaver. You can easily read the code and understand what it does.
Orders of magnitude smaller than xscreensaver. You can easily read the code and understand what it does.
Sadly, this does not help people who just want to replace their Windows machines with Linux, or even more professional Linux users, who haven't even heard of this bug.
After all, most people stick to the defaults.
Also, the suckless community os one of the more toxic ones out there...
After all, most people stick to the defaults.
Also, the suckless community os one of the more toxic ones out there...
If you just want to use their software, the community doesn't matter at all.
The GNOME / IBM / Red Hat crew (all the same money pumping them) have often relicensed things when they see fit, without asking the original authors if it's OK. But I think we are all starting to understand the large difference between a company-driven and nominally "open" project, governed by a commercial entity, and a true community project.
WONTFIX
WONTFIX
This thread expands quite a bit more on the above topic:
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.
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.
So, the way I see it is: if XSS has to be uncrasheable, sandbox it.
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
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
> that will reload it unless XSS exits with code 0 or something
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.
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.
Another approach to splitting out the lock dialog would be to fire up another whole X server. That would be so bloated, the desktop environment developers might just go for it.
The bloat isn't in the X server, it's in the DE itself. You can start an X server and an xterm (without even a window manager) on pretty much an empty tank.
I think Ubuntu already runs a separate X or Wayland instance for the login screen. If you press Ctrl+Alt+F2 / F3, you can switch between the login screen and the current desktop.
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).
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).
Linux still not ready as a desktop operating system, news at eleven.
Well, more like the Cinnamon DE isn't. And, yeah, if you stray from the two superpower DEs with the most dev polish (KDE and GNOME), you're asking for jank and bugs.
Did you even read the article? "Hold enter, unlock Gnome-screensaver."
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.
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.
I switched from XFCE to Cinnamon after I couldn't get on with Gnome, Cinnamon is (for my use case) way less "janky" than Gnome since the only way to get close to what I consider a pleasant productive desktop on Gnome is to install a bunch of very buggy plugins.
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.
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.
Well, as someone who recently switched from Cinnamon to Gnome:
- 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.
- 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.
Since the author mentions Cinnamon and Gnome, I'd expect GTK land to be more susceptible (so I'd expect to perhaps run into similar issues with other GTK-based DE's).
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).
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).
Yup, you're right. One hopes that Windows and macOS become ready at one point given their enormous corporate backing, so at least we can have one desktop OS that is actually usable and semi-secure.
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".
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".
MacOS doesn’t have a secure desktop either.
There you go. The same old reasons are still applied and unsolved.
Still, I'd use even the crappiest linux desktop OS any day over MS Windblows and the rotten apples OS
Sigh. Not this again. Linux has been ready for the desktop, for me and many others, since more than a decade.
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.
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.
On another thread today, BitLocker Lockscreen Bypass:
https://news.ycombinator.com/item?id=25810250
https://news.ycombinator.com/item?id=25810250
XScreenSaver was released under the BSD license, one of the oldest and most permissive of the free software licenses. It turns out, the Gnome-screensaver authors copied large parts of XScreenSaver into their program, removed the BSD license and slapped a GPL license on my code instead -- and also removed my name. Rude.
That's troubling. How do people expect the GPL to be respected when distributions don't respect other people's licenses?
That's troubling. How do people expect the GPL to be respected when distributions don't respect other people's licenses?
The commit message [1] removing JWZ from the AUTHORS file isn't very informative.
[1] https://web.archive.org/web/20210116154429/https://gitlab.gn...
[1] https://web.archive.org/web/20210116154429/https://gitlab.gn...
That’s… not how derivative works and copyright work.
Replies from Linux Mint contributors to this point make for fairly interesting reading: https://github.com/linuxmint/cinnamon-screensaver/issues/354...
> I would gladly meet the liar for a cage fight, winner takes all.
> I would gladly meet the liar for a cage fight, winner takes all.
Lots of GPL advocates think they can re-license BSD as GPL because BSD is permissive. Of course, there is nothing in the BSD license allowing this, only the copyright holder can re-license.
This isn't relicensing it's removed of a person's copyright. That would not go well if it was done to them.
The code in question was re-licensed under GPL without the author's permission. And according to the BSD license, the copyright must remain intact. A person can use BSD licensed code in a larger work under GPL or they can put the modifications under GPL, but they have no authority to change the original BSD license.
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.
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.
The BSD license does not require that you redistribute it under the BSD license. You can decide to instead license your modified version under any license you feel like, so long as you retain the original copyright notice.
You cannot relicense if you don’t have the rights. A license does not change authorship rights or copyright, it just controls how other people can expand the work or distribute it. This particular license explicitly forbids others to remove the copyright notice or change the license:
> 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...
> 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...
[deleted]
The BSD license does not require that you redistribute it under the BSD license
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.
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.
[deleted]
> How do people expect the GPL to be respected when distributions don't respect other people's licenses?
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.
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.
Alternative for screen locking on Linux
https://github.com/google/xsecurelock
https://github.com/google/xsecurelock
No thanks. There is no reason to have apache, mplayer and mpv as a dependency for a screensaver “designed for security”.
I'm really starting to understand why jwz left software and bought a nightclub.
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
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
Heh. I’ve seen Wayland proponents cite the “impossibility” of screen locking in X11 as a reason to rewrite the entire thing from scratch.
I’ve also seen this argument from the systemd crowd (spoiler alert: the logind ecosystem is also unreliable).
I’ve also seen this argument from the systemd crowd (spoiler alert: the logind ecosystem is also unreliable).
> Heh. I’ve seen Wayland proponents cite the “impossibility” of screen locking in X11 as a reason to rewrite the entire thing from scratch.
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...
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...
Directly below the supposedly juicy "I don't think this is worth it" comment is a merged PR linked to this issue.
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.
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.
Yes, they fixed the bug, which is good, but if you read jwz’s post, the issue is that these bugs don’t fail safe. A screen locker shouldn’t crash to an unlocked session. The design of a screen locker should take into account that bugs and crashes will exist and strongly prioritize failing safely.
Actually, Xscreensaver doesn't fail safe either. If it crashes, the same issue will occur. I don't know why the post implies otherwise. Jwz says it himself in the linked article:
> 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.
> 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.
I just said swaylock, a wayland screenlocker, had the same architectural flaw as all X11 screenlockers: when it crashes the screen unlocks. Wayland was supposed to be better but it isn't, apparently.
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.
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.
His approach was basically to leave out complex features that could crash when possible and document why doing that was necessary. As far as he thinks a better solution is not possible with how Linux interacts with screen lockers. Modern implementations seem to do the inverse, include as much complexity as possible and fix every security critical exploit after the fact.
Based on such arguments, I got an impression that screen saver and locking functionality is handled in wayland protocol, but when I tried to look it up, I haven't found it.
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 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.
My kids(all under 11yo) figured out how to buffer overflow the lock screen on our linux family games machine.
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.
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.
My impression is that he would make more money doing nothing than running the night club.
If you're using a de, the bug is in you
I don't know, I would not expect any Linux lock screen to be secure secure. More like a padlock to keep honest people honest. If somebody is "good with computers" the'll probably be able to break it.
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).
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).
> I think Windows' BitLocker already does that.
And one day later, it appears the answer is apparently not: https://secret.club/2021/01/15/bitlocker-bypass.html
And one day later, it appears the answer is apparently not: https://secret.club/2021/01/15/bitlocker-bypass.html