-
Notifications
You must be signed in to change notification settings - Fork 105
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
Secure token value #98
Comments
I looked the other day at another package called gist, which uses another file for storing the GitHub Gist token. I prefer to see Atom supplying use with a more secure option... atom/atom#1763 |
A few guys on Slacks suggested to use https://github.com/atom/node-keytar |
This sounds interesting. And still will require a dedicated UI for managing the token. IMHO this will be tied with #100 |
@jerone commented on 27 jul. 2015 19:05 CEST:
Hmm just tried installing it at work (Windows 8.1) but fails to install. Will try tonight at home. |
So at home it won't install either (Windows 7) 😞 It seems the package was used by Atom at one point but dropped with no replacement. Gives me a bad taste. Continuing search for another solution... |
So I've been thinking about this... We can't fix this with a good security model. Problem is that everything we do, other packages can read or write too. Besides that, everything is accessible through the developer tools. This makes providing a real secure model not possible. Encrypting the tokens doesn't really makes sense and is easily reverse-engineered. Going back to the original issue of not exposing the token when creating automatic error messages on GitHub through Atom error notifications, I think that moving the token credentials to another location/file would be the best solution. I propose we make an CSON file called gist:
token: 1234567890
id: 1234567890 Pushing to next milestone. |
token can be set in the environment variable We should probably show that on the settings page |
Currently bug reports generated from atom contain the token and gist repo. There should be some form of protection of the token so bug reports don't expose it. Additionally it would be preferable if other plugins don't have access to the token.
One way is to generate a random key and encrypt the token with that, the key itself could be stored as a plugin state - which I haven't investigated how secure is.
Another way is to store it in another location like custom config file in atom's config directory.
So far both approaches require building a custom UI to manage the token.
The text was updated successfully, but these errors were encountered: