41–50 of 266 posts
If you found a similar mistake in your repository, you can delete commit from history using: `git rebase --onto ^ `. Or if you want actually rewrite it, see git rebase -i` documentation.
If the keys/passwords are already pushed to GitHub or other public hostin, they should also be revoked.
If you found a similar mistake in your repository, you can delete commit from history using: `git rebase --onto ^ `. Or if you want actually rewrite it, see git rebase -i` documentation.
A single person who checked out your repo before the force push will still have the credentials. Once this has been pushed to a public repo, assume that the credentials are burned and revoke them.
Earlier quoted context omitted.
A single person who checked out your repo before the force push will still have the credentials. Once this has been pushed to a public repo, assume that the credentials are burned and revoke them.
Indeed; but these actions complement each other.
How do you guys, handle this problem? I use either `git-crypt` [1] or `ansible-vault` [2]. 1: https://github.com/AGWA/git-crypt 2: http://docs.ansible.com/ansible/playbooks_vault.html
Earlier quoted context omitted.
It is customer fault. However it should be pretty easy for them to set up a script to search github for this kind of stuff and automatically invalidate keys
And this would be a cool feature from github too. A link mentioning "we found something in your code that looks like a secret, please know people will use it."
Annoyingly there is no way to turn it off even when you explicitly want to share an API key knowingly. But i'm more than fine with needing to "obfuscate" an API key or manage secrets correctly knowing it saves TONS of people.
This is a good example of the increased risks from doing your development out in the open, any mistakes are exposed to a much wider group of potential adversaries. On an internal VCS, this would still be a problem, but a bit less visible/exploitable...
On an internal VCS this may be a deliberate decision: Secrets need to be stored somewhere and a cost-risk analysis can result in "this is the best place that we currently have at our disposal". That obviously won't fly if your threat model includes "adversary may attack our github account from within GH" or if you ever plan on opening up that repo, but if neither applies this may be the best place to store some sorts…
How do you guys, handle this problem? I use either `git-crypt` [1] or `ansible-vault` [2]. 1: https://github.com/AGWA/git-crypt 2: http://docs.ansible.com/ansible/playbooks_vault.html
This is a good example of the increased risks from doing your development out in the open, any mistakes are exposed to a much wider group of potential adversaries. On an internal VCS, this would still be a problem, but a bit less visible/exploitable...
On an internal VCS this may be a deliberate decision: Secrets need to be stored somewhere and a cost-risk analysis can result in "this is the best place that we currently have at our disposal". That obviously won't fly if your threat model includes "adversary may attack our github account from within GH" or if you ever plan on opening up that repo, but if neither applies this may be the best place to store some sorts…
That said I'd say putting secrets in a git repo is a pretty risky thing to do. By the nature of the tool that means that the secret ends up on the device(s) of every developer who checks out the codebase, so the security of the secrets is equal to the security of the worst secured device in question.