Hi store team,
Requesting personal-files for the kubeintellect snap (strict confinement).
Note: the name registration for kubeintellect is still ReviewPending, so there is no revision uploaded yet. I am filing this now so both reviews can proceed in parallel. Happy to narrow the paths if you would prefer something tighter.
name: kubeintellect
description: KubeIntellect (kq) - a terminal client that lets you query, debug and triage a Kubernetes cluster in plain English. It talks over HTTPS to a KubeIntellect server.
snapcraft: https://github.com/MSKazemi/kubeintellect/blob/main/snap/snapcraft.yaml
upstream: https://github.com/MSKazemi/kubeintellect
upstream-relation: I am the author and maintainer of the upstream project.
plugs:
dot-kube:
interface: personal-files
attributes:
read: [$HOME/.kube]
request-type: manual-connection
reasoning: >
kq is a Kubernetes client, so it must read the user's existing kubeconfig at
the standard ~/.kube location, plus any client certificates it references.
The home interface does not cover top-level dot-directories, so this is
requested explicitly. It is read-only. Requiring users to duplicate their
kubeconfig under ~/snap would break every normal kubectl workflow, including
the live context switching the client supports.
dot-kube-q:
interface: personal-files
attributes:
write: [$HOME/.kube-q]
request-type: manual-connection
reasoning: >
~/.kube-q is the client's own state directory: config, named profiles,
plugins, and the session-history SQLite database. It is named after the
snap's own command (kq / kube-q) and is not shared with any other
publisher's data. Using the same path as the non-snap install means a
user's existing state keeps working after switching to the snap.
The snap’s own description already instructs users to run sudo snap connect kubeintellect:dot-kube and sudo snap connect kubeintellect:dot-kube-q after installing, so manual connection is what I am asking for here, not auto-connection.
Thanks!
This request has been added to the queue for review by the @reviewers team.
Hello @mskazemi,
Given that this request is for manual-connection, as well as the fact that both paths requested are reasonable access expected for the snap as described, this is a +1 from me for granting manual-connection for the specified personal-files interfaces to the kubeintellect snap, pending the name registration, first revision of the snap, and successful publisher vetting. What do other reviewers think?
Hey folks!
Given that it is limited to manual-connection I think I can also support this request. +1 from me
+2 votes for, 0 votes against, granting manual-connect of interface personal-files as described to snap kubeintellect. @mskazemi can you please confirm your project-associated github username to proceed with publisher vetting? Thank you!
Thanks @elisehdy, and thanks to @jslarraz for the second review.
Confirming: my project-associated GitHub username is MSKazemi. The project repository is github.com/MSKazemi/kubeintellect (the same upstream URL given in the first post — my trust level here will not let me post it as a link again).
I am the upstream author and sole maintainer of the project, so the publisher and the upstream are the same person rather than a third party packaging someone else’s work. The snap is built from snap/snapcraft.yaml in that repository by .github/workflows/snap.yml, and the same identity publishes the project’s two PyPI distributions, kubeintellect and kube-q, and the documentation site at kubeintellect.com.
Store publisher account: Ubuntu One mohsenseyedkazemi (this forum account, mskazemi).
One note in case it is relevant to the next step: revisions 1 (amd64) and 2 (arm64) of 1.5.0 were auto-rejected on 21 August with the standard “personal-files is a super-privileged interface, please file a store-requests topic” message — about eleven hours before the grant was announced here. Happy to upload fresh revisions once the declaration is in place; just let me know if you would rather I wait for anything else first.
Thank you both for the review.
A small factual follow-up, in case it saves the next reviewer a step.
I uploaded fresh revisions from a current build — 3 (amd64) and 4 (arm64). Both were automatically rejected, with:
Rejected. Automated review found 2 errors and 0 warnings. Rejected automatically after manual rejection from revision 1.
The two errors are the declaration-snap-v2_plugs checks for dot-kube and dot-kube-q, so the automated review is reading the current snap-declaration and correctly still finding the plugs disallowed.
The practical consequence: since revision 1 was manually rejected, every later upload that trips the same two checks is now auto-rejected without human review. So a new upload cannot be the thing that unblocks this — the declaration has to be updated first, and then I can upload a clean revision immediately.
Nothing needed from you beyond whatever publisher vetting requires; I have the builds ready and will upload the moment the declaration is in place. Please just let me know if you would like anything else from my side.
Thank you for the detailed reply! I will proceed with publisher vetting.
+2 votes for, 0 votes against, granting manual connection of interface personal-files to snap kubeintellect. Publisher is vetted. This is now live.
Please let me know if you run into any issues.