31–40 of 45 posts
Do NOT do this. Anyone who gains access to the repo, gains access to all environments. I repeat, DO NOT DO THIS!!!! Do not deploy from your terminal. Do use CI/CD and do use environment variables and secrets to provide those keys from a secure location. DO NOT STORE THEM IN .git!!! All it takes is one dependency to ruin your day. npm install at your own risk then and wait for the breach…
Earlier quoted context omitted.
I guess this is why > This setup is localized to that repo and is entirely self-contained, i.e. you can move the repo to a different path or place it on a thumb drive to a different machine and it will work without reconfiguring.
I mean I saw that, but I just can't imagine this is thing that you are honestly doing that much... But also: > you can move the repo to a different path Pretty sure this alone is a non issue. > place it on a thumb drive to a different machine and it will work without reconfiguring. I go back to this being terrible security. If you loose that drive someone now has your key and the ability to figure out where that key…
Not just the ability to figure it out, but the config is set to use it automatically, so you could easily figure this out on accident.
Is this the kind of security vulnerabilities we'll be seeing as vibe coding and AI slop takes the reins?
So I have never actually tried, but could you not just have multiple SSH keys in your .ssh folder and run the same command in the article telling git specifically which one to use instead of one within the git directory? That seems like it would fix the issue here without introducing a major security issue. To be blunt... If I was security at a company and found out someone was doing this, I would question why they h…
You don't even need to do that. You can just put each set of repos in a directory on a per-account basis and set up git-configs for each. The top of my `.gitconfig` looks like [includeIf "gitdir:~/Work/"] path = .gitconfig_work [includeIf "gitdir:~/OpenSource/"] path = .gitconfig_opensource where `Work` is where all of our repos associated with our GitHub EMU go and `OpenSource` is where I clone all of the open sourc…
If the bad intent actor has access to the source code they still need to have access to push to the remote repo to issue a deployment.
If they have access to the remote repo they would then have full access to the deployment, I am not certain this is avoidable if one can edit code, push, and have the pipeline deploy as desired.
Car analogy? Key fob in the car in a locked garage. If you have access to the garage you can steal the car. Secure 'enough' for most people because the intrusion happened prior to the deploy.
I di the exact opposite and only use ssh keys store in secure enclaves. Each device has their own key I have no access to. Not sure what the author does but I have three devices and keep them for many years. Adding a new ssh key to servers every few years isn’t that bad.
I just use -sk variants with a FIDO authenticator. Being able to port the keys to another trusted machine (i.e. replacing a computer) if I need to is nice. And it's as secure as a secure enclave. I do prefer to use a unique key for every (local, remote) pair though. It makes revocation more straightforward.
I feel a bit skeeved out about the standard practice of just letting keys hang free and loose in ~/.ssh/ as it is already (leveraging e.g. Secure Enclave on Macs is much better IMO), let alone putting them in a place where they're liable to be unintentionally uploaded or freely accessible to anybody who happens to come into possession of my thumb drive.
I've moved to storing my keys in my password manager, using it as an ssh agent. Means clicking authorize a bit, but also means I'm running a command I'm expecting to use a key then being prompted to authorize (and if it ever prompts unexpectedly I can stop and ask why) Hardware keys would be better, but I think this is a decent balance or security vs convenience for my needs ATM.
Also make sure to put in your user password in a plaintext file in the repo for ease of automation. Add your SSN in case the usb gets lost. A face scan of a blank check could prove useful for future bills.