I had rEFInd and GRUB installed entirely by accident, and a botched update for Arch hosed my entire EFI setup making it impossible to boot Linux or Windows w/o a LiveCD. Thankfully it self repaired once I nuked rEFInd. I ended up going back to Ubuntu, but I hate snaps. I still would recommend Arch for most Linux users who want the power windows.
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.
Also, if I basically remove everything, I will get this error:
`[aapo@aapo-fedora ~]$ amdgpu-install [sudo] password for aapo: ROCm 5.4 repository 154 kB/s | 208 kB 00:01
AMDGPU 5.4 repository 699 B/s | 548 B 00:00
Errors during downloading metadata for repository ‘amdgpu’:
Status code: 404 for repo.radeon.com/amdgpu/5.4/rhel//…/repomd.xml (IP: 13.82.220.49) Error: Failed to download metadata for repo ‘amdgpu’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Ignoring repositories: amdgpu Last metadata expiration check: 0:00:01 ago on Tue 23 Jan 2024 03:47:14 PM EET. Package amdgpu-lib-1:5.4.50400-1510348.el8.x86_64 is already installed. Package amdgpu-dkms-1:5.18.13.50400-1510348.el8.noarch is already installed. Error: Problem: package rocm-hip-runtime-5.4.0.50400-72.el8.x86_64 from rocm requires rocminfo = 1.0.0.50400-72.el8, but none of the providers can be installed
conflicting requests
nothing provides /usr/libexec/platform-python needed by rocminfo-1.0.0.50400-72.el8.x86_64 from rocm (try to add ‘–skip-broken’ to skip uninstallable packages) [aapo@aapo-fedora ~]$ `
Many people have predicted the death of the small, independent window manager with the coming of Wayland. I have heard multiple times that only large projects like GNOME and KDE would be able to take on the burden of making a compositor.
Now, I do think that lots of no longer actively developed window managers could get left behind. But the idea that it will be too complicated to create a window manager now is turning out to be wrong.
First, fewer desktop environments are getting left behind than feared. XFCE, Cinnamon, and MATE all seem to have Wayland plans now.
The big change is the appearance of not one but multiple compositor libraries designed to make it easier to create a window manager for Wayland. Some of them look like they might make it easier than it was under X. The approach taken by this one makes the idea of hacking around with it very inviting.
Although having to create a compositor has made things difficultly until now, I think the idea of decoupling the compositor for Wayland is going to look smart in the long run.
Being separate from Wayland, compositor devs are free to experiment and window manager authors can select the one that best maps to their goals.
I was reading up on Oasis Linux yesterday. It comes with a Wayland compositor ( SWC ) and tiling window manager ( Velox ) that are less than 20,000 lines of code combined!
It would not be practical for a light-weight distro to trim down Xorg like that. But I the compositor is separate, it can be either smaller or feature rich. SWC is XWayland compatible but obviously that is going to add more size if you need it.
Looking forward to the window manager innovation that projects like Louvre enable.
People using X window manage will just keep using them. Wayland doesn’t offer anything valuable to most users so people will just keep using the managers they like. In 10-20 years we will get some nice, new managers that naturally will support Wayland and people will switch because of the features, not because ‘X insecure, Wayland awesome’ BS.
Wayland is already a lot nicer to use over X. Better gestures, better animations, better performance, and that’s if you use Wayland today, not in a year’s time.
Like I get why people are defensive over X but it literally isn’t being developed anymore - And if it’s really worth keeping over Wayland the time to get contributors to support it is passing quickly.
I agree with your overall sentiment with the caveat that 20 years will be closer to 5. Early adopters are enjoying Wayland only benefits today. For example, the Steam Deck just launched with HDR and mainline support for Linux gamers in general will not be far behind.
Also, the list of window managers being left behind is starting to look less appealing than the list of window managers that are Wayland only. Hyperland is probably already more popular than WindowMkaer. As GNOME and KDE go Wayland only, they will continue to add features that regular users will want. I see more announcements for new Wayland compositors than I do for new X window managers.
Another factor that gets missed is that the main dev support for X comes from Red Hat. RHEL9 is already Wayland based. When RHEL8 comes off support in 5 years, Red Hat will abandon X. How long will X stay viable after that?
As the number of X users dwindle, we will see toolkits drop support for X. GTK5 for example. 5 years may be too soon for that but I cannot see it taking 20 years.
Wayland being “valuable to most users” will come faster than you think.
I’ve learned from Brodie’s video that Ubuntu upload schedule is basically slightly different gnome’s schedule. So, KDE with rolling releases is what I think is best.
Though IIRC the scheduling of plasma 6 onward will follow gnome’s 6 month period to synchronize with bimonthly releases of distros that does it.
I asked chatGPT what Wayland is since the article contains no explanation
In this context, “Wayland” refers to a protocol and a display server protocol used in Linux operating systems. It’s an alternative to the more established X Window System (X11). The article highlights that Firefox version 121.0 has integrated support for Wayland by default, indicating that the browser can now utilize Wayland’s capabilities directly on modern Linux desktops without relying on XWayland compatibility layer, thereby enhancing performance and compatibility with the native display server protocol.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.