I noticed that valve is recommending against cryoutilities as of 3.5. what's the recommendation on b
I noticed that valve is recommending against cryoutilities as of 3.5. what's the recommendation on bazzite?
Kbuilding w/ this on
:testing
APls test first that blocks for 5s
KBazzite uses ZRAM same as Fedora and the next SteamOS release
ADon't use cryoutils, it doesn't really work on Bazzite
KNo swap file what so ever
K@Qwx576SDZf If you want, when this is done you can rebase to
:testingGNOME closed the issue stating what you experienced is not a bug
Kso we're gonna try and work around it
KI hate my internet 
that almost took an hour
that almost took an hour
DWhy is this?
KValve hasn't said anything about Cryo
Kbut they are dropping the concept of a swap file in the next SteamOS release entirely
Kso Cryo will do absolutely nothing
DAh ok
WI didn't fact check it, but what I read is today was supposedly a quote from valve saying they no longer recommend cryo on 3.5 because it supposedly addresses the same things cryo does
KValve has never recommended cryo
KIf they did, it would have been built into SteamOS
Kthe only time Valve even spoke on Cryo was to ask for reproducible benchmarks showing it made an improvement (none were provided)
KCryo is a collection of tweaks which have been spread around in the linux community for a long time, most of which are known to harm performance or not help it.
AI don't know about the other fixes, but a larger swap file definitely helped with system stability when I was doing PS3 emulation
ANever helped with performance though
JIs there a dbus-based screen lock vulnerability which could be replicated in KDE?
JYou'd probably have to use a different dbus address
KNot that I have seen, if there was it would have been triggered by the exact same thing
JI'm going to test this in KDE to see if I can replicate it
JIf KDE's login screen can be unlocked with
loginctl unlock-session(I'm no polkit expert, I just think it seems a teensy bit too trivial for someone to fire off a sleeping payload with a simple
sleep $SECONDS; loginctl unlock-sessionThe whole reason this is using that path too is it's the only way to request gnome not to fall asleep
KIt just happens to also unlock the screen from a locked state
KOr at least it was, maybe things have changed
KStill seems very suspect
Ayou cant, your user has the permission to unlock your session
Athat payload can do whatever somebody sitting on your keyboard can after it unlocks your session
Aso from a security standpoint, not being able to unlock your session is kinda mut
JUnlocking implies that there's a lock. When you have services like gnome-keyring storing your passwords, you don't automatically unlock them even though the files and the contents inside are owned by your user. You still need a security mechanism to ensure that not just anyone is accessing your resources. We already do this in several ways with the login screen before or after login, including A) what you know (password) B) what you have (smart card) C) what you are (biometrics such as fingerprint)
Athe only way to unlock your keyring is to enter your password
KHellow :3
Is there any special setup required to use scrcpy?
I installed it via the bazzite welcome screen, but everytime I want open the App, nothing happens.
ujust just offers a
Is there any special setup required to use scrcpy?
I installed it via the bazzite welcome screen, but everytime I want open the App, nothing happens.
ujust just offers a
install-scrcpyits very easy to test this as if you login with a fingerprint, your keyring does not unlock
JI was talking specifically about the login screen for those multiple authentication examples
Asomething running on your device already has access to yoru files
Aso it being able to unlock the lockscreen for an attacker to do the same is not a security vulnerability
Hyafti runs
keep in mind scrcpy works only over usb cable unless you adb to your phone and enable the adb server (a phone reboot kills it)
ujust install-scrcpykeep in mind scrcpy works only over usb cable unless you adb to your phone and enable the adb server (a phone reboot kills it)
Athe lock screen is meant to prevent physical tampering, if your device is owned at the user level, that's already the case
H@antheas let me unlock this random gnome computer
plug in gamepad and press button
this is similar-ish to the razer issue where you could elevate to admin on windows using a razer mouse on a machine that didnt have the driver installed
plug in gamepad and press button
this is similar-ish to the razer issue where you could elevate to admin on windows using a razer mouse on a machine that didnt have the driver installed
Aunfortunate bug with the library that keeps the computer awake
JWe discovered this purely by accident in a distro that packaged software intended to handle an unrelated function. Remember, it was replicated by pressing a button with a gamepad.
Athe endpoint it used unlocks the lockscreen
JWe don't know what other script authors are doing this purely by accident, nevermind out of malice
Awell, looking at the script it handles more than 8 DEs
Asoooo probably accident
