reason for blacklisting plugins?

[ReenigneArcher]

Before submitting an issue, please be sure to

• [x] Read the contributing instructions
• [x] Update to the latest Gem version (run bundle update github-pages)

This issue affects

• [x] The site generated by GitHub Pages
• [ ] Building sites locally

The GitHub Pages Gem is intended to help users replicate the GitHub Pages build environment locally. If your issue affects both the hosted version and the version previewed locally, you may be better suited reporting seeking support in other forums.

What did you do (e.g., steps to reproduce)

Can someone explain the reasoning behind disabling plugins, except those approved? The limitations are pretty harsh and complicate the build process for what seems like no good reason.

Additionally, even if you are okay with a custom workflow and deployment to gh-pages, if you create a remote theme that needs a plugin, then every place the theme is used, must also use a custom workflow.

Personally, I am trying to create a remote theme for my org that can be easily used in all the other repos. I want to be able to use a package.json file and install npm dependencies in the build automatically, but sadly this is just impossible with the automatic gh-pages workflow.

I would just like to understand the reasoning, as it doesn't make sense to me. There's almost zero limitations with any workflow using github actions, so why are the limitations put in place here?

What did you expect to happen?

Allow using any plugins whether they are gems or in the _plugins directory for a jekyll build.

What happened instead?

Plugins don't run.

Additional information

• Link to the live site (if applicable):
• Link to the source repo (if applicable):

[fredemmott]

I don't work on this, this is just my understanding:

This feature exists because the 'classic pages experience' depended on the whitelist to avoid executing untrusted code in an environment that wasn't fully sandboxed.

However, the whitelist is completely pointless (and should be removed) when using the GitHub Actions flow, as GitHub Actions is designed to run untrusted code without putting GitHub's security at risk.

Workaround

It is possible to use this gem via github actions without the whitelisting, if you want to keep on using the default plugin list, configuration etc, with minimal other changes:

1. remove , group: :jekyll_plugins from the gem "github-pages" line in your Gemfile
2. set safe: false in your _config.yml
3. create your own plugin in _plugins/ that:
   • restores the original configuration for whitelist-related keys
   • loads this gems' configuration super early, so that the jekyll plugin manager still loads all the other plugins this brings in super-early - for example: https://github.com/OpenKneeboard/OpenKneeboard/blob/f44354d5a3021814d8dc056f4f98b61116d1ccd1/docs/_plugins/github-pages-unsafe.rb

My use case

• I want to keep using GFM/jekyll with all the default settings
• I want to change my URIs to pretty URIs
• I want a trivial custom plugin to redirect the non-pretty URIs to the pretty URIs (https://github.com/OpenKneeboard/OpenKneeboard/blob/master/docs/_plugins/redirect-html-extension.rb) ; this is not possible without killing the whitelisting

Suggestion for actual fix

The maintainers should either:

• remove the whitelisting when github actions is being used
• split this into two gems:
  • one that does all the default configuration except for the whitelist, intended for those using github-actions
  • keep this one, depending on the other, and adding the whitelist, just for those using the classic flow
  • two gems, but the opposite: just remove the whitelisting from this gem, target it for the 'github actions' flow, and add a separate 'github-pages-classic' gem or similar for local testing of the classic flow

[fulldecent]

The scope of this project is:

A simple Ruby Gem to bootstrap dependencies for setting up and maintaining a local Jekyll environment in sync with GitHub Pages

So I think "remov[ing] the whitelisting when github actions is being used" is not out-of-scope.

If people are using GitHub Actions, then they can either adopt the convenience of this gem, or they can roll their own build system.

Using this gem is nice if, for example, you need to make a continuous integration test that needs to exactly test the output of the default of GitHub Pages builds. (You can test the exact output of the build with HTML testing tools.)

Or if you are switching (graduating?) from the training wheels version of GitHub Pages automatic builds then you need to identify your own best practices and own your own build system.

Here is one such project that identifies best practices and is a template build system for your own GitHub Pages sites. https://github.com/fulldecent/github-pages-template // even for that project I think dropping the github-pages gem is a good idea.

[parkr]

The allowlist provides usability benefits as well & reduces the burden on Support. By ignoring the Gemfile for the classic Pages experience, the system can guarantee it can install the apps (not always the case with RubyGems, since many C extensions require other libraries to be installed). Additionally, there isn't any isolation from plugin to plugin, so one plugin could negatively affect another, or cause theme incompatibility or any other negative effects. Generally, the "classic" experience is meant to be curated & easy to use. If you want more power, a custom GitHub Actions workflow can be used to build the Pages site (folks can even use other generators!), then GitHub will deploy the tarball it's given IIUC. I don't work at GitHub but I can see the value in providing both a curated limited experience while also allowing power users to plug in their own build step.