←back to thread

199 points elza_1111 | 2 comments | | HN request time: 0.01s | source
Show context
UnreachableCode ◴[] No.44452675[source]
What I've never understood is, how is this an issue with private repos? Aside from open source projects I can't see the problem with accidentally doing this, even though it is a smell.
replies(5): >>44452714 #>>44452733 #>>44452828 #>>44453249 #>>44453819 #
cess11 ◴[] No.44452714[source]
It's called private but actually shared with a very large corporation you don't control, likely running on infrastructure they don't control. Due to the CLOUD Act it's also shared with the US government.
replies(2): >>44452908 #>>44452931 #
bapak ◴[] No.44452908[source]
Secrets gotta live somewhere. Are you supplying them every time you deploy or run CI?
replies(3): >>44453051 #>>44453088 #>>44455627 #
larntz ◴[] No.44453051[source]
Yes. Either via a secret manager (eg vault) or configured as repo secrets if that kind of infra isn't available.

https://docs.github.com/en/actions/how-tos/security-for-gith...

Never commit secrets for any reason.

replies(1): >>44454878 #
1. bapak ◴[] No.44454878[source]
Repo secrets are just stored on someone's computer and they obviously have the keys. This is what I mean.

Same for your vault. The vault might be encrypted, but at some point you have to give the keys to the vault.

Your secrets are not safe from someone if someone needs them to run your code.

replies(1): >>44455297 #
2. larntz ◴[] No.44455297[source]
> Your secrets are not safe from someone if someone needs them to run your code.

This is true. I don't disagree with that or you're assessment of repo secrets.

My comment was in the context of the grandparent committing secrets to a private repo which is a bad practice (regardless of visibility). You could do that for tests, sure (I would suggestion creating random secrets for each test when you can), but then you're creating a bad habit. If you can't use random secrets for tests repo secrets would be acceptable, but I wouldn't use them beyond that.

For CI and deploys I would opt for some kind of secret manager. CI can be run on your own infrastructure, secret managers can be run on your own infrastructure, etc...

But somewhere in the stack secret(s) will be exposed to _someone_.