upki(snap): initial snapcraft.yaml for client

[jnsgruk]

This commit adds an initial snapcraft.yaml for
the UPKI client binary.

The snap is strictly confined, with access to
$HOME and the network.

It also has a 'personal-files' plug which
must be manually connected for now, but which we
can have auto-connected once the snap is published
in the store.

For now, you can test as such:

# Build the snap
cd upki
snapcraft pack

# Install and connect interfaces
sudo snap install --dangerous ./upki_0.1.0_amd64.snap
sudo snap connect upki:dot-cache-upki

# Fetch filters and do a check
upki fetch
curl -w '%{certs}' https://google.com/ | upki revocation-check high

[jnsgruk]

@julian-klode FYI

[djc]

Is it conventional for these to live upstream?

[jnsgruk]

It's mixed - many upstream projects do have the snapcraft in the upstream repo (they're pretty lightweight), but I don't have a strong opinion if you'd prefer the packaging concerns were kept separately.. I could always move the snap to a dedicated repo under Canonical

[djc]

It looks like this is focusing on the user-specific config/cache. Do you also have a plan for having a OS-global cache with a systemd unit to run regular updates?

[jnsgruk]

I could certainly add a plug for /var/cache/upki and /etc/upki, which seem like the appropriate locations?

[djc]

I could certainly add a plug for /var/cache/upki and /etc/upki, which seem like the appropriate locations?

The docs that @ctz wrote up seem to indicate the current path is supposed to be something like /etc/xdg/upki/config.toml though honestly it might be nice to get rid of the xdg segment from that.

[jnsgruk]

My plan is to add a timer service to the snap, per: https://snapcraft.io/docs/services-and-daemons

[jnsgruk]

Hmm, after a bit more playing, there is a limitation on the system-files interface that makes this quite impractical. Will discuss with Julian about creating some debs for this instead as a starting point.

[ctz]

something like /etc/xdg/upki/config.toml though honestly it might be nice to get rid of the xdg segment from that.

See https://specifications.freedesktop.org/basedir/latest/ -- it's a pretty established standard. If we deviate from that, we need a very very good reason.

[djc]

See https://specifications.freedesktop.org/basedir/latest/ -- it's a pretty established standard. If we deviate from that, we need a very very good reason.

It's also kind of explicitly for desktops, right? I've used Linux servers for 20+ years and have never encountered /etc/xdg before. All the services I've administered have used /etc/service.conf or /etc/service/stuff.conf-style things.

Anyway, I feel like @jnsgruk and @julian-klode as distro folks probably have more expertise on this than we have...

[jnsgruk]

Yeh, I think /etc/xdg is a bit odd for server-ish daemons, personally.