I find interesting that GNOME Screensaver's security depends on it to not crash.
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
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 %1
Afterwards switch back to the running session (Ctrl+Alt+F%2).
If ksmserver itself crashes then the entire session closes.
I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
In Windows it’s also good. The way it works is follows.
The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).
To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.
The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.
BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
> BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
When I mine cryptocurrency while playing games, I appear to sometimes run out of GPU memory (Both Task Manager and MSI Afterburner let me monitor usage) and I have experienced this reset. It's surprisingly graceful, even when a game is running, though NVIDIA Broadcast often doesn't like it and needs to be restarted, and I will sometimes see lingering graphical glitches in the game until I restart, but it's not game breaking.
You can also trigger a GPU reset manually with CTRL-WIN-SHIFT-B.
>I'm not sure why GNOME screensaver cannot do something like this.
This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.
jwz has a lot to say about complex graphical toolkits/desktop environments and their complex locking mechanisms. It's an interesting series of posts.
If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Also, if you're using a Hacker News app, it won't send a Referer header when opening an article unless the app authors went out of their way to implement that. I would be surprised if any did.
I would recommend not linking to jwz's website. Use web archive or something if you have to. jwz dislikes Hacker News and intentionally shows an NSFW image when Referer header shows Hacker News.
Can he at least update the text? HN was full of entrepreneurs and wantrepreneurs years ago. It is mostly big- and mid tech employees now, tech bureaucrats if you will.
Not to belabor the meta discussion, but your comment sparked a question. If it is how you say, and using a politico-economic lens, I wonder if there has been any discernible shift in commenter attitudes as the demographics have changed. Specifically, if the shift was from entrepreneurs -> skilled wage workers, as you’ve asserted.
The interests of the petit bourgeoisie (entrepreneurs, et al), the professional management class and that of skilled workers sometimes overlap. I think those overlaps would probably translate to some overarching strains of belief, for example, the tendency toward libertarian viewpoints on HN.
Sorry for the tangent, just had to get that out of my head!
This is OT, but I can't resist. I've been around HN since 2011, and tone has definitely shifted in the last 5-6 years. I used to stumble on HN posts that infuriated me relatively often, it was part of the deal (i.e. understanding how the self-appointed entrepreneurial classes actually rationalize certain things). That doesn't really happen anymore.
> those overlaps would probably translate to some overarching strains of belief, for example, the tendency toward libertarian viewpoints
The opposite is actually true, in my experience. Hardcore libertarian views on HN have been largely quashed into irrelevance, they only survive in lore. New commenters who join and expect HN to be a nest of hyper-capitalists are quickly downvoted into oblivion. Which is not a terrible thing in the great scheme of things, from the personal perspective of somebody who would likely dislike their point of view; but it has definitely taken something away from the HN experience, and possibly pushed some people towards worse (more radicalized) forums.
What I miss about the old HN is learning about all the cool new programming tools, libraries, frameworks, etc and participating in the discussions about them. These days, you rarely see posts about programming tools, unless it is one of the big ones like React, Qt, or TypeScript. I used to stumble upon so many great tools on HN, but that has become a rare experience these days.
Is there still somewhere on the web, perhaps on Reddit or another platform, where you can find such posts and discussions?
>Is there still somewhere on the web, perhaps on Reddit or another platform, where you can find such posts and discussions?
If they exist it would be wise not to link it here, or else the same fate would befall the new community. My advice is to search for a small community around a niche topic (say a specific text editor or programming language).
There are some great Reddit subs for niche projects, the trouble is discoverability. Those I’ve found have always been via obscure links or a chance hunt after finding a git repo.
I’ve also been around for donkeys years, and I agree mostly. Certain topics bring the “screw you, got mine” opinions back out of the woodworks at times, but yeah it’s far less prevalent.
> Hardcore libertarian views on HN have been largely quashed into irrelevance
Having seen a few threads recently (notably "Parler off AWS") where those views seemed quite exuberant, I'm not sure they've been quashed; maybe dormant until the right thread comes along?
It has something to do with the 1990's dot-com culture, like the original Netscape was somehow more pure than what came after, and this causes him to view modern inheritors like YC with a jaundiced eye.
It's quite nice of Apple to strip this by default in Safari—didn't even realize it was a thing until I switched over to Chrome to see what you were talking about.
I tested Safari on iOS, iPadOS and macOS and it didn’t strip the “referer” header for any of them. WatchOS did strip it though I’m not sure that counts as Safari.
Anecdotally, I use xidle[0] and xlock[1], and have found both to be very reliable. xidle supports locking the screen by sending it SIGUSR1, which is really useful since you can trigger it from a process that doesn't have DISPLAY set.
The trick on laptops is to block on sending the signal in the script you use to suspend, so that when the laptop resumes the display is already locked.
I actually had this happen around Christmas (using Manjaro). I had no idea what the message really meant or what caused it. The instructions were at least clear enough to get back into the running session, which is far better than, say, most of GNOME's crap.
> Our internal research found that clear error messages confused our users and removed it.
I can't tell if this is sarcasm or if you're serious. If you're serious, please tell me what product you've butchered so I can avoid it like the plague.
Clear error messages only confuse people who shouldn't be using the product in the first place. More importantly: a clear error message at the cost of a few confused users is far more important than an unclear error message that costs even more users hours or days of trouble.
I would far rather have a message that tells me that the software broke because the desktop manager found a crash loop and point me to the crash loop logs even if some other poor unfortunate soul has no idea what a crash log is or can't figure out how to access or understand the crash log.
I've had similar discussions at a previous job with their platform (it was a marketing dashboard). Management wanted developers to suppress error messages because users wouldn't know what to do with them. However, users always contact the help desk when things go wrong. User feedback became much harder for us to understand, so issues would take much longer to resolve. Instead of saying "I did ABC and I saw a message that said 'XYZ'", they would say "I did ABC and it broke"
I'm asking nicely, can we please not do this? Let's not exacerbate the problems of bad communication by using more sarcasm and hyperbole. If there is some particular thing that can be done to improve areas where there are perceived design proclivities, can we focus on that instead?
I agree that sarcasm provides for poor constructive criticism to get a point across, but the intent was mockery, not being helpful.
I certainly do not believe that GNOME would take the advice of an H.N. post, and they are well aware of these criticisms to begin with, as they are commonly levied against them.
I don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.
Please don't discount yourself like that, by resigning to the usual HN snark. I think you're smart and capable of much more. If there is new, important and relevant information brought to them, they will listen to that. (This applies to most big projects I've seen, not any one in particular. The smaller niche ones that commit to having their small narrow audience are the ones I've seen that tend to be resistant to new ideas)
Many developers and executives do participate in social media including Hacker News. I have seen plenty of tech-related fixes and features that come directly from Hacker News comments.
In all I think the best feedback I can give you would have been to include a `/s` to indicate sarcasm and jest.
> Many developers and executives do participate in social media including Hacker News. I have seen plenty of tech-related fixes and features that come directly from Hacker News comments.
But the comment wasn't bringing up anything new about GNOME. There is no information someone from GNOME could get from that post, no matter how it was worded. It is not a constructive vs. snark situation.
> In all I think the best feedback I can give you would have been to include a `/s` to indicate sarcasm and jest.
It seems like the same argument would have happened anyway, so eh.
I am sorry if I'm being pushy, it just gets extremely tiring to see all the same type of comments for years on places like here and on /r/linux. You don't have to listen to me if you don't want, it's just my humble plea.
This seems like an obvious response to gnome's poor behavior in the open-source ecosystem, they've been been burning good will among a large group of developers for a long time now. I think the solution to that problem isn't to ask people nicely to stop being pissed off, it's to fix the underlying problems/attitudes.
I am not saying don't be pissed off, I am saying please channel that energy to help to fix the underlying problems/attitudes. I can give suggestions on how to do this, if you're interested to hear it, so we can maybe have a chance to finally get some issues fixed. Beating the same dead horse going on years now is just not going to help this, regardless of what your perceptions of certain developer's attitudes are. If complaining about lost goodwill was ever a substitute for being persuasive and getting things done and taking initiative to restore the goodwill, it would have worked years ago, and we wouldn't be here talking about this now.
And just to be clear, harassing developers who have said "no I don't want to work on feature XYZ" is never acceptable and never has good results. If somebody says no and is just not interested, we leave them alone and we find someone else who does want to work on that feature.
Not having type-ahead, instead using gnome's search, makes GTK apps really annoying for me. Right now I have a solution that involves patching, but presuming that my ultimate goal is just that one concessions, just have a flag buried somewhere that would enable type-ahead instead of search, how do you suggest I get that done?
I think that would go a long way towards demonstrating that gnome can be reasoned with, is worth even approaching or talking to.
Could we hire a developer? Set up crowdfunding? Can someone give me a quote and I can see what resources I can bring to bear on the problem?
I'd be open to other suggestions on how to channel that energy productively, but I really think if they can't compromise on that one feature that's important to a bunch of people then they're probably not going to be worth dealing with. Feel free to send me an email, at gmail.
If you have a working patch for this that makes it a configurable option then just use that. There is no harm in submitting that as a merge request either, worst case it gets rejected again and you're in the same spot you are now. I don't believe a real non-intrusive patch was ever submitted for this, everything out there just seems to be a revert back to some old functionality that breaks other things. (Please don't waste maintainer time submitting patches that are broken or hacky, or patches that were already rejected. When in doubt talk about it with them first before submitting anything, and make sure your patch is actually new and addresses all the concerns that were made in the bug tracker already)
If it does get rejected then you do the same thing you'd do with any other open source project: convince your distro to carry the patch. I think the key here is to just not lose sight of the goal which is to get enough support somewhere to have the patch maintained, if you don't care to become an upstream developer and work closely with them then you can skip that and just do the same process but only with a downstream that is relevant to you.
If the patch still needs a lot of work/money to get it to the point where it's stable and doesn't break other things, well, now you know why upstream doesn't want to do it... so with that I would say a way to help would be to commit to maintaining this for however many years you expect to be using the patch. I can't give you a specific quote (I don't have any interest in working on this, sorry) but based on average developer rates you probably should expect to spend at least a few thousand dollars on this total, over several years of maintenance time, if you are not the one who is going to be writing the code. Of course, you can reduce the burden on yourself by getting a distro to share the cost, which is why I suggested that first :)
>When in doubt talk about it with them first before submitting anything
Normally you'd do that before even working on the patch, and you can see what kind of response that's gotten.
I've got a patched version that suites my needs, as I say. That being said I'm sure raising a few thousand dollars for that feature wouldn't have been hard.
I don't think we have. Like I said, I have not seen any serious offers to work on a non-intrusive patch for this, to put up the time and/or money and to maintain it for the number of years required. That's what you want to look for. And if you want to bring it upstream, you have to sell it to them in a way that shows it will not increase their maintenance burden or break the currently in-place designs. (This is not a GNOME specific thing, this is how basically every open source project operates. You generally can't just dump code on upstream and expect it to go well)
If you want to do fundraising, some trusted person has to put in the time to do it and to manage the money.
>lest people make the mistake of building stuff on top of it.
This is the kind of hyperbole I'm talking about... As with any open source, you don't have to use the parts you don't want. GNOME as a whole is a pretty big project, and like most projects, some of its parts are stable and up-to-date, and some aren't. Lots of other desktops build on pieces of GNOME technologies because they work, and replace the parts they're unhappy with. So I'm sorry if you feel a particular component made a mistake, but it really does not have to be a mistake that affects you, if you handle things the right way.
Can you be more specific about what kind of citation you're looking for?
I don't want to use systemd-logind or the gnome search services. Right now not using either of those requires a whole lot of work. It's actually pretty hard to use GTK apps with only the GTK toolkit and not a bunch of other software daemons. Hell, in a perfect would I'd even get rid of dconf and gnome's weird registry, but I recognize that as pretty integral to the toolkit.
AFAIK the only component that really relies on logind is GDM. If you don't want GDM and are comfortable using another display manager to launch your GNOME session, that should work fine, although I haven't tested this in a while. You may also be able to launch your session manually the old way, without a session manager, although that will probably require you to use setuid X which comes with the usual caveats. It's probably a total no-no if you're using wayland. If you decide you want GDM and wayland then you still don't need systemd-logind for session management, you can use elogind, or you can grab BSD's patches for consolekit support. The real issue there is that GDM requires some kind of session management, if you want to do this without any other daemons whatsoever, then you will have to reimplement parts of logind/consolekit inside GDM.
With the search services, there is a switch for that in settings under "Search."
With dconf, that is not actually integral to the toolkit. The API that applications use is GSettings, which requires a backend to actually store the settings, and dconf is just one of those backends. You can disable the dconf backend and just use the one that writes ini files to your home directory, or use some other backend. Technically apps can try to force the dconf backend but I've never seen one that does this.
Maybe the issue is what you consider a "clear error message"?
A clear error message should not necessarily clearly explain what the issue is - a clear error message should clearly explain how to solve the issue, or at least point the user in the direction of a solution.
At a minimum, a clear error message should include a contact point and what information to include. If error logs are available, they must be available for inspection, annotation, and approval before submission.
I have no idea why GNOME is the default DE for the big distros (Redhat et al, Ubuntu). Technically it's evidently inferior, it had substandard ergonomics and features like accesibility services. I really dont get it.
The Gnome screensaver lock is only a fluffy fake security mechanism. It's not real security.
I've had many instances where my CPU was bogged down and after hitting the keyboard I could use the computer for a good several seconds before the lock screen popped up asking for a password.
> I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
That is an option Linux Mint is considering[0] among other options.
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.
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.
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.
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..
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?)
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.
> 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.
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)
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.
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.
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.
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.
Can anyone explain why a crash in xscreensaver results in the computer being unlocked?
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
KDE has a failsafe mechanism. If the screen locker has crashed, it shows a black screen of death with a huge error message.
> The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session.
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.)
> 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.
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.
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.
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.
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.
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.
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.
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.
"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.
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 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.
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.
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.
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.
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.
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.
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.
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.
Years ago I taught a high school typing class in a K-12 school. The school didn't have the funds to get a commercial typing program so I wrote my own typing program. It evolved over time with features to help me track the students' progress etc. One day we had a school open house where all the parents could come to school. We had a bunch of different activities set up in different classrooms and I ended up getting assigned to the 3rd grade classroom to set up my typing program so anyone coming through could test their typing speed. It was a DOS program and I didn't want people using anything other than my typing program, so I modified it so you couldn't quit the typing program. Over the course of the day the 3rd graders were hanging out in their homeroom not really doing anything productive. Of course the computer was a novel attraction and they were just smashing keys and exploring my program's UI. Eventually at one point I noticed that they had somehow crashed my program with a segfault in what had otherwise become a pretty stable piece of software. To this day I have absolutely no idea what the bug was.
> The school didn't have the funds to get a commercial typing program so I wrote my own typing program.
Off-topic, but:
It seems absurd, to me, that such a conclusion could ever be reached. Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours. To me it seems that it's certainly not cheaper for us as a society, as a species, and only appears so because you are under-paid. If you were paid your actual worth, the school would say "we don't have the funds to develop this in-house, and had to buy a commercial typing program off-the-shelf, despite its loose fit for our use case."
How can we, as rational members of society, abide this?
Where I work there is a tool that's used in hundreds of our internal services. It was written in-house during one of our hack weeks years ago, and later we open-sourced it. Despite the fact that the org relies so heavily on it, it's completely unfunded; two employees improve and maintain it in our free time. (We do have a few outside contributors, too, which is awesome!)
That's not exactly the same situation, but I think this kind of short-sightedness is pervasive in our culture, in every walk of life.
To go in another off-topic direction...of course I mainly did it because I wanted to. I had a view about how to teach/learn typing that the popular typing programs then didn't seem to have. When you're learning typing for the first time, IMO it's fundamentally a kinesthetic endeavor. It's more important to focus on burning the motor pattern of moving your finger from the home row to the key you're typing and back to the home row than remembering where the letters are placed on the keyboard. (Of course you have to also remember where the letters are, but that will happen automatically in the process of doing the former.) So I wanted to take this into account and have my students type things like this:
fff ggg fgf gfg ffgg fggf gffg
jjj hhh jhj hjh jjhh jhhj hjjh
This forces the student to exercise that movement pattern in a way that just telling them to put their fingers on the home row and type English words does not.
So the above sentence you quoted was a an over-simplification for story telling purposes and not the whole story. :)
> Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours.
If you measure it by cost to the district (for which a teacher doing it in their off hours is $0), it's clearly not, even if you only consider the sticker price of the commercial software and not the other costs associated with purchasing in a school.
> If you were paid your actual worth,
The school would fire about half it's teaching staff in order to make budget, and still not have money left over to either develop or purchase the typing program, probably.
How do you commercially produce "better quality per dollar" when the high school teacher's off-hours cost the school $0 and they get infinite quality per dollar?
Calling work done in off-hours "$0" is magical thinking. That teacher costs a lot to maintain. Those of us who are employed full-time don't really have "off-hours", and regardless of the intensity with which we focus in a given 60-minute period.
Sometimes, while at work, I am thinking of leisure.
Sometimes, while at leisure, I am thinking of work.
At the end of the day, the school pays their employee. And the rest of society pays them during "off-hours", e.g. in depreciation of common resources if, say, they drive on the road.
My point is that people cost society to keep alive, but some of those people are better equipped for certain tasks than others. The question is only where do those costs come from, and to what particular efforts are the particularly-equipped assigned.
Are you sure it was a segfault? DOS did not have any memory protection, so segfault would be impossible. Or maybe you used some protected mode DOS extender?
My memory is getting a little fuzzy. I think the machines we were using were running Windows 98 or perhaps Windows 95. But I didn't want people to be able to do other things on the computers that day as the whole point of the endeavor was to emphasize typing skill, so I looked for some kind of way to make it impossible to do ALT-TAB to switch to a different program. I was thinking I booted it up in DOS only but I also might have run it full screen in Windows and just hoped nobody knew about ALT-TAB. :P
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
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.
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").
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 ;-)
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.
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.
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.
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.
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.
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.
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 :)
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.
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.
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.)
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.
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.
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.
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.
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!
I enjoy to see my kid breaking software, POS terminals and causing ATMs to throw error windows. Nothing critical, just funny how random screen touching and keyboard mashing drives “serious” software crazy.
Fool-proof and child-proof software is yet to come.
3 y.o. figure it out better than my parents because it seems their mindset is ‘do all the things’ to see what the i/o structure is. Their brain is built that way when they are so young.
Not really the same, but I had fun back in high school. Finding the Novell messaging utility that let me send a message to (IIRC) anyone in the school board currently logged in, though not anonymously.
Using some a couple lines of VBScript to change a couple registry entries (computers didn't persist storage anyways) you could also give your local admin privileges, to install stuff. That one got me in a touch of trouble, and I lost my account for a couple weeks while they "looked at my files", because I stored it on my network drive folder.
Linux Mint, and whatever it's built on, has been disappointing to me. The most worrying thing I've experienced is that, when waking up from sleep, the unlocked screen will sometimes flash before showing the lockscreen. That is a huge no-no and really betrays the fallibility of whatever security measures are employed.
I remember finding a very similar issue with XDM on a Sun 3/60 back in about 1992. Just mash the keyboard while in the 'password' field and it would eventually drop a root shell. Oops!
The first computer I ever bricked was a my father's work laptop running Windows 95. I was a toddler and wanted to press the buttons. Good to see the kids are still at it!
That reminded me of the Linux GRUB2 bug where you could press Backspace key 28 times and bypass all security. [1]
>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.
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
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.
Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
If ksmserver itself crashes then the entire session closes.I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.