The original definition of "hacking" was "hacking code together". Move fast and break things. There are a lot of us OG and TNG hackers here. It's kind of the SV spirit.
"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.
Hacking (in the modern 'computer' sense) has been used since at least the late 50s and early 60s and used to mean experimenting with any technical machine or system. It wasn't until the 70s when it primarily became connected with programming.
> original definition of "hacking" was "hacking code together"
Hmm. Right spirit but not so much "hacking code together" going on at MIT's Tech Model Railroad Club in 1958.
"a project undertaken or a product built not solely to fulfill some constructive goal but with some wild pleasure taken in mere involvement, was called a `hack'".
The Tech Model Railroad Club (TMRC) Dictionary [1], June 1959, by Peter R. Samson defines (comments in italics by PRS, 2005):
HACK: 1) something done without constructive end;
2) a project undertaken on bad self-advice;
3) an entropy booster;
4) to produce, or attempt to produce, a hack.
I saw this as a term for an unconventional or unorthodox application of technology, typically deprecated for engineering reasons. There was no specific suggestion of malicious intent (or of benevolence, either). Indeed, the era of this dictionary saw some "good hacks:" using a room-sized computer to play music, for instance; or, some would say, writing the dictionary itself.
HACKER: one who hacks, or makes them.
A hacker avoids the standard solution. The hack is the basic concept; the hacker is defined in terms of it.
A well known reference, Eric Raymond's "jargon file" a.k.a. "hacker's dictionary" offers 9 definitions, much broader and seemingly older than keypress timings: http://catb.org/~esr/jargon/html/H/hack.html
People have been fuzzing user interfaces since the 80s. It was used for developing MacPaint and MacWrite in Apple's original Macintosh. Quote Wikipedia:
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
Thanks for sharing that story. It's probably the reason why Netflix decided to use "monkey" for the name of their tool to randomly terminate service instances: https://netflix.github.io/chaosmonkey/
As others have pointed out, you are describing fuzzing but rather than purely random you’ve trained your fuzzer on a particularly troublesome set of random variables ;-)
This reminds me of when I was about 14. I had a Tamagotchi which I had for a record amount of time. My niece, about 2 at the time wanted to see it so let her hold it. Within 1/2 a second, she squeezed both buttons at the same time and crashed it.
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
We had some race conditions that started appearing more often over time. Those race conditions could be triggered by rapidly firing events on a busy backend.
After long research, we found correlation with marketing moving their target from only students to 'older people'. Apparently the latter 'doubleclick' on links and buttons in webforms far more often. At least for us they did.
Does 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 screen appeared. I guess it's because the lockscreen was a separate process that had to start up? Still, what an awful awful design.
I’m not familiar with the details of the design flaw and whether or not Wayland fixes it, but those links don’t contradict this being an X-specific design flaw. I get the impression that swaylock is a direct port of i3lock, and thus stands a fair chance of being written and architected in an X style, rather than taking advantage of any superior form that Wayland may support but X didn’t.
Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)
(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)
If you've ever looked in the bugtracker of a big X11 screenlocker, you would love to have this small amount of bugs. In fact, some of the bugs you posted are alread solved and I can't find one bug related to displaying. Giving the display to the user could also lie in other code parts. We'll see how this ends, but it's already a huge gain that not every Everyday Linux user has experienced such things by themselves.
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.
Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?
Because, IIRC, xscreensaver is launched on demand (idle timer, power management), and that's a terrible time to detect the extension and tell a user that they won't be able to resume their session, because their Xserver is too old.
Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily have its server component updated, but you run remote sessions that have an updated Xscreensaver. (Btw, if you do this, you're pretty dedicated in 2021)
> 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).
This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.
Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.
I like the dedicated VT, as DE users usually have a DM to login and for wayland that prob must a separate VT any way. The question is how to securely do this.
You still get the testicles if you click this link, at least using Chrome you do. It's because the referrer field is set to HN so they know where the traffic is coming from.
I'm using Chrome with uMatrix and uBlock Origin... I assume one of those blocks the data because, somehow strangely, I feel left out that all I'm getting is the websites.
I wonder why someone would setup a "bad result" for specific referrers ...
Savers can crash without the screen unlocking. Are you sure it was xscreensaver you were running, and not one of the innumerable incompetent knockoffs?
Sounds like you were probably using gnome-screensaver or some of the many other poorly written alternatives like cinnamon that do this. I don't believe there is any way for xscreensaver to unlock the desktop even if it does crash
Incorrect. It’s a limitation of X11 that if the screensaver daemon crashes, including xscreensaver, the desktop will be unlocked. See the JWZ links that are posted in this thread.
In fact jwz himself says in that very post that it is a fundamental problem with X11:
> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.
He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:
> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.
I do not understand. There's an xl and its PAM-checking derivative xl-more that just work.
They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.
It's not an X11 design flaw. The very concept of locking the screen is flawed. A flaw that also haunts Wayland, BTW.
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
that's a really good point! your comment reminded me that that is what we used to do in the lab at university, a long time ago. switching to a different terminal, then locking that, was much more fool proof. perhaps not for security, but rather because X11 was so damned buggy and crashy, that you might need to have access to that terminal to get back into your workstation without forcing a reboot.
Perhaps outside of display servers altogether, implementing an authentication system that keeps track of what user currently owns what v.t., and allowing only that user, or root, to switch to that v.t..
The architecture you're describing would also be good for other reasons. For example, you could start a local session, lock it, and then remotely connect to the same session over VNC without local users at the workstation being able to see or interfere with what you are doing, just as on Windows.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
Windows has a secure desktop that host lock screen. Crash that gives you a bsod or at worst a blank screen (your window did not host on it, whta did you expect?)
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.
I'll edit it to (for me). With working on an X11 desktop everyday, it felt like everyone has at least once experienced such an issue.
To be fair to swaylock, they actually fixed some of those issues, in contrast to kscreenlocker which are just ignoring most edge-case bugs, because it's nearly impossible to fix them.
It's still a fundamentally flawed design, because the system fails open when the locker crashes. So it seems Sway / Wayland actually didn't learn anything in this area, and suffers from exactly the same problem as X11 when it comes to the lockscreen.
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.
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.
Given that python versions are incompatible by design you should probably explicitly refer to the version your code supports. At least that is my takeaway from this mess.
This whole situation is a bad trap for novices, given how many tutorials, class slides, etc ask students to copy/paste various invocations of pip and python that may or may not work verbatim on their distro.
The difference is that with Wayland there are no design issues that prevent you from implementing it reliably and securely; if it's broken it's an implementation problem that can be fixed.
There had been recent bugs on windows 10 where you could navigate your way to a desktop session through the input assistance dialogs (mashing the shift button). They fixed it by removing one of the links in the UI. In older Windows I think it was a mix of help and printer dialogs.
Really? I have never seen this in Windows. Don't get me wrong, I've seen plenty of lock screen failures in Windows, usually in the form of it suddenly being unresponsive, just never anything that actually gave me access to the locked session again.
The closest I've seen is when using RDP, if the Window has been minimized or hidden or otherwise has had reason not to update its display, then locked due to timeout, it will briefly show the last image it rendered when reactivated before updating and showing the lock screen.
P.S.: As other users have pointed out, Windows does have some known lock screen bypasses using accessibility and help dialogs, but in regards to merely crashing the lock screen, I haven't seen it behave in an insecure way.
Yes, really. I don't use Windows myself, but I've seen it happen to others. As another commenter said, it's usually when the computer is coming out of "sleep" or something like that. Plenty of times I've seen a glimpse of the desktop that was long enough for me to get a vague idea of what they were doing before the lock screen takes over. If one was determined enough a photograph could easily be taken in that time.
My guess would be that the video buffer wasn’t cleared before suspending. If so, on resuming there is a race condition between painting the lock screen, and turning on the video hardware that will show the screen memory as it was when suspended.
I've experienced an issue where the window blacking out the screen would get moved aside, it was something to do with plugging and unplugging monitors and somehow the screen contents would become visible. I probably couldn't reproduce it if I tried.
I wasn't too concerned about it since it still blocked all user input, but if you had sensitive info visible it could definitely be an issue.
Judging by the redirect to the image macro of a testicle in an egg cup, specifically calling out HN, I think we can assume the author of that article does not appreciate links to his website from HN
So what. This is how the web works. If you don't want people linking to you, don't have a website. He puts this blog out there for people to read, is it so weird that tech sites like HN would want to link to it?
And really if you're being DDoSed by a small thing like HN comment links you really have to up your game :) Wait till you get featured on reddit (previously called slashdotting when slashdot was still a big thing).
He doesn't think he's getting DDoSed from here. He doesn't respect anyone who comes from here.
Nor should he, not least because the redirect reliably results in ~90% of comments in any thread where jwz is mentioned being about the testicle in the eggcup rather than anything substantial.
But he refers to DDoS specifically in his eggcup image :)
PS: I have no idea what he means by "finance-obsessed"? I think the community at HN is tech-obsessed which is what I like about it. But finance? This is not yahoo finance or wherever all the finance guys hang out.
It sounds more like he had a clash with someone specific on a finance-related issue and bases his view of the HN community on that. The eggcup is a bit of an immature way to deal with this IMO. Especially as he has good points to make about X11 security, and this undermines them.
I don't know what prompted the redirect; it predates my awareness of Hacker News. I could guess, but why bother? The man has a nightclub to run, and I'm sure that's plenty all by itself to fill his days.
"Finance obsessed" is a pretty accurate description of what's going on here. A huge number of people on this site have trouble understanding that there's a world outside of the Bay Area where rent isn't $3000+ a month, and that its possible run a company without involving venture capital and ballooning to multi-million dollar revenues in less than five years. Even the tech discussion here revolves around this stuff -- almost every thread has some mention of "scaling" even if what's being discussed is a niche product that will have a customer base of a few thousand people over its entire life.
I like this site a lot, but I have a lot of patience when it comes to deciphering what is being affected by the Software Hub City Reality Distortion Bubble. Some people don't, hence the eggcup testicle, and people that think something like that undermines the technical argument aren't thinking clearly enough to even debate the technical point with anyway.
For x lockscreens this is solved by making sure the lock launches _before_ the system is suspended, I'm not sure how many distros do it like that though.
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.
> and re-launch it if it crashes without first signalling that the desktop has been unlocked.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
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.
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.
Now imagine they're powered by a docking station, you go into suspend, put the laptop out of the docking station, wake it up and - tadaa! This bug dissappeared but still occurs slightly diffrent for other people. Three monitors itself aren't more edgecase than 2. How long are you using this setup?
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
I don't believe the X system had/has a separate protocol for screen locking, or if it does, that any of the programs implement it. So xscreensaver is just another X client that happens to draw itself full-screen on top of all other apps and grab all user input.
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
jwz wrote a document explaining why this is hard. (Note that this link may result in an unsavoury redirect if you click on it from here. You can, e.g. copy and paste it to avoid this.)
I believe that's how JWZ's XScreenSaver works, but every distro decided to re-invent the wheel there for whatever reason, then blame it all on X11 when it inevitably fails.
You can use MS teams in Chromium or Firefox. The secret is that Browsers disable 3rd Party cookies per default for a year now or so and Microsoft has not reacted to it yet.
Screen sharing of X11 windows from a Firefox running on Wayland works fine for me under Sway. Sharing of other Wayland windows, or the whole screen, however, does not.
It happens to me on Windows 10 if I close the laptop lid to lock the desktop and send it to sleep.
When I open it again, the desktop is accessible for a few seconds (sometimes long enough to launch programs) before the lock screen activates and I have to input my password. The workaround I use is to manually lock with Win+L before closing the lid.
Windows have multiple desktop sessions(the normal user session, and the safe desktop). Even if you ever able to crash the one that host lock screen without bsod. You still won't be able to go back to the normal desktop.
Yup. On my 10.15.7 this happens frequently. Often if I open up the laptop I can see the current contents of the screen for a good 5-8 seconds before the lock screen shows.
I don't think I could interact with the screen in any way, but I could certainly take a picture of it, if I had any private information on the screen.
I don't dispute the bad design, but FYI, there was also a very recent exploit for accessing bitlocker drives on Windows without login credentials, making use of accessibility features on the lockscreen.
In the past I also had some information leaks with an Nvidia discrete graphics card, which seemed to not clear its RAM or something. I think it even persisted over restarts or similar complete session terminations. So I assume, driver issues may play into this too.
In 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 nowhere showing everything in the filesystem. I could reproduce it easily with rapid-enough clicks. I still have no idea why that happened.
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. :)
In the early web days, I had a public facing web site with a link that said "I can see what's on your computer", and the href was essentially what you posted.
The number of emails I got from that was worth the vitriol contained in them, including threatened lawsuits.
This reminds me of the classic XP login screen bypass by opening the help dialog, then the print dialog, then searching for a file to open for printing, and then executing 'explorer.exe' (I might be misremembering, this is quite a while ago).
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
Oh man this brings back so much nostalgia for the old school computer exploits we used to find.
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
It uses a compiler pass to insert code to branch points functions calls etc.
I think it uses genetic algorithms to increase coverage by changing the data.
Somewhat similar for web UIs: Quickstrom is a tool that lets you define a set of conditions that should hold (e.g. "there should always be an 'Add todo' button"), and then it'll simulate behaviour that might break that condition.
I have used AFL a few times casually in some personal projects, and it has always performed quite well for me. Of course, there are a lot of weird cornercases which would not occur on real-world (non-adversarial) inputs, but it also found some very real bugs.
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
Something about this exchange was extremely pleasing and calming to read, maybe I'm irony poisoned from overly loud social media. But this was so nice to read through.
A pleasant bugreport with no judgement or demands.
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
Keep in mind that screensavers aren't the only untested dumpster fire on Linux Desktops (or ~ distributions in general).
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
Mi kid got around the lock screen of my mac. Twice.
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
My kid (3 years old then) found an issue in the MacOS lock screen as well. It didn't result in a bypass, but a "Spinning Beach Ball of Death". I could then reproduce it and even filed an issue, but only I could reproduce (and one funny response was: "Why would you want a screen shot of the screen sleeping? It would just be black." - well tell that to my kid): https://discussions.apple.com/thread/7598463
With the current version of MacOS I have (not the latest), one could still cause some havoc... E.g. filling the disk by recording a movie with sound. Command+Shift+5. When mashing the keys, sometimes after login a list of message shows up ("Can not save the screenshot at this location").
Here's the last reply before the thread was locked:
> I don't see the point of pressing the wrong series of key combinations nine or more times in a row constitutes a "Login Window ScreenShot Problem" any more than dropping my MacBook from various heights until it breaks is a reliability problem.
Why do people hold computers to such a lower standard than other complex devices in their life? (Serious question -- I don't understand people very well here.)
Can you imagine a car that wouldn't unlock or start if a passerby without the key plays with the door handles too much? If this has happened and is documented, that alone is a testament to its rarity and people's unwillingness to excuse the behavior.
Unless it happened to early Tesla, because they were held to the lower standard applied to computers and OSs. That doesn't seem to be as true anymore, thankfully.
>Unless it happened to early Tesla, because they were held to the lower standard applied to computers and OSs. That doesn't seem to be as true anymore, thankfully.
I've definitely had my Model 3 not unlock when it should, but I've never had it go the other way around.
I was wondering as well. I _think_ he is just a user; an Apple fan ("community"). To some extend Apple employees probably moderate this forum (same as here, or at Stackoverflow.com), but most comments are from the community. I didn't find a way to file a security issue, so I thought I ask a question in this forum, hoping someone can reproduce it, and someone understands this is a security problem, and then forwards the problem to Apple. But that never happened.
Physlock works comparatively well, but nothing can stop the omniscient stupidity of, eg ctrl-alt-del 10x (or similar) invoking reboot, which I've found no method of preventing. The general attitude encountered when seeking a solution to this madness is "if someone has physical access, you're pwned anyway", which is also supremely unimaginative and omnisciently stupid. This has gnawed at my cranial portions for years, and I now speak forth in due fury.
What context? Reading that issue, the content seems to be:
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
> Why is it his responsibility to fix your code? The distro extended his program, the extension broke.
cinnamon-screensaver (the repo this discussion is pertinent to) is written from scratch. The commenter's intent here is to suggest that JWZ has valid criticisms, but he has voiced them before and his latest blog post doesn't add anything to the discussion.
This blog post, which links to the issue, creates additional overhead for the project to deal with. Just like this HN link does.
I think its fair for us to give them a voice in the matter if we're showing the discussion to everyone. It would be nice to assume people read the entire discussion but clearly, that is not a reality.
Even with their voice in the matter, the voice is speaking nonsense and trying to snow the reader (as your response seems to indicate. And that's being charitable and assuming you're sincere). Giving that voice oxygen is making the matter worse.
Cinnamon tried to re-invent the wheel. They made it very sparkly and shiny and colourful and forgot that it had to be robust, round and capable of rolling.
Jesus wept, you criticise other people for not reading the entire discussion, and yet you somehow missed the part in JWZ's post where he explains that Cinnamon-screensaver was NOT written from scratch. So congratulations, you hypocritically own-goaled yourself there too. Which again, makes me question the charitability of assuming sincerity.
And JWZ is supposed to "work with them" when their code fouls up for the Nth time? No, the idiots should've been writing modules for JWZ's engine, seeing as JWZ's is the one that a) they did indeed steal from and b) still screwed up.
Yes, he's voiced his valid criticisms before. And the damn Cinnamon tards STILL KEEP MAKING THE SAME MISTAKES. This adds to the discussion. It adds useful, educational history that the Cinnamon morons are so stupid that they repeatedly, in the face of history, keep making the same goddamn stupid mistakes.
I get to "the other side of the road" just fine with JWZ's screensaver. I just FIFTEEN MINUTES AGO had to step the housemate through replacing her new Mint install's Cinnamon screensaver with xscreensaver; because what a surprise, it's 2021 and the $hitpile that is Cinnamon screensaver lock would NOT RESPOND to keyboard or mouse and wouldn't let her log in. And either she had to either magic-sysrq, or I had to ssh in to the root account to kill the stupid pile of crap that is cinnamon-screensaver.
And I found this ridiculous comment on this thread, because I was trying to show her a reference as to WHY Cinnamon-screensaver is stupidly broken in its principles and why xscreensaver should be used instead.
Clement Lefebvre has some pretty big balls to have written what he did; and that's good. Because it'll make it easier to repeatedly kick him in them as he deserves for this. And defence of his positions is... not particularly defensible.
I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Good info, thanks for sharing. I can only be as accurate as the info I was provided. I did read JWZ's post -- I have his blog in my RSS feed and actually saw the post there before I saw it being linked here.
Mr. Lefebvre said "cinnamon-screensaver is written from scratch" in his GitHub post. I assumed good faith[0], and thought that maybe after nearly 30 years, JWZ was just a bit jaded and assumed the worst. I see that JWZ is probably the right one here, and clefebvre mistaken.
But Jamie has a certain "tone" that I would argue is a tad combative. To be fair, its his style, just like Linus Torvalds. But that lead me to see his comments in the context that he responds like this to every bad thing (TM) he feels lead to comment on, and I combined that with the GitHub response to conclude that JWZ was acting as a peanut gallery member here.
And please don't mistake my reasoning for support. In both my earlier comments, I was advocating for exposure of the response, not endorsement. I feel that is quite clear, and this is shooting the messenger.
> I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Welcome to HN, officially! But maybe chill with the cred dropping. Appeal to authority is no basis for an argument.
Unless there's something unbelievably wacky going on, this is why people use formal verification.
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
Another tangentially linked anecdote. We had build artefacts stored on a Samba shared drive, that were write protected, since some people regularly used to move them instead of copying them. Then one day, the latest build was gone again. We asked around to see whether someone had purposefully removed the build, but no. Turns out someone on Windows 10 had tried to cut and paste the file, but his computer had crashed before pasting. Apparently the permissions were only checked on paste, but the file was unlinked on cut?
i don't think these permissions are enforced client side... I also think write and delete are separate permissions on windows and i am pretty sure i never lost a file on accidentally doing only the first halt of a cut and paste aka move... so i conclude this "someone" either had nothing to do with the incident or removed it by accident...
I was surprised as well, but we could reproduce it. Delete would not work, "normal" cut and paste would throw an error when pasting, but cut and switch off power -> file was gone.
Sounds like something funky was going on, server side. For file operations, I don't believe the OS does anything to the file/folder for Cut and Copy operations, it simply notes the handle. Its only when you paste the file is when the operation happens. You can try this yourself, cut/copy a large file and see if your mem usage spikes and/or perform cut on any folder which you don't have delete rights for.
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked.
When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
339 comments
[ 1.9 ms ] story [ 1000 ms ] thread"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.
Hmm. Right spirit but not so much "hacking code together" going on at MIT's Tech Model Railroad Club in 1958.
"a project undertaken or a product built not solely to fulfill some constructive goal but with some wild pleasure taken in mere involvement, was called a `hack'".
(Steven Levy, "Hackers").
----
[1] "An Abridged Dictionary of the TMRC Language", 1959: http://www.gricer.com/tmrc/dictionary1959.html
( see also http://catb.org/~esr/jargon/html/index.html and https://en.wikipedia.org/wiki/Jargon_File )
2: Use ML to learn how to simulate it.
3: Sell it as a service, labeling it KaaS.
4: Profit, then go to jail because of a misunderstanding.
But seriously, is there such a tool to automate this?
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
Read the story here:
https://www.folklore.org/StoryView.py?story=Monkey_Lives.txt
[0] https://developer.android.com/studio/test/monkey
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
So a crash like this doesn't surprise me.
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
My final bill was £300+, zeroed.
Phew!
After long research, we found correlation with marketing moving their target from only students to 'older people'. Apparently the latter 'doubleclick' on links and buttons in webforms far more often. At least for us they did.
That was probably not a crash, on some that did a partial reset.
https://news.ycombinator.com/item?id=25801693
https://github.com/swaywm/swaylock/issues/162 https://github.com/swaywm/swaylock/issues/158 https://github.com/swaywm/swaylock/issues/10
Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)
(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)
https://github.com/google/xsecurelock
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.
Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?
Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily have its server component updated, but you run remote sessions that have an updated Xscreensaver. (Btw, if you do this, you're pretty dedicated in 2021)
This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.
Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.
Its not an X11 problem.
- https://bit.ly/3o2qekz
- https://bit.ly/38Y6pGO
(using bit.ly because he gives a testicle if referrer is HN :P)
- https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
- https://www.jwz.org/xscreensaver/toolkits.html
[Edit]: I understand now. My browser doesn't send referrer URLs, and I think that's the real fix instead of using something like bit.ly!
https://brave.com/privacy-updates-5/
edit: see also: https://www.cookiestatus.com/brave/#referrer
Source: https://wiki.mozilla.org/Security/Referrer
Just tested in Chrome and it works there as well.
I wonder why someone would setup a "bad result" for specific referrers ...
Can't count on everyone having referrer turned off
> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.
He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:
> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.
Which can be found via this thread: https://news.ycombinator.com/item?id=11412081 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#400
They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
Maybe using Xdummy instead of Xvfb would work better?
This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy
Edit: For me stuff
0: https://news.ycombinator.com/item?id=25844338
To be fair to swaylock, they actually fixed some of those issues, in contrast to kscreenlocker which are just ignoring most edge-case bugs, because it's nearly impossible to fix them.
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
> 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.
Also:
> In contrast to Wayland
I don't think Wayland is what you think it is.
My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.
Really? I have never seen this in Windows. Don't get me wrong, I've seen plenty of lock screen failures in Windows, usually in the form of it suddenly being unresponsive, just never anything that actually gave me access to the locked session again.
The closest I've seen is when using RDP, if the Window has been minimized or hidden or otherwise has had reason not to update its display, then locked due to timeout, it will briefly show the last image it rendered when reactivated before updating and showing the lock screen.
P.S.: As other users have pointed out, Windows does have some known lock screen bypasses using accessibility and help dialogs, but in regards to merely crashing the lock screen, I haven't seen it behave in an insecure way.
I wasn't too concerned about it since it still blocked all user input, but if you had sensitive info visible it could definitely be an issue.
The thread was linked below (or above, to this same parent), or see: https://web.archive.org/web/20210116101222/https://www.jwz.o...
How do I get the testicle in an egg cup?
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
An interesting website and blog, I like it! I wonder what their problem with HN is, although I don't mind being a testicle!
And really if you're being DDoSed by a small thing like HN comment links you really have to up your game :) Wait till you get featured on reddit (previously called slashdotting when slashdot was still a big thing).
Nor should he, not least because the redirect reliably results in ~90% of comments in any thread where jwz is mentioned being about the testicle in the eggcup rather than anything substantial.
PS: I have no idea what he means by "finance-obsessed"? I think the community at HN is tech-obsessed which is what I like about it. But finance? This is not yahoo finance or wherever all the finance guys hang out.
It sounds more like he had a clash with someone specific on a finance-related issue and bases his view of the HN community on that. The eggcup is a bit of an immature way to deal with this IMO. Especially as he has good points to make about X11 security, and this undermines them.
I don't know what prompted the redirect; it predates my awareness of Hacker News. I could guess, but why bother? The man has a nightclub to run, and I'm sure that's plenty all by itself to fill his days.
I like this site a lot, but I have a lot of patience when it comes to deciphering what is being affected by the Software Hub City Reality Distortion Bubble. Some people don't, hence the eggcup testicle, and people that think something like that undermines the technical argument aren't thinking clearly enough to even debate the technical point with anyway.
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.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
Also this bug (and probably most other bugs xscreensaver has had over the years) wouldn't result in an infinite crash loop anyway.
> 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.
All screens lock together etc.
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
I'm imagining 2 processes:
1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process
2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt
When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.
If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.
None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.
https://www.jwz.org/xscreensaver/toolkits.html
There is also xsecurelock [1] by Google.
[1] https://github.com/google/xsecurelock
Argh. That would be the window manager, of course.
* Do you use a nvidia GPU * Do you need to screen share from electron or other x11 only applications (MS teams, etc)
Its ready if you said no to both of those.
Doesn't XWayland solve this?
Firefox supports Pipewire, Chrome has it behind experimental flag. Electron apps like Skype or Teams? Forget it.
Log in, open firefox. Minimize the window, and the entire machine freezes. This is on an AMD GPU as well.
Every time I try Wayland, whether it be sway on my laptop or plasma on my desktop, I run into snags that did not exist in X. So back to X I go.
I'll switch to Wayland when it's ready "for real, actually, promise", and not a moment before. Maybe when Debian Stable switches to it by default.
When I open it again, the desktop is accessible for a few seconds (sometimes long enough to launch programs) before the lock screen activates and I have to input my password. The workaround I use is to manually lock with Win+L before closing the lid.
It will go to sleep, then when I wake it up, I get a flash of my desktop before the lock screen shows..
Too fast to write anything down by hand, but you could certainly point a 60fps camera at it and get something I'm sure.
I don't think I could interact with the screen in any way, but I could certainly take a picture of it, if I had any private information on the screen.
The number of emails I got from that was worth the vitriol contained in them, including threatened lawsuits.
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
For example LLVM's lib fuzzer uses instrumentation to track code coverage and mutates data to find invalid behaviour.
https://llvm.org/docs/LibFuzzer.html
It uses a compiler pass to insert code to branch points functions calls etc. I think it uses genetic algorithms to increase coverage by changing the data.
There are others that work in similar ways one of them is. https://github.com/google/AFL
See https://quickstrom.io/
(I haven't used it myself yet, but it looks interesting.)
https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291...
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
But this is pretty impressive as well!
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
Wow every new person who joins that thread misses the point more than the previous one. This was painful to read.
> I don't see the point of pressing the wrong series of key combinations nine or more times in a row constitutes a "Login Window ScreenShot Problem" any more than dropping my MacBook from various heights until it breaks is a reliability problem.
Why do people hold computers to such a lower standard than other complex devices in their life? (Serious question -- I don't understand people very well here.)
Can you imagine a car that wouldn't unlock or start if a passerby without the key plays with the door handles too much? If this has happened and is documented, that alone is a testament to its rarity and people's unwillingness to excuse the behavior.
Unless it happened to early Tesla, because they were held to the lower standard applied to computers and OSs. That doesn't seem to be as true anymore, thankfully.
I've definitely had my Model 3 not unlock when it should, but I've never had it go the other way around.
On the previous version I believe he managed to unlock the computer as well, just by hammering the keyboard.
https://linuxcommandlibrary.com/man/physlock
smashes keys
Unlocks
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
cinnamon-screensaver (the repo this discussion is pertinent to) is written from scratch. The commenter's intent here is to suggest that JWZ has valid criticisms, but he has voiced them before and his latest blog post doesn't add anything to the discussion.
This blog post, which links to the issue, creates additional overhead for the project to deal with. Just like this HN link does.
I think its fair for us to give them a voice in the matter if we're showing the discussion to everyone. It would be nice to assume people read the entire discussion but clearly, that is not a reality.
The commit is at https://github.com/linuxmint/cinnamon-screensaver/commit/38a... where mtwebster writes:
> We'll use the old screensaver auth code instead - this ports gs-auth-pam.c and gs-auth.h from the old screensaver,
Cinnamon tried to re-invent the wheel. They made it very sparkly and shiny and colourful and forgot that it had to be robust, round and capable of rolling.
Jesus wept, you criticise other people for not reading the entire discussion, and yet you somehow missed the part in JWZ's post where he explains that Cinnamon-screensaver was NOT written from scratch. So congratulations, you hypocritically own-goaled yourself there too. Which again, makes me question the charitability of assuming sincerity.
And JWZ is supposed to "work with them" when their code fouls up for the Nth time? No, the idiots should've been writing modules for JWZ's engine, seeing as JWZ's is the one that a) they did indeed steal from and b) still screwed up.
Yes, he's voiced his valid criticisms before. And the damn Cinnamon tards STILL KEEP MAKING THE SAME MISTAKES. This adds to the discussion. It adds useful, educational history that the Cinnamon morons are so stupid that they repeatedly, in the face of history, keep making the same goddamn stupid mistakes.
I get to "the other side of the road" just fine with JWZ's screensaver. I just FIFTEEN MINUTES AGO had to step the housemate through replacing her new Mint install's Cinnamon screensaver with xscreensaver; because what a surprise, it's 2021 and the $hitpile that is Cinnamon screensaver lock would NOT RESPOND to keyboard or mouse and wouldn't let her log in. And either she had to either magic-sysrq, or I had to ssh in to the root account to kill the stupid pile of crap that is cinnamon-screensaver.
And I found this ridiculous comment on this thread, because I was trying to show her a reference as to WHY Cinnamon-screensaver is stupidly broken in its principles and why xscreensaver should be used instead.
Clement Lefebvre has some pretty big balls to have written what he did; and that's good. Because it'll make it easier to repeatedly kick him in them as he deserves for this. And defence of his positions is... not particularly defensible.
I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Mr. Lefebvre said "cinnamon-screensaver is written from scratch" in his GitHub post. I assumed good faith[0], and thought that maybe after nearly 30 years, JWZ was just a bit jaded and assumed the worst. I see that JWZ is probably the right one here, and clefebvre mistaken.
But Jamie has a certain "tone" that I would argue is a tad combative. To be fair, its his style, just like Linus Torvalds. But that lead me to see his comments in the context that he responds like this to every bad thing (TM) he feels lead to comment on, and I combined that with the GitHub response to conclude that JWZ was acting as a peanut gallery member here.
And please don't mistake my reasoning for support. In both my earlier comments, I was advocating for exposure of the response, not endorsement. I feel that is quite clear, and this is shooting the messenger.
> I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
Welcome to HN, officially! But maybe chill with the cred dropping. Appeal to authority is no basis for an argument.
[0]: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html#comments
Pretty rich from someone who starts with "I'll fight him in a cage match"
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
Start kiosk mode fullscreen app as a lock screen -> if app exits -> show desktop
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked. When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
In general, the way you secured a Windows 9x box was by locking the door to the room it was in.