Hi team, during TPM/FDE marathon we made this admin tool in parallel with the Security Center update we need to publish on the store.
- name: snap-tpmctl
- description: CLI tool for managing TPM-based full-disk encryption with snapd on Ubuntu systems
- snapcraft: snap-tpmctl/snap/snapcraft.yaml at main · canonical/snap-tpmctl · GitHub
- upstream: https://github.com/canonical/snap-tpmctl
- upstream-relation: it’s me and the Ubuntu Desktop’s Apps squad
- interfaces:
- block-devices:
- request-type: installation/auto-connection
- reasoning: needed for the
(un)mount-volume features
- mount-control:
- request-type: installation/auto-connection
- reasoning: needed for the
(un)mount-volume features
- dm-crypt:
- request-type: installation/auto-connection
- reasoning: needed for the
(un)mount-volume features
- hardware-observe:
- request-type: installation/auto-connection
- reasoning: needed for the
(un)mount-volume features
- mount-observe:
- request-type: installation/auto-connection
- reasoning: needed for the
(un)mount-volume features
- snapd-control:
- request-type: installation/auto-connection
- reasoning: needed for accessing
snapd privileged APIs
Hello @gabelluardo,
This is a +1 (#voteFor) from me to grant auto-connection for the block-devices, mount-control, dm-crypt, hardware-observe, and mount-observe interfaces for the snap-tpmctl snap. All of these are necessary to provide the snap’s advertised functionality.
We very rarely permit auto-connection of the snapd-control interface outside of a brand store, could you explain in a bit more detail exactly how/why the snap needs this interface?
Thanks!
Sure,
snap-tpmctl has the same features of desktop-security-center which has snapd-control auto-connected.
Also, I tried to replace it with both snap-fde-interfaces and snap-interfaces-requests-control, but I don’t have access to some API (e.g. /v2/system-info/storage-encrypted).
In the end, this tool is intended to be merged in the snapd repo in the future, and it uses already the official snapd client and structures, so I think it’s safe using snapd-control even if it’s not its documented use case.
Thank you!
Given the described functionality, that this is a Canonical-owned snap, and that this tool will end up in snapd, I feel ok giving a +1 (#voteFor) for granting auto-connect to the snapd-control interface as well for the snap-tpmctl snap.
1 Like
+1 from my end as well for auto-connection to
- block-devices
- mount-control
- dm-crypt
- hardware-observe
- mount-observe
- snapd-control
to this snap. The publisher is already vetted being associated with canonical (#voteFor)
+2 for, 0 against. Auto-conection to all the above interfaces has been granted to this snap. This is now live
(#approve)
1 Like
Voting period has ended. This request is approved with 2 votes for and 0 votes against.
Hi @0xnishit @elisehdy, thank you for the approval!
Seems like the only revision accepted is the #27 with arm64 arch, we actually only care about amd64, which is the last revision is the #24. Do this need to be manually requested/approved, or can I just push another release, and it’ll be automatically approved?
@gabelluardo , you can go ahead and push another release and it will be automatically approved
1 Like
