New bare base

[ale8k]

Hi,

I was following:

Process for reviewing base snaps

Base snap review process Background As of snapd 2.29, snappy supports type: base which allows the snap to be used as an alternate runtime for other snaps. Because base snaps provide libraries and other supporting files to snaps that depend on them, care must be taken in making them available to other snaps. As a practical matter, base snaps could not be widely used until base-template security policy was implemented, which is now included in snapd 2.45. the review process in the snap store wil…

Our team (Commercial Systems) requires a bare base that has access to general system utilities for statically linked binaries.

I’m a little iffy on if it is done correctly, the repo can be found here: https://github.com/ale8k/bare-with-bash-snap-base/blob/main/snap/snapcraft.yaml

I plan on moving this repo to our organisation afterwards.

As such could I request the following (if everything is OK):

1. The snap “bare-bash” be moved to Canonical with our team for the “canonical-livepatch” snap access granted.
2. The snap be enabled to be a “base”.

Thanks in advance and apologies if anything is incorrect!

[roadmr]

Doesn’t the existing bare base snap serve your purpose?

Install bare on Linux | Snap Store

You said your snaps are statically linked so I’m not clear why they also need bash, but if they do maybe you can include bash in them (which you would also have to statically build anyway because I’m fairly sure using bash as a stage package will have library requirements and thus won’t be fully static).

• Daniel

[kian90]

@roadmr I’m replying on @ale8k’s behalf as he is out this week.

For context, we are experimenting with this for the Livepatch client snap. The binary inside the snap is statically linked but it also uses some bash (and core utils) in its hooks and due to this bug the snap’s auto-generated meta hooks require a shell located at /bin/sh.

The original plan was to use the bare base + busybox (statically linked) to get it all working. But because of the limitation above around the meta hooks, it seems easier to go with our own base that has busybox and a shell located in /bin/sh.

Hope that’s all clear. Also, maybe this is something that can be discussed in person in Prague to understand the approach better.

[emitorino]

@kian90

For context, we are experimenting with this for the Livepatch client snap. The binary inside the snap is statically linked but it also uses some bash (and core utils) in its hooks and due to this bug the snap’s auto-generated meta hooks require a shell located at /bin/sh.

iiuc from the bug comments, it seems @mr_cal is suggesting alternatives to make this work with the existing bare snap. Unless this is urgent or is blocking the Commercial System team, I think this is preferred. Maybe @sergiusens can also help here.

[mr_cal]

My apologies, I missed the responses on the Launchpad bug. I’ll take a look tomorrow.

[mr_cal]

I added a suggestion in the Launchpad bug report

[kian90]

Hi,

@mr_cal’s suggestions ended up working so there is no longer the need for a different bare snap here. Thanks for the suggestions and collaboration here!