Don't read symlinks in site.include in safe mode

[ashmaroli]

• This is a ⚠️ security fix.

Summary

As a result of #7188, any entry in site.include that points to a file within the source_dir is read-in during a build. That created a security issue where an entry referring to a symlink is read-in even if it points to an entity outside the source_dir.

This PR attempts to resolve that by mirroring EntryFilter#symlink? without creating a new EntryFilter instance.

[mattr-]

Why is the filtering here and not in EntryFilter?

[ashmaroli]

Why is the filtering here and not in EntryFilter?

I didn't want to create a new EntryFilter instance to do something possible with just native Ruby.
But I guess its more in line with OOP principles than duplicating logic. So I've made the change.

[mattr-]

I'm so sorry. I didn't do a good job of describing what I wanted. My original thought is that there could be a symlink? method in EntryFilter that is a class method. That would keep the symlink logic isolated to EntryFilter and keep from having to allocate an object just for the symlink check.

[ashmaroli]

My original thought is that there could be a symlink? method in EntryFilter that is a class method.

@mattr- Since #symlink? depends on site.source (hence indirectly @site), I feel that a singleton_method :symlink? is just going to be an abstraction just for the sake of it.
The PR in current state looks okay to me.

[mattr-]

@ashmaroli Right on. Thanks for the clarification. Do we need to get appveyor passing before merging this? Looks like it's only the Ruby 2.4 build that's failing.

[ashmaroli]

Do we need to get appveyor passing before merging this?

Its a spurious failure. The builds have all passed now.

[mattr-]

Thank you!! ❤️

@jekyllbot: merge +bug