To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
- name: cfgd
- description: cfgd is a declarative, GitOps-style machine-configuration tool. You declare packages, files, secrets, and system settings in version-controlled YAML; cfgd diffs desired state against actual state, plans, and reconciles — one-shot or continuously via its daemon. The snap ships the
cfgd binary (CLI plus a system-scope reconcile daemon).
- snapcraft: The snapcraft.yaml is generated at release time by our release tool (anodizer); its readable source is the
snapcrafts: block of its’ .anodizer.yaml. I can attach a rendered snapcraft.yaml from a build if that is preferred.
- upstream: GitHub - tj-smith47/cfgd: Declarative, GitOps-inspired, shareable tooling and machine configurations. · GitHub
- upstream-relation: I am the author and maintainer of the upstream project and the publisher of the snap.
- supported-category: cfgd does not map cleanly onto a currently-listed supported category. It is host configuration-management / system-administration tooling; the nearest listed category (orchestration agents “for running workloads on systems … otherwise managed outside of the agent”) explicitly excludes software that manages the systems themselves — which is exactly what cfgd does — so I am not claiming it. I am requesting review under the process for needs that fall outside the enumerated list, with the technical reasoning below and the full strict-confinement interface trial posted as a reply to this topic.
- reasoning: cfgd’s core function is to configure the host machine — it installs software by executing the host’s native package managers (apt/dpkg/dnf/brew/cargo/npm), writes managed files across the system, reads administrator-declared source paths, and runs a system-scope reconcile daemon. Under strict confinement the snap runs in a private mount namespace whose root is the base runtime, not the host: the host package managers cfgd must exec are absent from that namespace, and the host state it must read (e.g. the dpkg status database it diffs installed packages against) is not present. The path-exposing interfaces (system-files, personal-files) require paths to be enumerated at build time, but cfgd’s files, sources, and targets are declared by the administrator at runtime in YAML — the path set is unknowable when the snap is built. No combination of existing interfaces bridges “execute the host’s package managers with host context,” so strict confinement cannot perform the tool’s primary function. Classic confinement — host mount namespace, unconfined execution — is what cfgd fundamentally requires. I ran a full strict-confinement interface trial to confirm this rather than assume it; the results are posted as a reply below.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
Strict-confinement interface trial — evidence that no existing interface makes cfgd functional under strict
Setup: base core24, installed via snap try, with home, network, system-files (read/write /etc), and personal-files all declared and connected. Observations from inside the confined app:
| Check |
How |
Result under strict |
| Runtime identity |
read /etc/os-release |
reports “Ubuntu Core” — the base runtime, not the host OS |
| Host package manager present? |
command -v apt-get, look for /usr/bin/apt-get |
not found — apt, apt-get, dpkg, dnf, brew, cargo, npm all NOTFOUND in the mount namespace |
| Host package DB readable? |
read the dpkg status database |
not present — the file cfgd diffs installed packages against is absent from the namespace |
| Does system-files / personal-files help? |
reconnected both, re-ran the above |
no change — apt-get still not found, host state still absent |
Why the path interfaces do not close the gap: system-files and personal-files expose only paths that are enumerated in the snap at build time. cfgd’s managed files, GitOps source trees, and reconcile targets are declared by the administrator at runtime in YAML, so the required path set cannot be known when the snap is built. The app’s $HOME is additionally redirected to a per-snap sandbox, so the real home’s dotfiles and .git source trees are unreachable even with personal-files connected.
Conclusion: cfgd manages the host system itself. Strict confinement isolates it from that system by design, and no existing interface lets a strict snap execute the host’s native package managers with their host context — which is cfgd’s core mechanism. That is why we are requesting classic. (For history: our 0.3.5 upload shipped strict with home + network; it installed but could not perform its primary function.)
This request has been added to the queue for review by the @reviewers team.
Hey @tj-smith47
Thanks for the detailed explanation. Falling under any of the supported categories is a hard requirement. The only alternative is that a architect grants an override for this concrete application, what happen under very exceptional circumstances. Moreover, please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that cfgd doesn’t meet this criteria because of the following reasons:
-
The project seems to be very fresh, according to the upstream repository
-
The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)
-
I could not find evidences that the project has a strong enough user base currently
Considering all these factors, I think cfgd should not get classic confinement as of now.
Thanks
Hey @jslarraz, thanks for the reply.
The primary reason for even publishing this tool is to dogfood a the snap publishing feature for my other tool, anodizer. I’ve recently worked over the course of this year on both these tools, and given the natural reluctance to claude-assisted tool development, I’ve been making an enormous effort to dogfood and rigorously test each feature of each tool. This is intended to test snap publishing for classic mode, and really only needs to happen one time. I’m about to put up a handful of adoption PR’s in Rust projects throughout the community - ones you would likely consider mature and well-known enough (smallest repo has 1.1K stars). FWIW, kubectl’s krew index accepted this tool in the spirit of open source promotability, despite its’ lack of popularity, and it has since received 3 stars - availability through a breadth of platforms for users to discover and provide feedback is how you become mature and well known. I haven’t even promoted this tool yet, those 3 users came since being added to the krew index.
I’d greatly appreciate if you would reconsider allowing this tool through in this mode so I don’t have to ask my users to do this testing for me within their production release cycle. If/once I can record dogfooding proof, I can happily disable publishing to snap whatsoever, in all of my tools. I appreciate you considering the tool regardless.