Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile for Linux #78

Open
hoop33 opened this issue Oct 10, 2013 · 4 comments
Open

Compile for Linux #78

hoop33 opened this issue Oct 10, 2013 · 4 comments

Comments

@hoop33
Copy link
Owner

hoop33 commented Oct 10, 2013

Off the top of my head, the only issues should be:

  1. SSKeychain. Where should Linux version store keys/tokens?
  2. Settings. Save to .wry instead of wry.plist (or com.grailbox.wry.plist)?
@jeremy-w
Copy link
Contributor

Gnome has a keyring IIRC. I think I've seen Python modules that will use that to store keys under Linux, or OS X keychain if on OS X.

Ah, I think I was thinking of keyring:

What is Python keyring lib?

The Python keyring lib provides a easy way to access the system keyring service from python. It can be used in any application that needs safe password storage.

The keyring services supported by the Python keyring lib:

  • OSXKeychain: supports the Keychain service in Mac OS X.
  • KDEKWallet: supports the KDE's Kwallet service.
  • GnomeKeyring: for Gnome 2 environment.
  • SecretServiceKeyring: for newer GNOME and KDE environments.

Besides these native password storing services provided by operating systems. Python keyring lib also provides following build-in keyrings.

  • Win32CryptoKeyring: for Windows 2k+.
  • CryptedFileKeyring: a command line interface keyring base on PyCrypto.
  • UncryptedFileKeyring: a keyring which leaves passwords directly in file.

You should be able to put a wry.plist in $XDG_CONFIG/wry/wry.plist. See http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html. So just the path needs to change, I think.

@parkr
Copy link
Contributor

parkr commented Oct 10, 2013

The typical way tokens have been stored that I've observed is via ~/.wryrc dotfiles. We authorize entirely in the command-line then it writes the token and any other auth into to that home dir dotfile.

@jeremy-w
Copy link
Contributor

@parkr The XDG_CONFIG thing is intended to solve the dot-file explosion problem in the home directory. It's also very convenient when you want to make your dotfiles a separate git repository, since you just need to symlink the .config directory into place and all its children follow.

@parkr
Copy link
Contributor

parkr commented Oct 10, 2013

I definitely don't think including dotfiles with tokens should be subject to version control – ideally, you'd have a different token per machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants