Public Service Announcement.<p>While for the other secrets, I’ve got nothing, there is never a reason to have AWS secret keys in your code or in application specific configuration files.<p>Every AWS SDK will automatically read your keys from your config file in your home directory locally. Just run<p><pre><code> aws configure
</code></pre>
When you run your code on EC2, Lambda or ECS, the same SDK’s will automatically get the keys associated with the attached role.
This would be solved if python used an (OS-specific) cache directory for its .pyc files. I have always disliked .pyc files... here's a concrete reason!<p>Question: what does python do if it doesn't have write permission in the current working directory? Not write the cache?
Highly recommend "export PYTHONDONTWRITEBYTECODE=1" in your bashrc and just forget about it. Pyc files are still an important optimization on modern machines in some circumstances (especially with huge oft-restarted apps), but the autogeneration behaviour has always been a pain in the ass<p>The bulk of your pycs are generated during package install. What tends to remain in the usual case is a handful of files representing app code or similar.
Just reading the script from TFA, it attempts to find secrets.pyc and decompile it, but doesn't even check if secrets.py is also in the repo. A glance at search results (I just used GitHub's web interface, didn't bother to run the code) tells me when secrets.pyc is committed, secrets.py comes with it at least the vast majority of time.<p>I guess the author did find cases where secrets.pyc is committed but secrets.py is not? It's hard to fathom how that could have happened (especially inside "organization" settings). Sounds like the result of absolute rookies in both Python and git following a tutorial with a step "add secrets.py to .gitignore" but unfortunately takes ignoring __pycache__ and ﹡.pyc for granted, which is too much to ask for some people.<p>> it is very easy for an experienced programmer to accidentally commit their secrets<p>No, it doesn't take an experienced programmer to put __pycache__ and ﹡.pyc to global ignore, or use a gitignore boilerplate at project creation, or notice random unwanted files during code review.
Another possible place to look for secrets is in public docker images. Bots are scanning github repos for secrets all the time, but what about dockerhub (and other docker images repositories)? I accidentally leaved a secret on my public docker image once and that's made me quite paranoid about it now.
I read "Finding secrets by decompiling Python bytecode in public restrooms" by accident. It never occured to me that anyone would do THAT in there.