Having been through open sourcing an app platform repo (https://github.com/documentcloud/documentcloud ) that wasn't explicitly created w/ open sourcing in mind, moot has my deepest sympathies.
Moot left out the most sensible response to Mistake #5:
I went through a rushed 8hr rebase to remove all of our keys, certificates, cookie secrets and the like before DocumentCloud's platform was opened. Two days after, a friend asked me why I hadn't simply revoked and replaced all of our secrets to the sound of me facepalming repeatedly.
It is always much easier just to revoke and replace your secrets. Doing so should always be relatively easy for you to execute, and having a chance to practice that is also always good.
Good point -- frankly I'd suggest doing both (clean repo and revoke/replace the secrets). The developer in question simply overlooked the issue, and since we were busy spinning down the company, nobody else caught it.
I would scrub the repo anyways because revoked secrets can still be used for social engineering. "Hey $HOST, I got hacked. My old password was $PASSWD and you can be sure it's me because $PUBLIC_INFORMATION. Can you send a password reset to $ATTACKER_EMAIL?"
Its a very good point that if you are not able to easily revert and change all your secrets and key's then you are in more trouble than just removing them from the commit log.
Moot left out the most sensible response to Mistake #5:
I went through a rushed 8hr rebase to remove all of our keys, certificates, cookie secrets and the like before DocumentCloud's platform was opened. Two days after, a friend asked me why I hadn't simply revoked and replaced all of our secrets to the sound of me facepalming repeatedly.
It is always much easier just to revoke and replace your secrets. Doing so should always be relatively easy for you to execute, and having a chance to practice that is also always good.