toxic icon indicating copy to clipboard operation
toxic copied to clipboard

Don't store state data in $XDG_CONFIG_HOME

Open rpdelaney opened this issue 5 years ago • 2 comments

In general toxic does support the XDG directory specification, but support is not completely implemented. Critically, toxic provides no options that I'm aware of to divide configuration data from state data.

  1. Configurations should be read from "$XDG_CONFIG_HOME/toxic/", then "$XDG_CONFIG_DIRS", then "$HOME/.config/toxic/". This seems to be implemented correctly.
  2. State data such as logs, authentication credentials, DHTnodes.json, and so forth should be read from "$XDG_DATA_HOME/toxic/", then "$HOME/.local/share/toxic/", before resorting to any fallbacks.
    • Identity data (e.g. toxic_profile.tox) should not be stored alongside configuration files since this dangerous deviation from the protocol may cause users to back them up by insecure means to insecure locations.
    • Logs of private chats may also present a security hazard for users.
  3. Any temporary files such as session keys should be stored in "$XDG_CACHE_HOME" (although I wasn't able to find any of these in my "~/.config/toxic" directory).

For emphasis, users who do not expect state data to be stored here may accidentally back it up and synchronize it across systems improperly. Configuration data are fine, but prefer storing state data somewhere in $XDG_DATA_HOME to conform to the freedesktop.org / XDG standard.

Reference: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

$XDG_CONFIG_HOME defines the base directory relative to which user specific
configuration files should be stored. If $XDG_CONFIG_HOME is either not set or
empty, a default equal to $HOME/.config should be used.
$XDG_CONFIG_DIRS defines the preference-ordered set of base directories to
search for configuration files in addition to the $XDG_CONFIG_HOME base
directory. The directories in $XDG_CONFIG_DIRS should be seperated with a
colon ':'.
$XDG_DATA_HOME defines the base directory relative to which user specific data
files should be stored. If $XDG_DATA_HOME is either not set or empty, a default
equal to $HOME/.local/share should be used.

rpdelaney avatar Sep 16 '19 00:09 rpdelaney

There is also DHTnodes.json, the functionality of which I am no completely sure on. It should either go into the new XDG_STATE_HOME or into CACHE, depending on whether it captures any relevant state. Seems a good fit for STATE at first glance.

xeruf avatar Jan 24 '22 14:01 xeruf

XDG_STATE_HOME

Oh my god. They finally did this. I'm so happy.

rpdelaney avatar Jan 24 '22 16:01 rpdelaney

Closing due to inactivity. It works fine the way it is and it's not worth my time to maintain a bunch of backwards compatible code. As far as "dangerous deviations" go, people are responsible for their own data. There's no reason in this day and age for anyone to be backing up anything without encryption, much less without even knowing the contents of said data.

Edit: With that said, if someone else wants to write the code and do a seamless transition without breaking anything, I'll gladly accept the PR.

JFreegman avatar Jan 25 '24 20:01 JFreegman

if someone else wants to write the code and do a seamless transition without breaking anything, I'll gladly accept the PR.

That's all I needed to hear, thanks! :) I'll add it to my personal backlog.

rpdelaney avatar Feb 03 '24 17:02 rpdelaney