Hacker News Reader

Comment by aidenn0 | Hacker News Reader

FWIW, the OpenSSH devs believe it to be a potential security risk to adopt XDG:

> Adding additional configuration paths is confusing and potentially risky for .ssh as, quite unlike usual "desktop" apps, it grants system access and having its configuration smeared across several possible paths makes managing this more confusing and brittle.[1]

I think this is clearly true for something like ~/.ssh/authorized_keys; it is perhaps less true for ~/.ssh/config and or ~/.ssh/known_hosts which could go in XDG_CONFIG_HOME and XDG_DATA_HOME, but if part of the point of the XDG BDS is to reduce dotfiles in $HOME then it makes less sense to move some, but not all of those files.

1: https://marc.info/?l=openssh-unix-dev&m=170687803731931&w=2

View on HN

I think most people are okay with software such as OpenSSH keeping its long-existing conventions. In the same way I don't think a lot of people mind ".bashrc" being where it is. It's manageable if there's just a few and they're well-known.

However this "exemption" does not and should not apply to anything newer. Things like Cargo, Snap, Steam, Jupyter, Ghidra, Gradle, none of those should be putting their stuff (especially temporary junk) directly and unsegmented into $HOME.

At some point I had more than 50 different dotfiles and dotfolders in my $HOME. It was unwieldy and nasty to look at. I couldn't even figure out what created some of those files because they were so generic.

Plain $HOME as the dumping ground simply does not scale beyond a select few.

    $ find ~ -maxdepth 1 -name '.??*'|wc -l
    435

[edit]

A sampling...

    $ (cd && find . -maxdepth 1 -name '.*'|sort -R|head)
    ./.texlive2023
    ./.stl
    ./.stp
    ./.repo_.gitconfig.json
    ./.xsel.log
    ./.msmtprc
    ./.fonts
    ./.bash_logout
    ./.steampath
    ./.compose-cache

>$HOME as the dumping ground

It's been a while since I used Windows, but I remember the "My Documents" folder being trash pile of configs, save games, data files and whatnot, making it the worst place to actually store your documents.

Windows-oriented developers bring that mess to Macs, too, and it's incredibly aggravating. For over 25 years, Apple has had Documents/Pictures/Movies/Applications/Downloads/etc folders under the user's home folder, and convention is predominantly that you never put non-hidden files or folders in the user's home directory. And you don't put application configuration in Documents, because that's what ~Library is for.

Then ignorant developers who don't care about the platform throw random configuration folders in ~/ or ~/Documents, or think their app needs a central workspace folder for all of its projects, instead of letting you manage your own damn files.

how else will you remember where you stored your 3d objects

I actually use it for 3D objects for my printer. Stays nice and clean compared to My Documents.

It's just plain lazy devs. They do that crap on Windows too despite having conventions for where the stuff goes since Windows 98 (though Photos and Videos folders were introduced with XP, and Game Saves with Vista).

The folder for config is even older. CSIDL_APPDATA has been able to be used to get the path to the AppData folder since the update for Windows 95 that added Internet Explorer 4.0.

> configuration smeared across several possible paths

This does make things confusing, and while it may be inconvenient, it is not a security risk.

I use firejail with most apps and they do not have access to any other files than their own (most of the time).

FWIW, I am completely fine with ~/.ssh and I hope it keeps being ~/.ssh. I prefer SSH-related stuff to be in one place. Same with ~/.gnupg. I do not want to miss anything when I am making backups.

> inconvenient, it is not a security risk

Mmm...not exactly. When security is difficult, the default fix is to turn it off, workaround, etc. Security should be relatively simple.

Increasing the difficulty of correctly configuring additional directories increases the chance something "bad" may happen. As a theorical example, for ssh say that config is not protected the same way keys are (on the file system or by policy). Pair this with some option that, when configured, exposes the contents of the keys.

Increasing the complexity required to secure something makes it inherently less secure.

Okay, that makes sense and I do not disagree.

Here's an example:

Let's say that there are just two possible paths for an authorized_keys file (P1 and P2).

The choices are:

1. Check P1, if it doesn't exist use P2

2. Check P2, if it doesn't exist use P1

3. Merge the contents of P1 and P2 somehow

You need to remove authorization for a key (or certificate); you confirm it has been removed from P1. In both cases #2 and #3 above, you may have failed to actually remove authorization!

Obviously if there are more than 2 possible paths, things get even worse. Also, if you follow XDG to the letter (where things can be redirected by environment variables), there are even more confounding issues, because the environment that sshd sees could be different from the environment that the user sees.

Reply on news.ycombinator.com