There’s quite a lot of programs that make use of XDG_CONFIG, with the default set to .config in most distros. However, there’s also quite a few programs that have rejected this, sticking with a format that is not XDG-conforming.
One such example is OpenSSH, as can be seen in the following page - it makes use of the ~/.ssh directory. Why is that OpenSSH does not conform to this specification? Are there any security vulnerabilities? If so, then shouldn’t there be another specification by Freedesktop.org, which allots a secure directory for the same?
ssh predates the specification, exists somewhat independently of even the idea of a desktop (not common to see xdg env variables like XDG_CONFIG in a headless environment, for example), and uses the homedir/.ssh directory on both the client and server side of a connection. I think it’s less to do with security and more to do with uniformity for something as important as ssh - ssh doesn’t need to change to use the xdg spec, and xdg doesn’t need to allot anything special for ssh when it’s already uniform across the unix spectrum
XDG = X Desktop Group.
OpenSSH is neither an X client nor a desktop program.
More specifically, XDG is more related to Linux. It was the name of the freedesktop group. OpenSSH is more related to OpenBSD. However, none of that is strictly true - freedesktop/XDG isn’t just about desktop, XDG directories are not completely neglected by OpenBSD and OpenSSH isn’t used by just OpenBSD. dotfiles sprawling is a common problem - so OpenSSH should probably follow it as well.
OpenSSH’s server login component (the authorized_keys checking) can’t properly respect
XDG_CONFIG_HOMEbecause 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.configor the like, which you can do by changing theAuthorizedKeysFileinsshd_config.Other than declutter and conformity (which are good goals in general) what else are you getting here? What would you be able to do tomorrow if they suddenly supported XDG_CONFIG that the general population would benefit from?
Honestly, I do not have any strong points, because XDG makes the home directory look clean, but I imagine alternative SSH libraries offer this freedom of choice? Maybe the Guille-SSH? But then again, it’s just one extra folder on my personal device, so I don’t really have a lot of complaints, and I don’t really want to use a project that is not tried and tested, at least for now.
deleted by creator
Well yes, after breaking countless tools with repercussions possibly in the decade range, punching security holes in systems that were hardened with certain expectations (my head aches at the amount of “lol the admin didn’t restrict .config/ssh”) - after all this havoc we will have a native bsd server software that finally complies with a Linux desktop standard. I don’t see downsides to this.
deleted by creator
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.
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: https://web.archive.org/web/20190925004614/https://bugzilla.mindrot.org/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.
Edit: just to be clear, for ssh Linux is a second class citizen. On our distros we run a special (less secure) “portable” version of ssh that they release for us poor peasants. OpenSSH is an OpenBSD tool first, everything else after.
It’s not BS. It’s correct.
You’re proposing an obscene security hole for no benefit.
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 Desktop Group “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
Having a consistent base directory specification is a “smooth brain idea”? Alright, buddy, enjoy your config and cache files scattered around your user directories.
is
$HOMEnot 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.
You used to have to do all that stuff before too. Vim has had history, settings, caching, and plugins for ever. And it all used to sit in ~/.vim. Now it’s in ~/.config/vim. What’s the difference?
