Request for classic confinement for hugo snap

store-requests
#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?

#8

@anthonyfok since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks

#9

Hi @pfsmorigo,

Could you please kindly add the request back to the queue? Thank you!

And while I somehow became the maintainer of Hugo’s snapcraft.yaml after @dholbach gifted it to us, it is something that I have quite limited understanding. (As a Debian developer, my forté is in .deb packaging, and maintaining the Snap, it is more because no one else has stepped up to it and I have to do it.)

I am not entirely sure what more information you require from me; I believe the conversations at https://github.com/gohugoio/hugoDocs/issues/1222 make it pretty clear from multiple end users requiring Hugo to use classic confinement. If there are still unanswered questions, may I invite them to answer here?

Thank you for your understanding.

#10

Still requesting classic confinement for hugo snap… please advise.

#11

Regarding this request, hugo could be seen as perhaps a compiler of sorts, and so could fit within that existing category for classic confinement as per Process for reviewing classic confinement snaps - @anthonyfok to be granted classic confinement it is not sufficient to just outline reasons why something doesn’t work with strict confinement - a snap also has to fit within one of the existing categories - can you please comment on this?

#12

@alexmurray,

I am a member of the Hugo organization, and have been asked by @anthonyfok to drive this to conclusion.

I think Hugo fits into either/both of these categories:

  • compilers
  • tools for local, non-root user driven configuration of/switching to development workspaces/environments
1 Like
#13

@alexmurray, Where does this stand?

#14

Thanks @jmooring - the requirements for classic confinement for hugo are understood - @Igor could you please perform publisher vetting?

#15

+1 from me, I verified the publisher.

1 Like
#16

Thanks @Igor, classic confinement granted for hugo - this is now live (ie future uploads of hugo which specify confinement: classic will pass automated review)

Note existing users of the snap will not be automatically upgraded to the classic version - so you should publish an update which is still strictly confined that prompts them to manually refresh to get the classic version (or you could perhaps use a separate track for classic…?)

ie. users will need to manually run: snap refresh --classic hugo

1 Like
#17

@alexmurray @Igor Thank you both very much. We appreciate your assistance and guidance.