Consider re-enabling symlinks (at least opt-in?)

In 0.56, symlinks got explicitly forbidden for /static (github com/gohugoio/hugo/commit/e5f229974166402f51e4ee0695ffb4d1e09fa174 - sorry for the link, new user, I’m limited to two links in a single post). While I get the argument, it prevents the usage of Hugo entirely in certain circomstances (granted, they’re quite specific, but they exist). In my case for example, I have my webiste in a monorepo managed with Bazel, which relies on symlinks to sandbox every single input of every single task to ensure hermeticity and reproducitibility. Because of that change, I’m either stuck on Hugo 0.55.6 forever, or have to disable sandboxing for my repo (which is not an option).

Now I’m not fluent in Go and I didn’t dig deeper than this specific commit, but it looks like symlinks are explicitly dropped while they could just be handled as regular files. Would it be an option to re-enable symlinks support, guarded with a flag, for users who need them?

So, before 0.56 the symlink handling in Hugo was revised. Before that it was for /content and some other very much undefined places.

  • After 0.56 we in general support symlinks everywhere execpt from themes/modules (the latter motivated by security/sanity; and this is the logic in the source link you posted).

So, the situation should in general have improved, but obviously not for you.

  • Is this from /static in a theme?
  • If no, and it workd before, I may have introduced something that I didn’t mean to. With the /static mount, we’re using a third party library that uses Go’s “file walker”, which does not follow symlinks, but I guess that is folders and not files. Is this files? Or perhaps directories directly below /static?

Thanks for the detailed explanation!

I have the issue for files from a theme, but not only for /static:

  • files in themes/my-theme/layouts/_default
  • files in themes/my-theme/layouts/partials
  • files in themes/my-theme/static/css
  • files in themes/my-theme/static/img.

Interestingly enough, files in /static in the site itself are working just fine. I’m not exactly sure which files/folders are symlinks (Hugo logs files directly though, not folders, if that’s relevant), as Bazel is removing the sandbox as soon as the action is complete - I’ll have to dig more into it.

(I’m not sure you meant “from /static in a theme”, or “from /static or in a theme”, sorry)

I’m testing with both 0.55.6 and 0.56.0 to have the minimum set of differences and 0.58.3 (0.56.0 and 0.58.3 behave the same way). It works fine with 0.55.6, doesn’t pick the files from the theme in 0.56.0+.

Edit: I just realised that if the files in /themes/my-theme/layouts were picked up despite the symlinks (which, as I understand, would be intended?), I could live without symlinks in /themes/my-theme/static - all of those are CSS and SVG files, which I could expose through resources instead. I’ll give that a shot as soon as I can.

OK, then I see: Yes, for themes (and theme components) in /themes (and also included as Hugo Modules) we currently do not support symlinks.

But at the same time we added a powerful mount config syntax:

Could that help somehow - by mounting file from the theme directly into the website, for example? (I sadly don’t control the symlink creation, they’re created whether I like it or not.)

So I read a little bit more how modules work, and that doesn’t help me as symlinks aren’t authorised anyway for themes even by using mounts. The only solution that I see is hardly a solution: mounting all the paths from the theme to consuming sites, which would be 1) a real pain to maintain 2) preventing sites to override files from the theme.

While I kind of understand the security concerns you’re trying to prevent with this, you’re also preventing users to use a standard file-system feature that has been around and widely used basically since modern computing exists. I really hope you consider adding a flag to allow symbolic links in the future.

I would consider it, but it would include a fair amount of of my time to do so (as in: not 5 minutes). But I think it would need more than “a couple of persons” to convince me to go that extra mile. Even if you ignore the security aspect, you will soon get into an extremely hard-to-debug setup if your component/theme tree gets big enough.