Open groupsky opened 9 years ago
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... https://github.com/atom/atom/issues/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:
A few guys on Slacks suggested to use https://github.com/atom/node-keytar
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) :disappointed:
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. Without Atom providing a way to securely storing credentials only accessible by our package, I wouldn't pursue a security model for now.
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 sync.token
in Atom root (~/atom
) where we can store credentials. Thinking about the feature; if in the future we want to support more sources (:bulb: ? ), we could define a namespace with Gist as first release. Something like:
gist:
token: 1234567890
id: 1234567890
Pushing to next milestone.
token can be set in the environment variable GITHUB_TOKEN
and gist id can be set in GIST_ID
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.