#TIMELESS INK STUDIO SOFTWARE#
If a security-focused software distribution that I am using ships with known security flaws, I would like to know about them so that they can be weighed into my workflow. notourbug: When upstream can't fix a security flaw, and you won't fix it, closing the github issue that collects information about it removes visibility of the bug, which I feel is detrimental to the user experience.The latter part was bolted onto the solutions as an afterthought, and it kind of shows. Originally screensavers were meant to - save the screen from burning a permanent image, not to act as a security-critical component. XScreenSaver in particular has had a few "exciting" bugs that allowed bypassing the lock screen:īut this is not exclusive to XScreenSaver (see #963 for the exact same issue in KDE's screenlocker, also on Qubes and here also reports that it's broken) building an X11 screensaver application is a design flaw in itself.
This means locked xscreensaver displays sensitive notifications #2026 will not be fixed upstream since it cannot be fixed.
The screen locker runs in dom0 and protects the whole system, so I don't see how that argument intuitively extends to mean that screenlocking is not security-critical. It is my understanding that your argument for refraining from noticing people about bugs in browsers, or the recent LibreOffice exploit (that still works?) is that they expose AppVMs, but not dom0, to danger, and you don't care about what runs in people's AppVMs. I personally think it's a somewhat important aspect of a distribution that aims to provide people with a secure desktop, but if a working screen locker is not a priority that the Qubes team shares, and the only security-critical component worth issuing QSBs about is in fact Xen, I feel it would be more honest to be up front about that, or just removing xscreensaver entirely and let people who cares about being able to safely lock their screen seek out their own solution.Īt least this stance comes as a surprise to me, and I think it will be surprising to people who currently use Qubes in shared office spaces, in transit, or anywhere their equipment may conceivably be stolen or momentarily accessed by other people. I appreciate that every reconfiguration carries cost, and it's a question of priorities.
#TIMELESS INK STUDIO HOW TO#
We issue QSBs to notify users of security-critical bugs and how to patch them (among other reasons). On the contrary, if it looks like the upstream project isn't going to fix #2026 (and we can't or won't do it for them), that might be all the more reason to increase the priority of #1917.Īnd if that is the strategy that Qubes wants to go with, we could erase most of the Qubes security bulletins already, since even if they affect Qubes users, very few of them are in software maintained by the Qubes team. It doesn't follow that we're going to ignore the underlying issue or that we don't care about it. If #2026 is genuinely a bug in an upstream project's software and not ours, and if our developers cannot or will not fix that bug for the other project, then closing #2026 as notourbug is probably the correct thing to do. To be precise, closing #2026 does not entail closing #1917. Closing this issue as notourbug does not entail that we'll ignore the screeenlocker topic in general. Saying that it's notourbug is IMHO equal to saying meltdown / spectre is not our bug, so lets ignore it, But switching is not easy, and doing so carries opportunity costs. It's not entirely "by choice." If we could wave a magic wand and switch to physlock with everything working perfectly, I'm sure we would've done so years ago. Notably physlock, which we have been discussing for years in these Github threads now.
Pictures of phoenix tattoos.It's a bug that we expose our users to by the choice of software we include, and by choice, since there are solutions available that does not have these security flaws (things leaking, bypassing authentication when the application crashes).
0 kommentar(er)
