ship.conf should not be in the repo

[samccone]

it is far too easy for someone to commit ship.conf or accidentally share the file which can compromise the users account.

instead it should be in

~/.ship/REPO_NAME/conf

[hhsnopek]

Only thing I don't like about this idea is that for shared projects, multiple devs will not have the same deployment files. Otherwise I do like this idea, just for s3 keys & other secret passwords.

[notslang]

:thumbsup: on keeping them out of the repo.

Actually, we could make this even better by using a standard password storage mechanism like GNOME Keyring, or Mac OS X Keychain, or the Credentials API for Windows

[samccone]

yep @slang800 that is a nice long term solution, for now I think the simple solution will suite us quite well

[jescalan]

I'm ok with this solution, although I'd also like an option to override if you do have one in your repo. If anyone could help out with this, that would be great, as I have a lot on my plate right now. Otherwise, will get to this eventually!

[jescalan]

Hey @slang800 do you know if there is a node project that provides a cross-platform API to the password storage mechanisms you described above? If so, that would be quite useful I think.

[notslang]

take a gander at https://github.com/atom/node-keytar

[jescalan]

Sweet, this looks great. We do have to store more than one value for a lot of the deployers here, you think we should just serialize it as JSON and store that?

[notslang]

pretty sure you'd only store the passwords/secrets/keys in keytar... the rest of the info on deployment would be fine to make public

[jescalan]

There is sometimes more than value you might want to keep as a secret. You don't always want to leak your username or repo name, s3 has both an access key and secret key, VPS you might not want to leak your user and host names to prevent brute forcing, and who knows what other details might be added in future deployers. I think it would be a short-sighted move to bank on there only ever being one piece of information people might want to keep private.

[notslang]

The issue with putting a JSON object into keytar is that the password store is shared system-wide... so you'd be messing with other applications that only expect a password to be in the password field.

As for S3, I opened an issue over here: https://github.com/atom/node-keytar/issues/14

[jescalan]

I don't think other applications would be grabbing ship's values, would they? It seems pretty unlikely... and if they are they can deal with the JSON, or store their own values.

[notslang]

yeah, that's how keyring works... you put in your password once, and all the apps on your system have access.

[jescalan]

Yeah but we could just use it as a store for ship too, we don't have to care about other apps accessing it

[notslang]

True... We could do that, but it would mean that the user would have to reenter all of their credentials just for ship, which would defeat the purpose of using a system-wide credential manager

[jescalan]

I feel like there's a very decent chance that the user has not entered their credentials for these services into the system-wide manager. On top of that I honestly could care less if they have to enter credentials one additional time. The point of this request is to make sure they are not in the repo, and the alternative (storing them in ~/.ship) requires the same amount of effort.

Unless there is a great solution that works cross platform for storing multiple arbitrary values, it's not worth wasting more time on trying to figure this out, much more important to just implement the feature.

[samccone]

heh yeah... i was not thinking of a global multi app thing, instead just don't put it in the repo so someone does not commit it accidentally

[hnqso]

@jenius @slang800 I'm wondering here. Could we just use NODE_ENV for the username and password? So we could keep the ship.conf in the repo without these details.

[kareniel]

@henriquea +1

[notslang]

@henriquea: we could, and I like the idea, but if it's an environment var, then the user needs to export it every time they open a new session. Or, they'd just end up putting it in their Makefile; which, while better than an application-specific .ship file, suffers from the same problem of being committed to the repo.

You could get around that by setting the var in your .bashrc (or any other startup script for your shell of choice), but I certainly wouldn't recommend putting passwords in there. Your .bashrc is plain-text, readable by everything on your system, and often gets committed to a "dotfile" repo - which makes it a pretty poor place for passwords.

And what's even worse is after that var is exported, it's available to all sub-processes of the shell, which is risky if you have applications that blindly log their environment variables to an external server in the event of a crash or similar scenarios.

So, rather than an environment var, you could use an arg that's only passed to ship (like ship --platform s3 --password 249fa3... or something like that), and rather than putting the password in a plain text file you could store it in a password manager (like pass), passing it to ship with something like ship --platform s3 --password "$(pass s3/username)". Then you could put that whole command into your Makefile & run it with make deploy (or put it in your package.json scripts... whatever works for you).

That solution shifts a bit of the work on to the user, and still lets them store their passwords insecurely if they choose not to use a password manager. However, I like the amount of freedom that it gives. You can even make it work with an environment var if you don't agree with the first 3 paragraphs I wrote (or if you're using it with encrypted vars in travis): ship --platform s3 --password "$YOUR_PASSWORD".

[samccone]

PRs welcome, for anything that makes it harder to ship your password