openssh bugs - Dec 2012 - [Bug 2050] New: Support XDG basedir specification

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

            Bug ID: 2050
           Summary: Support XDG basedir specification
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: -current
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: Heintzmann.Eric at free.fr

Please support FreeDesktop.org XDG basedir specification for openssh

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #2 from Eric Heintzmann <Heintzmann.Eric at free.fr> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
So tools and users need to hunt in two places for configuration that
has security ramifications? That makes it even less palatable...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #4 from Eric Heintzmann <Heintzmann.Eric at free.fr> ---
The Freedesktop.org XDG base directory specification have good de facto
adoption.
It has been adopted by:
- GNOME ( https://live.gnome.org/GnomeGoals/XDGConfigFolders )
- GTK+ ( https://bugzilla.gnome.org/show_bug.cgi?id=646631 )
- KDE (
http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy#Freedesktop.org_and_Standard_Directories
)
- QT (
http://harmattan-dev.nokia.com/docs/library/html/qt4/qsettings.html#setPath
)
- XFCE ( http://docs.xfce.org/xfce/xfce4-session/advanced in Files and
Environment Variables )
- LXDE
- Razor-qt
- VLC ( https://trac.videolan.org/vlc/ticket/1267 )
- GStreamer ( https://bugzilla.gnome.org/show_bug.cgi?id=518597 )
- Chrome ( http://code.google.com/p/chromium/issues/detail?id=16976 )
- many more upstream applications
- Ubuntu ( http://brainstorm.ubuntu.com/idea/6557/ &
http://packages.ubuntu.com/fr/source/precise/libxdg-basedir )
- Debian ( http://packages.debian.org/squeeze/libxdg-basedir1 )
- Red Hat
- Fedora
- Suse
- many more distributions

I think that OpenSSH should use same locations than the vast majority
of Desktop environment and applications.


There are real advantages of following this specification :
- a lot less cluttered $HOME
- Make backups a lot more safer and easier.
  Backuping your $XDG_DATA_HOME along with your files is enough 
  (or just excluding $XDG_CACHE_HOME)
- A lot easier to reset a default configuration if you want/need it
  (and without any risk to loose informations).
  Even for the software itself could choose to reset $XDG_CONFIG_HOME
if needed.
- Avoid some strange bugs that happens because you had a old version of 
  some configuration file
- A lot more of flexibility and portability because no path are
hardcoded.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Quintus <quintus.public at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |quintus.public at gmail.com
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #5 from Quintus <quintus.public at gmail.com> ---
My apologies for digging this issue from the grave. Please let me know
if it would be better to file a new report.

A possible solution to this issue could be to add an option (boolean,
like VisualHostKey with ``yes'' and ``no'' as options) to the
system's
ssh_config file.

E. Heintzmann's argument is certainly a valid one. Giving users this
option (even if ``no'' is the default) would be useful and rational.

Desktop applications are not the only applications to make use of
XDG_CONFIG_HOME; judging only by my own server, git, htop, irssi, tmux,
some distributions of vim, and zsh all offer this capability.

The theory behind the option is enumerated well here:
http://stick.gk2.sk/2009/03/the-ugly-duckling-called-xdg_config_home/

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Darren Tucker <dtucker at zip.com.au> ---
sorry, but the answer is "no".  please stop beating this particular
dead horse.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Mihail Mihov <mmihov.personal at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmihov.personal at gmail.com

--- Comment #8 from Mihail Mihov <mmihov.personal at gmail.com> ---
And here is OpenSSH 7 years after the bug got reported and 16 after the
specification came out and OpenSSH still considers itself special. I
love the attitude of no arguments and simply calling the issue a "dead
horse", but maybe you should actually look at the rest of the world and
see that OpenSSH is one of the few who're still refusing to adopt the
specification. Like at least argument yourself. Even if you don't want
to change the default you could easily make it an option in the global
config with it defaulting to no (like how E. Heintzmann suggested). But
just so you know your software being old isn't the issue here, it's
that the people behind it see themselves and their software as somehow
a special snowflake. Just think about it.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Drew DeVault <sir at cmpwn.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sir at cmpwn.com

--- Comment #9 from Drew DeVault <sir at cmpwn.com> ---
It's about time you stopped dying on this hill, guys.

Here's what would happen if SSH introduced XDG base directory support:
nothing whatsoever, because everyone's ~/.ssh would still be there and
would be picked up as the fallback directory. Tools which provision new
systems by dumping keys into ~/.ssh would continue to work.

What might break is someone deciding to move their SSH directory, at
which point they are perpared for their scripts to break because
they've made the change themselves.

Third-party SSH tools will quickly update, likely within a year, to
support XDG base dirs as well. Give it 2 years to be safe, then update
the default behavior. Hell, read the env from SSH_XDG_* for a start, so
people have to opt-in to making SSH do the right thing.

25 years of using ~/.ssh doesn't make it right, it just makes it
egregiously wrong.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Rhys Perry <rhysperry111 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rhysperry111 at gmail.com

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Vladimir Porotnikov <zerdox.cool4 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zerdox.cool4 at gmail.com

--- Comment #10 from Vladimir Porotnikov <zerdox.cool4 at gmail.com> ---
Just give me opportunity to override this path. I know what I'm doing,
if something goes wrong, I know that it is happened because I changed
default path. You don't need to migrate all users from ~/.ssh, just
give opportunity, it isn't as hard.

I am sick and tired of trash data in my home directory.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

beatlink+mindrotbugzilla at simplelogin.co changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |beatlink+mindrotbugzilla at si
                   |                            |mplelogin.co
             Status|CLOSED                      |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #11 from beatlink+mindrotbugzilla at simplelogin.co ---
It is not even about having dotfiles cluttering the home folder,
although that is a good reason. Its about interoperability. The more
tools like ssh refuse to cooperate with the established standards, the
more other tools that depend on these have to build in exceptions for
these misbehaving tools and the more complex and difficult to maintain
the linux ecosystem becomes. 

XDG folders are there, and they're established and widely supported.
There are no technical limitations preventing the migration. As
mentioned before fallback checking can be used to maintain backwards
compatibility and prevent breaking changes. 

Refusing this change because "tools may break" and "developers
will
have to learn the new path" is the worst excuse you could possibly use.
One of the first things you learn in programming class is to never hard
code paths. Keep things flexible and configurable and you make software
simpler and easy to maintain. The data path for ssh should have been
set to a variable from Day 1.

This is a non issue. SSH should use the XDG desktop spec, and to this
day, I don't see a single decent reason as to why that should not be
the case.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Drew DeVault <sir at cmpwn.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #12 from Drew DeVault <sir at cmpwn.com> ---
Typical BSD, refusing to play with others, shoving your thumbs in your
ears and singing lalala until the pesky users go away.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #13 from Damien Miller <djm at mindrot.org> ---
Spam-reopening this bug and making personal insults isn't going to help
your case.

We have already stated our rationale and no convincing evidence or
argument has been brought to this bug that changes out minds. To
restate our reasons:

 * OpenSSH's use of ~/.ssh predates the XDG specification by some years
 * OpenSSH is not desktop software to begin with anyway.
 * Many third-party tools, scripts and habits depend on this location.
 * OpenSSH is security software and scattering important configuration
across multiple-directories can yield unpleasant surprises

But hey, if you want to avoid ~/.ssh then you mostly can via
configuration. 

You can have ssh look for its config in a different place by putting a
line in /etc/ssh/ssh_config and override the locations for other
commonly-used files too:

Include ~/.config/local/ssh/config
UserKnownHostsFile ~/.config/local/ssh/known_hosts
IdentityFile ~/.config/local/ssh/id_ed25519

etc.

sshd can be taken care of using something in /etc/sshd_config like:

AuthorizedKeysFile ~/.config/local/ssh/authorized_keys

(I make no promise that this is all the configuration that you need
touch)

Alternately, if you're willing to recompile then it's a single line
change to make OpenSSH look in a different location for user configs:

pathnames.h:#define _PATH_SSH_USER_DIR          ".ssh"

A benefit of OpenSSH being open-source is that you're not constrained
by our decision - you're more than welcome to change this on your
systems if you prefer.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

Drew DeVault <sir at cmpwn.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #14 from Drew DeVault <sir at cmpwn.com> ---
(In reply to Damien Miller from comment #13)
> Spam-reopening this bug and making personal insults isn't going to
> help your case.
It's been twelve years and users still demand this feature. What else
do you expect?
>  * OpenSSH's use of ~/.ssh predates the XDG specification by some
> years
What of it? OpenSSH predates heaps of things that it ended up
including.
>  * OpenSSH is not desktop software to begin with anyway.
What of it? Plenty of non-desktop tools obey XDG basedirs. And SSH
*does* have X11 support!
>  * Many third-party tools, scripts and habits depend on this
> location.
What of it? They would still work. No one is telling SSH to stop
reading ~/.ssh.
>  * OpenSSH is security software and scattering important
> configuration across multiple-directories can yield unpleasant
> surprises
Like what?

You're pulling answers out of a hat, and haven't provided a good
rationale for any of them, for over a decade. Your excuses are
incredibly thin, and seem to only be here to retroactively justify
inaction. Will you knock it off already?

I'm reopening this, again, not because I am creating spam in doing so,
but because I am correcting a wrong. You are *in the wrong*. It's time
you admit it and stop defending your ego by using thin excuses to
justify bad behavior.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #15 from Dmitry V. Levin <ldv at altlinux.org> ---
Adding support for an extra place where to look for security sensitive
information would introduce a major security risk, therefore openssh
should not change its default behavior in this respect.  If it ever
changed, we downstream maintainers would certainly patch it out.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #16 from Drew DeVault <sir at cmpwn.com> ---
(In reply to Dmitry V. Levin from comment #15)
> Adding support for an extra place where to look for security
> sensitive information would introduce a major security risk,
> therefore openssh should not change its default behavior in this
> respect.  If it ever changed, we downstream maintainers would
> certainly patch it out.
And how exactly does it pose a major security risk? Can you be more
specific than these sweeping generalizations? The key files are still
mode 600 regardless of where they're put.

We can't go outside, because of the bears. What bears? Don't ask, just
lock the door.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #17 from Dmitry V. Levin <ldv at altlinux.org> ---
(In reply to Drew DeVault from comment #16)
> (In reply to Dmitry V. Levin from comment #15)
> > Adding support for an extra place where to look for security
> > sensitive information would introduce a major security risk,
> > therefore openssh should not change its default behavior in this
> > respect.  If it ever changed, we downstream maintainers would
> > certainly patch it out.
> 
> And how exactly does it pose a major security risk?
The risk is that sensitive data would be accessed from a less secure
location than ~/.ssh/.  I saw setups where ~/ and ~/.ssh/ directories
were out of user control, these setups would break.

You're talking about defaults, they shouldn't change this way.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2050

--- Comment #18 from Drew DeVault <sir at cmpwn.com> ---
(In reply to Dmitry V. Levin from comment #17)
> The risk is that sensitive data would be accessed from a less secure
> location than ~/.ssh/.  I saw setups where ~/ and ~/.ssh/
> directories were out of user control, these setups would break.
> 
> You're talking about defaults, they shouldn't change this way.
But how does that happen? This is entirely hypothetical. No one is
asking ssh-keygen to stop setting keys to 600. If you saw setups where
~/.ssh is "out of user control", causing things to break, what makes
that any different from if ~/.config/ssh/ is "out of user control"?

If you really, desperately don't want to change the defaults (something
which has led to actual security problems in SSH, by the way, like
generating less-secure RSA keys by default), then alternatives like
SSH_XDG_* have been proposed as an incremental stepping stone.

If you have arguments to make, *make* them, rather than just alluding
to their approximate shape and making vague generalizations.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.