search

sveale / remote-edit

remote-edit
MIT License
146 stars 55 forks source link

Support for .netrc files #134

Closed mexisme closed 8 years ago

mexisme commented 8 years ago

I'd like to suggest support for .netrc files, instead of in .atom configs, as this is a fairly common password-storage format, and is also more cross-platform, e.g:

https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html https://atom.io/packages/heroku-tools

Obviously, this is still much less secure than tools like Keychain, Gnome Keyring or KDE Password Wallet.

sveale commented 8 years ago

Tools like Keychain, Gnome Keyring and Credential vault is supported on most platforms through node-keytar, and can be used for saving passwords and passphrases by enabling it in the settings. Since it doesn't work on all systems, it's turned off by default. All serializing of host info is done using constructs provided by atom.io, so the cross-platform support is quite good.

I don't really see the upside of adding support for .netrc files, unless of course some user already have a bunch of these files and want to avoid adding the hosts using the dialog in remote-edit. I'd be more than happy to look at a pull request, but will not add support for .netrc files myself.

mexisme commented 8 years ago

The main idea was for supporting a more-common/well-supported config file for storing passwords, rather than storing those things in atom config files.

Two thoughts led me to .netrc:

I wasn't very-aware of node-keytar, and thanks for pointing it out. And even though .netrc is not really very secure, it sounds like it might be a better place to support it, anyway.

Happy to let this one go, until I have time to write a PR (for this, or node-keytar!)

sveale commented 8 years ago

I get your point, but it seems you've misunderstood a few things:

  1. All the information regarding remote-edit is stored in remoteEdit.json. This isn't an atom configuration file, although it is stored in the atom directory. In the same directory atom stores all installed packages, so it's maybe not optimal to have this dir as a shared directory. Either way, you can change the location of the RemoteEdit.json file to wherever you want in the remote edit settings The only info that might leak then would be serialized editors - ie if you open a remote file and then close atom, the state of that file, including remote info, could be serialized inside the atom directory, another reason why this shouldn't be a include-all shared directory.
  2. Support for node-keytar is already present :-). You can activate it in the settings panel.

Please don't take this as discouragement - I'd gladly accept a PR for netrc support as long as it wouldn't diminish the functionality provided by the current solution :-)

---- mexisme skrev ----

The main idea was for supporting a more-common/well-supported config file for storing passwords, rather than storing those things in atom config files.

Two thoughts led me to .netrc:

I would like to store my atom config in a "shared space" (e.g. GH gists or a public git repo) but can't do that if I can't be 100% certain there's nothing sensitive in them (e.g. passwords) and I'm not keen on digging through to find the bad citizens... especially if the format is up for redesign at some point in the future! .netrc is astonishingly common, e.g. supported by things like Heroku, Ruby gems, large numbers of Unix tools.

I wasn't very-aware of node-keytar, and thanks for pointing it out. And even though .netrc is not really very secure, it sounds like it might be a better place to support it, anyway.

Happy to let this one go, until I have time to write a PR (for this, or node-keytar!)

— Reply to this email directly or view it on GitHub.

mexisme commented 8 years ago

No problem, was mostly sharing my thinking, so that you could disabuse me of any terrible notions. Like I implied, it sounds like this sort-of thing is better handled via some common/shareable thing like node-keytar.