101–110 of 117 posts
I got tired of "oops" over time and started abusing environment variables. If you have enough discipline to spend 10 seconds configuring them, you'll never have to worry about magic strings accidentally getting sucked up into source control. The other upside with environment variables is that they work across projects. Set & forget, assuming you memorized the name. Getting at tokens for OpenAI, AWS, GH, etc., is alre…
Last time I tried, the default suggestion was Cloud KMS (yeah), now there's some new secret manager that also looks annoying: https://stackoverflow.com/questions/58371905/how-to-handle-s...
Earlier quoted context omitted.
While I am not suggesting that people should go out and leak their secret keys or push a buffer overflow, the fastest way to learn that you have this problem is by pushing that code to the internet on a project that isn't important. The AWS secret key thing doesn't hold up here, you just really shouldn't do it, but how about an ec2 ssh key or passwords in plaintext? How did I learn about parameterized queries for SQL…
> No amount of internal review and coding standards and etc will catch all of these things. You can only hope that you build the muscle memory to catch most of them, and that muscle memory is forged through being punched in the face Everything you mentioned is security 101, widely known, and can be caught by standard tools. Shrugging that off as a learning experience does not really hold much water in a professional…
The responsibility is on the programmer to learn and remember these things. Period, end of story. Just as smart pointers are a bandaid on a bigger problem with real consequences (memory fragmentation and cache misses), so too is a giga-linter that serves as permanent training wheels for so called programmers.
All devs should run open-source trufflehog as a precommit hook for all repositories on their local system. It’s not a foolproof solution, but it’s a small time investment to get set up and gives me reasonable assurance that I will not accidentally commit a secret. I’m unsure why this is not more widely considered standard practice.
Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.
So the question is: after I orphaned a commit how do I _truly_ make sure it's not visible anywhere on github? Is there no way short of contacting customer support to GC a repo? Shouldn't this just basically be a button on the repo, in the "danger zone" area of the repo maintenance?
For a long time and probably still today, Google AppEngine kinda encouraged storing secrets in the YAML, which is easy to accidentally git-commit. There's no easy way to pass secrets to your services otherwise, unlike Heroku etc where it's always been a single command to put them into envvars on the jobs. Last time I tried, the default suggestion was Cloud KMS (yeah), now there's some new secret manager that also loo…
Earlier quoted context omitted.
Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.
I moved all my precommit hooks to prepush hooks. I don’t need a spellchecker disrupting my headspace when I’m deep into a problem. My developer environments are setup to reproduce CI test locally, but if I need to resort to “CI driven development” I can bypass prepush hooks with —-no-verify.
Pre-commit hooks should be much, much faster than most CI jobs; they should collectively run in less than a second if possible.
For a long time and probably still today, Google AppEngine kinda encouraged storing secrets in the YAML, which is easy to accidentally git-commit. There's no easy way to pass secrets to your services otherwise, unlike Heroku etc where it's always been a single command to put them into envvars on the jobs. Last time I tried, the default suggestion was Cloud KMS (yeah), now there's some new secret manager that also loo…
And can we talk about the predatory pricing model? In AWS one secret service prices a secret for 0.4 dollars a month. I was appalled when I first saw it, are you going to charge me 5$ a year for storing my 12 bytes?
Earlier quoted context omitted.
And can we talk about the predatory pricing model? In AWS one secret service prices a secret for 0.4 dollars a month. I was appalled when I first saw it, are you going to charge me 5$ a year for storing my 12 bytes?
If all you're doing is storing, and not using advanced features like auto rotation, Parameter Store is free for most use cases.
Earlier quoted context omitted.
If all you're doing is storing, and not using advanced features like auto rotation, Parameter Store is free for most use cases.
Ok I may have misread the pricing model, I’ll look into it, thanks!