Classic confinement request for framework-tool

[kenvandine]

• name: framework-tool
• description: CLI tool to inspect and control Framework Computer systems
• snapcraft: framework-system/snap/snapcraft.yaml at snap_packaging · kenvandine/framework-system · GitHub
• upstream: GitHub - FrameworkComputer/framework-system: Rust libraries and tools to interact with the Framework Computer systems · GitHub
• upstream-relation: contributor
• supported-category: debug tool
• reasoning: This tool is provided by Framework, the OEM, as a utility for users of their hardware to inspect and diagnose their hardware/firmware. It needs low-level firmware access to do this.

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.

There are plans to transfer this snap to Framework, and apply for verified publisher status.

[store-requests-bot]

This request has been added to the queue for review by the @reviewers team.

[zyga]

While I don’t particularly mid this I don’t think it’s fair to just approve it without understanding what the surface area is, and what kind of blockers currently exist. Do we have some more information about this?

[kenvandine]

Certainly, and I always avoid classic whenever possible. From our first look it looks like the most important thing we’re missing an interface for is /dev/cros_ec to talk to the embedded controller firmware. There is nothing providing that today, and there might be more. I considered creating a new interface for that, or looking for an appropriate existing interface to add it to, but that doesn’t scale well over time they may need more.

Aside from the system access concern, my usual concern is maintenance of a classic snap is harder, but in this case it has very few dependencies so not really concerned there.