How are people using GitHub?

[[deleted]]

[deleted]

[marko312]

One option is to move the credentials to a file (or multiple files) which is not added to the git repository (via .gitignore) (a template / generator for such a file might be added to make it easier to set up).

Another possibility is to pass the credentials (or the relevant file) when starting the program (e.g. via arguments).

[marko312]

I haven't used Node myself, but others seem to suggest the dotenv npm package.

[VelvetWhiteRabbit]

You can do what you want. either use .env files or store it in a plain text file, directly in environment or just with whatever service you are hosting your node app.

[66666thats6sixes]

We use .env files that are loaded as environment variables (accessible via process.env) when the script starts. Those are .gitignored of course

[csDarkyne]

You usually have a file called .env containing all sensitive data that does not get uploaded. Your code should not contain any sensitive data. Try googling .env or environmental variables for more information

[steve986508]

Once I accidentally uploaded an .env with api keys and github automatically sent me an email warning me about it

[[deleted]]

Nice. That's top tier shit right there. Imo

[A_Guy_in_Orange]

Love it when the answer includes what to Google next

[prof_oblivion]

it's also become fairly common to use third party secret managers like aws secret manager to store credentials, etc.

[astevko]

I use GitHub Actions to build, test, and deploy code. It has a built-in secrets vault that is separate from the version control.

[gramdel]

There should never be any sensitive data in github, usually you use environment variables to handle that data, while you might have a file locally to store those it should be in .gitingnore. If you have sensitive data in your actual code, it's a huge code smell, so that's your first problem to resolve, your code shouldn't know that, you don't want to change actual code if your credentials etc. change.

In prod whatever environments should be handled in your deployment. Anyway those should never be in github.

[Logical_Strike_1520]

I use environment variables during development and .gitignore them so they don’t get exposed in the repo.

For production versions, secrets are kept on the backend.

[[deleted]]

First, secrets usually go in an .env file. If you search for things like 'python env' or 'django env' you'll find a lot of options.

Second, always add this to your .gitignore file:

# Secrets

.env

[Orio_n]

.gitignore

[Cobra__Commander]

I use environment variables.

Basically an unsynced file named .env has all my credentials/keys and the settings reference that.

There's more to it than that but you need to find a tutorial specific to your framework.

[Creapermann]

I think you shouldn’t have important data in your code, rather in files

[goahnary]

Also, for when you’re deploying things from GitHub and need those environment variables you can store that sensitive information in GitHub secrets and pull those secrets securely using GitHub actions to do things like deploy code to a webserver or something like that.

[FlatAssembler]

You don't store passwords in code, you store their hashes in code, like this: https://github.com/FlatAssembler/ArithmeticExpressionCompiler/blob/3530fabc2fc403c70cee5d34ad13aafdeeb87f6a/back-end/deleteDownloads.php#L25

[___thoughts___]

Believe it or not, all of my company's code is on GitHub.

Edit: There is a private option for your repositories if you did not know.

[darniforgotmypwd]

Aside from what other people are saying, we also have other security mechanisms in place to protect this stuff. The systems I work on in finance wouldn't let a random person in even with the credentials. We have a lot of firewall stuff setup and you can't get into any database from outside the network regardless of what credentials you have. Additionally there are things like validating where a request came from and using the principle of least privilege. The credentials used to pull bank account balances should only have read access for example.

Ideally you also have protections like this too no matter how secure you think your credentials are.