Non-executable files set with executable permissions

[mensfeld]

Hey there,

While reviewing the source code of card-mod-bootstrap I've noticed, that several files in the vendor/ directory have executable permissions while not being an executables.

For example:

vendor/bootswatch/docs/3/bower_components/font-awesome/fonts/fontawesome-webfont.woff
vendor/bootswatch/docs/3/bower_components/font-awesome/fonts/fontawesome-webfont.eot
vendor/bootswatch/docs/2/font/fontawesome-webfont.eot
vendor/bootswatch/docs/3/bower_components/font-awesome/fonts/fontawesome-webfont.svg
public/assets/fonts/MaterialIcons-Regular.svg
# and many more...

is that something intended? If so, I would appreciate explanation as I often find it as a bug.

Thank you 🙏

[ethn]

Oh, I think it's fair to call that out as a bug.

I should do a broader sweep and see how many executables we have across the various card mods in this repo. In principle there really shouldn't be many at all.

Thanks for bringing attention to it!

[ethn]

I just made a pull request that removes executables on hundreds of files:
#614

However, the first four you listed above aren't included because they are not actually code that we maintain. Everything in that vendor directory is pulling code from some other git repository, so we don't control the permissions on those files.

Eg the bootswatch dir is pulling from https://github.com/thomaspark/bootswatch.

[mensfeld]

@ethn bootswatch is a gem. Is there a reason to serve it as a vendor data instead of being a dependency?

[ethn]

Good question. I'm not the most familiar with the bootstrap code, but my impression is that because decko's skins let users customize bootswatch skins, there are cases where things could break if the bootswatch gem were updated independently (and eg, their file structure changed in a way that decko wasn't ready for). I'll have a deeper look at some point, because when we are able to use external code as gems rather than submodules, that's generally our preference, but I think the depth of the code integration here made that a bit riskier than usual.

[mensfeld]

Good question. I'm not the most familiar with the bootstrap code, but my impression is that because decko's skins let users customize bootswatch skins, there are cases where things could break if the bootswatch gem were updated independently

Absolutely. That's why you can lock the version to match it exactly to what you expect.

That could be even better than including the vendor for one more reason: if the users would want to use bootswatch separately, not they will end up with a huge conflict. With locking, the resolution would go as expected.

Take your time and thank you for your comprehensive replies :)

[ethn]

That's true, the versioning shouldn't really be an issue, should it? Perhaps the bigger deal is that decko is actually reading in a lot of raw asset files from bootswatch, which is less common. If we did this via gems, we'd have to figure out where the gem is installed. Not impossible, but maybe this was the rationale.

@xithan, is that why we're using submodules for bootswatch?