Why does OpenSSH not conform with XDG_CONFIG? Can there be alternatives?
Why does OpenSSH not conform with XDG_CONFIG? Can there be alternatives?
So the Arch Linux Wiki page you shared actually had a source, but the OpenSSH maintainers hid it because it got brigaded (if I had to guess, by this Hacker News post). Anyways, here’s the latest archive (I also edited the wiki to include it), it’s a BS reason: web.archive.org/web/…/show_bug.cgi?id=2050
Please support FreeDesktop.org XDG basedir specification for openssh
No.
OpenSSH (and it’s ancestor ssh-1.x) have a 17 year history of using ~/.ssh. This location is baked into innumerable users’ brains, millions of happily working configurations and countless tools.
Changing the location of our configuration would require a very strong justification and following a trend of desktop applications (of which OpenSSH is not) is not sufficient.
Please notice that backward compatibility can be preserved by continue to use ~/.ssh if it exits but using/creating XDG dirs if it is not exist.
So tools and users need to hunt in two places for configuration that has security ramifications? That makes it even less palatable…
They are not BS reasons, they are just reasons you don’t like. The OpenBSD team - those behind OpenSSH - are very conservative to the point of being almost reactionary, and that’s great for the kind of software they make. OpenBSD defines itself as “boring”, in a good way.
Coming from a Linux world it may seem weird, as around Linux innovation is praised more than improvement so we end up with a bunch of shiny new software with a lot of growing pains, while BSDs tend to be avantgarde on some technical aspects but at the same time very wary of novelty. OpenBSD in particular takes this to the next level with most of development still happening on CVS and many other quirks that would baffle most Linux users.
To each their own. Personally when it’s security stuff I like it boring. I’ve been using openssh since version 2.x and the muscle memory built 20 years ago is still serving me.
It's not BS. It's correct.
You're proposing an obscene security hole for no benefit.
if they switch it will cause a lot of trouble at first. it’s used everywhere. some management software has .ssh/ hardcoded.
they can’t be automatically backwards compatible, because it would mean an alternate location for a authorized_key file etc, which is dangerous. so, hosts updating need to be checked and migrated. some people will be locked out.
however, after the initial chaos it should be fine.
Because it comes from OpenBSD and OpenBSD doesn’t do xdg stuff.
It also predates the standard.
But you could ask the same of many other Unix utilities too.
XDG = X Desktop Group.
OpenSSH is neither an X client nor a desktop program.
XDG config was always a smooth brain idea, and any other outcome of this experiment was always ~impossible (of course some apps didn’t switch …)
Great job to X “fixing” what didn’t need fixing, and causing us to go from one unified system that made sense, to two. And now people don’t even want to use X anymore
$HOME not a consistent base path?
My “user directories”? You mean you have more than one $HOME with dotfiles in it?
It was never a problem to find user specific app data on unix. And XDG obviously didn’t solve it because solutions that require everyone to change their code are dumb. Case in point, this thread
My “user directories”? You mean you have more than one $HOME with dotfiles in it?
I meant directories under your $HOME.
The problem isn’t that finding files is difficult, but that a lack of specifications leads to inconsistencies and programs doing whatever they want under your home directory.
That worked fine for Unix because programs were designed to be simple. It doesn’t work today where you have programs that constantly save temporary files, caches, and data derived from user input.
Consistency and separation.
If I need to clear out any caches or temporary files, I don’t need to dig around in a bunch of dot-directories to figure out what’s safe to delete and what’s a configuration file. I can wholesale rm -rf ~/.cache.
It’s also convenient for distro hopping or backing up files. If every program kept temporary and transient files in the same base directory, you would need filters for each of them. For anything conforming to XDG base directory specifications, different types of files are all under well-known directories.
More subjectively, I hold the opinion that my home directory is mine. Programs shouldn’t be littering the root of my user folder with their crap (looking at you, ~/go).
All in all, XDG base directories solve a problem that isn’t covered in any other specification. If POSIX defined a similar specification, such as having config files relegated to ~/.local/etc/some-program, I wouldn’t be here.
XDG_CONFIG_HOME because it won't be set at the time it's reading the authorized_keys file. The user's home directory is stored in /etc/passwd but the XDG variables have a million different ways to set them, none of which are truly standardized. Best you could really do is hardcoding .config or the like, which you can do by changing the AuthorizedKeysFile in sshd_config.