Any competent engineer hasn't?

Is that even at the competent level? You need to be particularly special to actually "accidentally" leak the .ssh dir via GitHub. Even incompetent people wouldn't fail to that degree for the most part.

Leaking the directory through other avenues is a different matter though. Almost all package managers provide post install and compile scripts. Hence doing (as an example) "npm install" can potentially leak it. That's something not many people actually pay attention to (you would have to basically jail every command, which sadly isn't the norm today)

How would you accidentally leak your .ssh dir on Github?

People with workflows like `git add .; git commit -m 'fix'` can push wondrous things to public repos.

Only if you're raw dogging git from your home directory...

You would have to have a git repo in .ssh or higher up the tree for that to work. Otherwise you’d get one of the “directory is not a repo” messages.

It isn't that uncommon to sync a home dir with git: https://askubuntu.com/questions/1316229/is-it-bad-practice-t...

I'd guess that most of us wouldn't do it by just "git init" in the home directory. There are many safer ways than that.

But we were all newbs once, and often even the newbs have access to various keys and credentials.

It was just an example. It used to be fairly common for people to sync some of their dotfiles via git, and from time to time someone would leak a directory that contained sensitive data without them realizing it. I'd guess things like tokens used by cli tools were more common than whole .ssh directories, but I'm sure both happened.

Not quite the same thing, but also a leak: https://blog.gitguardian.com/github-exposed-private-ssh-key/

I guess all these folks saying professionals would never make a mistake like this will also have insulting names for github engineers. :shrug

I only use private repos, so that when my .ssh and .env leaks the public doesn’t see it. Probably. Maybe. Well…

Git implemented a `.gitignore` file for this exact purpose. One of the first things to do when you create a new repo is to customize if for the language + OS.

And .env is implemented for this exact purpose too, hand-in-hand with .gitignore ;)

But mistakes happen all the item. It's very easy to fat-finger a line in .gitignore - one char off and you're toast.

Just remember to go through your commit history if you ever plan on making that repo public.

I commonly flatten repos (by copy and create) when I share them. Its rare that the other person needs the commit history.

I have often thought it would be nice to have a good tool to retroactively view and tidy them, but everything I've seen has not quite hit the nail on the head.

I use the Pieter Levels commit history strategy of all my commit messages being the single word "commit"

https://x.com/levelsio/status/1590908364393156608

I have not.

And at a certain level of criticality, you do not do this at all

You have security measures in place to prevent this.

Not that the ketaman cares about it.