On top of what other said, the wayland project also maintains the wayland protocols repository which includes additional protocols that are approved by a “committee” that includes representatives from wayland protocol implementations (wlroots, kde , gnome , smithay etc). for example now they are working on color management.
There appears to be a consensus among people working on window manager implementations that X has to go and wayland is the future.
Wayland has technical benefits, if you want the nitty gritty details see this.
Basically X11 is bad IPC at this point.
Also be careful with what you read online, I see misinformation about it relatively often.
This is great!! I use macOS for work but I’m sure I can get 90% of the work done on Linux now! Just wondering about GPU perfomance? Video editing is crazy fast on macOS, anyone tried on Asahi?
You’ve already gotten great answers on what Wayland is, but as far as who should care:
Mainly developers and users with niche workflows. People with NVIDIA cards should care a little as initially NVIDIA did not support Wayland, but NVIDIA drivers are catching up so this should continue to improve. Most users should just switch when their DE switches.
The messages you’re getting sound like they’re from the bootloader, so I think secure boot is not causing the problem… Linux should print some stuff right away when it loads, maybe check the architecture of the kernel you’re trying to boot, even an error immediately after loading the kernel should print something unless the architecture is so different that it’s just feeding the CPU bad instructions… Not sure how the bootloader would get installed correctly in that situation though. Is this after installation? Does the system boot from a live USB or cdrom?
Have they fixed the copy+paste problem from the Firefox address bar under Wayland in KDE plasma yet? I’ve been holding off switching to Wayland in my Plasma desktop because of that one Firefox issue.
Example: there’s another user with sudo access, he has access to my home folder, encrypting the drive doesn’t solve anything. Or maybe you just are not the system administrator.
It’s not my usecase, but it’s definitely a reasonable situation.
Unless some sandboxing or other explicit security measure is in place, any software you run typically has access to your entire home directory, including .ssh/. If any one of those was compromised somehow, they’ve got access to your SSH keys.
Yes, it can be done. Not to the point of deleting your key (that makes no sense - you need the key), but ssh-agent is what you want. Add it to your shell config and it will only ask to be unlocked once per however often you define.
I have this function defined and called:
<span style="color:#323232;">function ssh-agent-setup() {
</span><span style="color:#323232;"> # SSH agent
</span><span style="color:#323232;"> pid_file="$HOME/.ssh/ssh-agent.pid"
</span><span style="color:#323232;"> SSH_AUTH_SOCK="$HOME/.ssh/ssh-agent.sock"
</span><span style="color:#323232;"> if [ -z "$SSH_AGENT_PID" ]
</span><span style="color:#323232;"> then
</span><span style="color:#323232;"> # no PID exported, try to get it from pidfile
</span><span style="color:#323232;"> SSH_AGENT_PID=$(cat "$pid_file")
</span><span style="color:#323232;"> fi
</span><span style="color:#323232;">
</span><span style="color:#323232;"> if ! kill -0 "$SSH_AGENT_PID" &> /dev/null
</span><span style="color:#323232;"> then
</span><span style="color:#323232;"> # the agent is not running, start it
</span><span style="color:#323232;"> rm "$SSH_AUTH_SOCK" &> /dev/null
</span><span style="color:#323232;"> >&2 echo "Starting SSH agent, since it's not running; this can take a moment"
</span><span style="color:#323232;"> eval "$(ssh-agent -s -a "$SSH_AUTH_SOCK")"
</span><span style="color:#323232;"> echo "$SSH_AGENT_PID" > "$pid_file"
</span><span style="color:#323232;">
</span><span style="color:#323232;"> >&2 echo "Started ssh-agent with '$SSH_AUTH_SOCK'"
</span><span style="color:#323232;"> fi
</span><span style="color:#323232;"> export SSH_AGENT_PID
</span><span style="color:#323232;"> export SSH_AUTH_SOCK
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">ssh-agent-setup
</span>
This way it stores the unlocked key in memory until the end of the session.
But if it’s stored in a keyring or similar (like on windows) and the client reads from it you don’t need the file with the plain text key. Like you don’t store the git credentials in a file, but with libsecret.
I would prefer something that never ask for the password.
Things like the gnome-keyring or kwallet keep all the passwords in an encrypted file, they get decrypted and kept in ram using your login password when you log into gnome/KDE session and programs can ask for passwords using some API. Once you log out the passwords are removed from ram and no one can read them. My goal is to have something like this, so I’m never asked for a password, I just log into my session and everything is available
I’n Windows it is not stored in a keyring but instead in the registry. This has basically the same security threat model as a local key file.
The ssh-agent on Linux will do what you want with effectively the same security. The biggest difference being that it doesn’t run as a system service but instead runs in userspace which can make it easier to dump memory. There are some other agent services out there with additional security options but they don’t change the threat model much.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.