Classic confinement request - bart


#1

I have a CD pipeline that builds and publishes an updated snap. I recently realized it needs to have classic confinement but now it requires manual review. Is this is a one time process the first time classic confinement is requested? Or will this require a manual review for every update? Here is the requested revision: https://dashboard.snapcraft.io/snaps/bart/revisions/11.


#2

Why specifically does the snap need classic confinement? Are you saying your snap drives snapcraft?


#3

This is an internal CLI tool for our engineers. When features are added to the repository, it automatically builds and publishes the updated snap to the store. It needs to have file system access which is why it needs classic confinement.


#4

As it is currently, bart is a public snap in the global store. Granting classic for an internal tool in the public store is not a typical use case. Is this tool useful to others? Would a brand store where you can control all aspects of your snaps and brand be a better fit? (https://docs.ubuntu.com/core/en/build-store)

If useful to others in the global store and you want it to be used globally, can you provide specific details on why it must be classic as per Process for reviewing classic confinement snaps?


#5

The brand store would be a better fit I think. But, the link you posted isn’t valid.


#6

The correct link is https://docs.ubuntu.com/core/en/build-store/ for some reason the link that @jdstrand posted doesn’t work unless you add a “/” to the end. (filed an issue with the docs at https://github.com/canonical-web-and-design/docs.ubuntu.com/issues/215)


#7

What if I made the snap private? Does that have different requirements than a public snap?


#8

I’ll let @jdstrand comment but AIUI no, because a snap can change from private to public anytime.


#9

@ijohnson is correct, though there is discussion on this point in Classic confinement request: automaton-builder


#10

In Classic confinement request: automaton-builder, @noise said:

"Unfortunately we can not support that case currently. We could look into adding a feature to disable classic if granted while private and then later made public, but without that there is a large hole that I’d rather not leave open. I will add this to our ideas list for consideration.

Your best bet for now is to bundle those dependencies and avoid the use of classic."

I believe the same criteria holds for this request and that either you should bundle or use a brand store for your organization.