Please remove that .DS_Store

macOS automatically creates .DS_Store when you open a folder with Finder, the default file manager. The operating system stores some information in binary in this file, for example, the list of files inside the folder.

You cannot read a .DS_Store file just by opening it (binary data), but it's pretty easy to decode. If for some reason, the file gets deployed to a webserver, things can turn nasty:

• it might disclose some information such as the name of some removed files as .DS_Store files are only updated by Finder
• it might also be used to download files recursively from the webserver 🔥

How the heck can you deploy such files on production?

It happens more often than you might think, for example, when you don't ignore .DS_Store files in your project's .gitignore. I see it very frequently, including in public repositories.

The best approach, to me, is to configure it globally on your machine. This way, even if you forget to ignore those files in your particular project, it will be skipped anyway.

The following command will locate your global .gitignore file:

git config --global core.excludesfile  

Open it and verify that .DS_Store files are in the list.

If the ignore file does not exist yet, create a .gitignore file at the root of your home directory and run this:

git config --global core.excludesfile ~/.gitignore

It will set the file as the global ignore file. You can find plenty of templates on the web to get a robust list for various usages.

To list and remove potential existing .DS_Store in your repository:

find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

Be safe.

Comments

[Andrei Dascalu]

I am partially against globally ignoring .DS_Store in your local machine, if you work collaboratively with others. Why?
Because if you ignore DS_Store files in your local globally but others don't, they might still push theirs.
On the other hand, since you ignore those files locally, you will have no idea because changes to them or their presence will be ignored.
You can't enforce ignoring DS_Store in local environments (in a way you can check), but you can make it a thing you look for in every project gitignore.

[Andrei Dascalu]

It's not about replacing. It's about the risk that if you do ignore it locally in a global way, you will not be in a position to notice it clearly if the project doesn't. Which in itself is a risk.

[Andrei Dascalu]

Global configuration only applies to you, not the team. The risk is that it makes you unaware of what the team does because it applies globally but only locally to you, so the result is that you are left unaware that others in the project are free to message with DS_Store.
In a nutshell, it prevents YOU from doing something stupid but it also prevents you from seeing the sign that a project allows others to do something stupid.

[leob]

I think he does have a bit of a point here, so there are pros and cons to doing this, but that doesn't take away from the usefulness of your tip - not to mention raising awareness of the risk of accidentally deploying .DS_Store files on a server - thanks!

[nitpum]

Sorry for my English. I have a example about what @andreidascalu talking about.

My colleague left the company so maintaining his project now become mine. Whatever reason he doesn't ignore .DS_Store in the project's .gitignore. But, I have it ignored globally so I don't know it's not ignored in the project. A week later, a new intern join this project. he doesn't have global ignore like me so he accidentally commit and push .DS_Store to remote

In this example, it's just a .DS_Store what about .env or something that is really important like a key or token. I should notice and fix project's .gitignore on the first day if I don't have globally ignore.

[nitpum]

I think it should be secure both way

1. notice the git incident and prevent it in the first place
2. secure the server

securing the server is only prevents it through to the server but the incident has already happened. the git incident is shouldn't happen in the
first place.

for pull request, we don't notice it until pull request is created. if we don't ignore it globally, it will be noticed faster. also have to clean up the commit, if sensitive files like .env already push to remote for creating pull request.

[nitpum]

The git incident problem will not happen in 2 case

• the project's .gitignore has been set correctly
• everyone set their global gitignore correctly

For me set global gitignore is not scalable. When many people join the project later you need to tell them how to set their global gitignore properly or have some documentation for them. what if they miss config it, even they config it correctly it does not guarantee they will not miss config it later. It is hard to know when and what they miss config in later.

the project's .gitignore is more scalable when more people join the project later you don't need to have some documentation(it's still good to have one) or tell everyone that they need to set global gitignore.

I don't use global gitignore when I join a new project I can notice that the project's .gitignore is missing some config. This make me notice it fast and fixed the config to be correct for the other people. people who join the project later don't even need to set their global gitignore.

If everyone doesn't use global config when the project's .gitignore has something wrong everyone will notice it fast and fix it in no time.
If everyone uses global config it's hard to notice when .gitignore has missed config.

The project's .gitignore is prevent everyone to make a mistake.
The global gitignore is only prevent you to make a mistake but not the other and it makes you hard to know when the project's .gitignore is invalid.

[Yawar Amin]

Ignoring .DS_Store globally on my dev machine is a basic convenience measure. If this is a real worry in the team regarding security, then the team should be using a CI pipeline and running this (and other) security checks during pipeline builds. For example, check that .DS_Store must be mentioned in every project's .gitignore file, fail the build otherwise.

[leob]

Yeah it sounded like a good idea but I've come to realize that what I don't like about it is its "do it once and then forget about it" nature. It's a bit, out of sight, out of mind, which mean that at some point you wouldn't even be aware anymore that you have it. The issue would be "solved" but you'd lose sight of it and not be aware of it.

[Sherry Day]

I suspect many see .DS_Store and have absolutely no idea what it is. Thanks for writing this!

[Nick Frostbutter]

I think it should for sure be removed from git repos. Especially as a Windows user. It is super annoying! Everyone should add it to their .gitignore. No doubt!

[saviorys]

thanks for writing this, I never knew I could remove them LOL