Security vs flexibility ( issue #796 )

Could we continue the discussion from issue #796
I’d like to understand better the security concern blocking some form of extension (i.e. registering external functions).

So far we agree, there is a need for a balance between security of user data/environment and Hugo’s flexibility.
In the end, themes can already carry arbitrary code, with the difference that Hugo will not just run it - user would have to manually run the theme custom code.

At the same time, in the end security of user’s files ultimately can be safeguarded by a) user knowing (or trusting) software being installed (extensions) and b) by actual operating system security (i.e. file system ACL).

One example of similar security effort is VLC which simply will not run when user is root. Personally, I’m not sure what the motivation is and why is it not enough to let user make sure not to run as root. What is interesting is the reaction from users: https://www.google.ch/search?q=how+to+run+vlc+as+root

Then again, when all things equally beneficial, the default should of course be more security.
But as an example, would it be sensible to check on start of Hugo if the user running has elevated privileges?

Regarding extensions/plugins, adding this one feature is an investment, as more code could be supported plainly by community, potentially with no cost on Hugo dev team.
@bep bottom line question is what is the required safety and can none of the concern for it be delegated to themes authors?

Even if all the above checks out: Is the feature worth the amount of work needed compared to its value and other features in the pipeline?
And the answer to the last one is currently no.

Issues like https://github.com/spf13/hugo/pull/1450#issuecomment-143312799 could easily be resolved by adding functionality externally, provided i.e. by theme author - the question is what measure of control would you be comfortable to delegate?

I will comment on this single argument, the rest is covered fine back in the issue.

There are no such thing as “no cost”, and I will tell you what the cost of maintenance of this feature will be:

  • People will start complaining about “my site suddenly got slow” … And we, polite as we are, try to investigate. After a some trouble shooting, we get access to the project Git repo, and low and behold, it is some slow running exec thingy that is in heavy use.
  • People will start complaining about random crashes. … And we, polite as we are, try to investigate. After a some trouble shooting, we get access to the project Git repo, and low and behold, it is some exec that tries to compile and execute some Java program, which works fine locally, but fails on Wercker, because no Java
  • The exec plugin feature was buggy, but the person who implemented the feature and told everyone that this was a piece of cake and that he was a security expert, is now on a 6 month vacation around the world, and “someone else” will have to clean up the mess …
  • … etc etc.

I’m not against a well designed plugins system. But I’m against this particular issue. It seems simple, but it isn’t.

I’m not against a well designed plugins system. But I’m against this particular issue. It seems simple, but it isn’t.

OK, perhaps we were just talking close, but not exactly about the same thing. So you don’t like the implementation from #796, while you are open to some form of extendability?

Could we start from an outline - to your mind and in general terms, how should a good solution look like? What should it be disallowed to do and what would you expect that it would deliver (to be worth the support on Hugo side)?
I’d start with repeating what you shared already - please correct if I misrepresent anything.

Plugins/extensions / the whole plug implementation in Hugo CAN NOT:

  • the Hugo implementation - can’t be over complicated, so that if must be, it can be supported by any Hugo developer (Superman’s intervention not required)
  • negatively impact performance
  • break Hugo functionality
  • drain support resources from other development
  • shift support effort from actually supporting Hugo users with Hugo related issues to issue in some ones private ball of mess

I would add that,

Plugins / plug implementation should:

  • allow theme authors / Hugo users to delegate some processing to code that is provided outside of Hugo

Btw., the only thing you did reply to, I’m not sure if we again communicated well - what I’m suggesting that you don’t need to support plugins. It would be a fair community contract that plugins provided by 3rd parties, and NOT with Hugo (who knows, perhaps you will want to ship some additions as plugins as well) are not supported by you. Community forum could still be used, or the plugin authors should take responsibility, but I don’t understand why plugins themselves must be supported by Hugo dev team?
I was not suggesting that the integration implementation in Hugo would be free - this would ofc require support.

Deliver one simple integration and when it’s mature (useful) constrain it’s changes to essentials, bug fixes, etc. + explain contract on plugin support does it sound like a feasible option?

I’d really like to continue this discussion to find what are the hard constrains.
I wanted to try and propose a solution, but it’s not going to be an effective process if I don’t know what the parameters are.
At any rate, the questions raised by me are genuine and I don’t see answers to them on the #796 discussion - could you help me with this, @bep or anyone else?

This isn’t a priority of mine at the moment, so I cannot spend any time on it. Sorry.