fix: remove unessessary executable bits

[donatj]

I was doing a security scan which included our dependencies and I found that your LICENSE had it's executable bit set in our node_modules folder.

They almost certainly shouldn't be. I did a quick

$ find . -type f -exec test -x {} \; -print | grep -v '/\.git/'
./LICENSE
./.gitattributes

I then removed the executable bit from all of these as they are not scripts.

Let me know if you have any questions or comments.

[jonschlinkert]

It seems more likely that the package manager somehow did that. My hunch is that package manager is grouping license files together with files, directories, binaries, etc. defined in package.json. and when they install those files they all get the same directory permissions.

[donatj]

If you look at the diff here, they are executable in the repo currently, and they shouldn't be. I wouldn't have been able to open the PR with no diff.

[donatj]

The diff showing the permission change

[jonschlinkert]

If you look at the diff here, they are executable in the repo currently, and they shouldn't be. I wouldn't have been able to open the PR with no diff.

This is irrelevant to my point.

[donatj]

The executable bit is currently set in the repository on the LICENSE file. Agreed? Can we also agree that it shouldn't be and it should be removed regardless?

The executable bit is set in the published package. I think that's your area of contention, but it is.

Here's a screenshot.

I've tried it on macOS and Linux.

You can try it for yourself, presuming you have access to a non-Windows OS that supports the executable bit.

$ npm pack micromatch
…
$ tar -ztvf micromatch-4.0.5.tgz
…

I don't see any reason to believe that the executable bit in the published package is set for reasons other than the original file being executable.

There would have to be a step that removed it, and then a second step that added it back. Occam's Razor says it's probably just copying the original permissions of the file, given they match.