Request for classic confinement for hugo snap

#1

Hello,

On behalf of Hugo authors, I would like to request classic confinement for Hugo, a fast static website generator written in the Go programming language.

We have been using confinement:strict since @dholbach generously gave us the initial version of snapcraft.yaml in September 2016. However, as Hugo grows in features and popularity, and with the Snap being promoted as the easiest and preferred installation method, more and more users run into issues such as

  1. Hugo/Go modules (see gohugoio/hugoDocs#1222)
  2. PostCSS is broken (see gohugoio/hugo#7278)
  3. Limited to $HOME access (see gohugoio/hugo#3143)

which seem to be make users and developers feel disillusioned with snaps…

Please see the most recent summary and discussion at gohugoio/hugoDocs#1222

Admittedly, the “PostCSS is broken” might be due to an outdated node.js bundled in snapcraft.yaml, and not due to confinement…

But, for other issues, are there ways around them with strict confinement? Or is it better to switch to classic confinement? Please advise.

Here is our current snapcraft.yaml for your reference:

Many thanks!

3 Likes
#2

Another issue with strict confinement: Hugo can’t access external binaries like pandoc which is necessary for other content formats besides the default Goldmark renderer to work.

Thus I would really appreciate this request to be granted.

#3

Hey @anthonyfok,

Thanks for your post. I would suggest we keep your snap under strict confinement so you can enjoy all the benefits of a stable runtime environment and we help you to (hopefully) overcome the issues your snap users are experiencing. Please remember classic snaps are not installable on Ubuntu Core devices and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions (I see you have users running Manjaro).

Have you tried snappy-debug when troubleshooting issues? It could help you identify missing interfaces you could plug while keeping your snap strict. If you run into problems, post the snappy-debug output here along with your questions and we are happy to help.

Regarding your issues:

#1. Hugo/Go modules (see gohugoio/hugoDocs#1222 )

I am not very familiar with Go modules, let me do a bit of research and will back to you as soon as possible. Meanwhile, it seems the issue your users are reporting is “Error: we found a go.mod file in your project, but you need to install Go to use it”, can you please confirm?

I am assuming #2 could be fixed with an updated node.js as you stated.

#3. Limited to $HOME access (see gohugoio/hugo#3143)

Access to arbitrary files on the system is typically not a justification for classic confinement since the the home and removable-media interfaces provide typical locations for users to operate in. Have you considered the use of personal-files, system-files, or even snap layouts? What specific locations are still not covered by those?

#4 Hugo can’t access external binaries like pandoc

Dependent software only available on host also falls under the unsupported category. You can easily include relevant packages from the Ubuntu archive via stage-packages, could this be an option?

Thanks!

#4

If I read correctly in https://gohugo.io/hugo-modules/use-modules/ is it a fair statement to say that hugo now requires recent version of go available and hugo mod essentially leverages Go Modules to setup building blocks for your hugo site?

If so, and considering that you need a recent enough version of go, how feasable would it be to just add Go into the Hugo snap?

This seems to have been covered in the issue, my proposal for the previous point is similar to what you have done on this one.

This is true, adding a couple of more interfaces would allow for access to /media and such.

I personally use hugo and would prefer it to stay strict knowing what the caveats are, but if any Go is a goal (and not an implementation detail), then yeah, classsic is the way to go. Same would apply for node.

I am not sure if channel tracks can be assigned classic and have the “main” tracks as strict, that is a potential alternative for people wanting unconfined.

#5

Looking at the documentation, it doesn’t look like Hugo is just using the Go module system as a data distribution mechanism rather than to compile anything.

It’s possible that it would work with only part of the Go toolchain available, but it also means that you might end up having Hugo invoke git to clone a module (if not going through the module proxy), which may also end up using ssh auth. It would seem difficult to get this working reliably with strict confinement, assuming it is possible.

#6

@anthonyfok ping, can you please provide the requested information so we can move fw with your request?

#7

@anthonyfok - ping, this request cannot proceed without the requested information?