Manually reviewing private snaps?

Say I want to use private snaps to deploy to my own servers. Let’s say I want to try using restricted interfaces, like snapd-control. As of today, even though my snap is private, my snap get popped into the manual review queue.

Why? Private snaps by definition only affect me and my collaborators, right? What do we gain by denying stuff in that case? Perhaps automated review failures should be warnings/informational when the snap is private?

Perhaps the answer is “because the developer can always press the ‘make public’ button,” to which I ask: why not promote review warnings to errors at that time?

Hey @kyrofa,

Privacy of a snap can change at any time, and the decision of how the privacy change is up to the snap publisher, so the store needs to guarantee that the snap will be as safe and sane as any other for when it gets switch to public.

Can we not treat the review results differently depending on whether the snap is private versus public? Failures are non-fatal when private, but become fatal to prevent the move to public?

3 Likes

Absolutely agree with @kyrofa.

Ok then the “Make public” button should be grayed out if there are some validation issues. Isn’t it obvious?

4 Likes

This would be useful for us too. Right now we are stuck using devmode and limited to the edge / beta channels because we use the snapd-control interface. It looks like a few different projects in addition to mine are using snapd-control to manage their devices.

1 Like

@jdstrand and @niemeyer can you chime in on this, Kyle raises interesting points wrt private snaps and forbidden interfaces.

Today, the review-tools don’t know if it is private or public, but the store could let them know as part of the invocation.

What is probably better is that the store calls the review-tools like normal and simply doesn’t block on errors or warnings if the snap is private. This would allow people to see what would happen if it went public (this happens to also be simpler to implement).

I suspect there might be some things that would be important to still block on, but I’m not sure what they are. One could also argue that if it is a private snap, the user knows what he/she is doing.

3 Likes

My thoughts exactly, I think that’d work quite well.

Yeah, that sounds relatively straightforward. Each revision just needs a boolean associated with it that describes whether the particular snap may be released.

In fact, that’s pretty close to the current situation already. Once an upload is made, the given snap revision is sitting somewhere in the server and cannot go public until the review happens and goes green. We just need to open the snap up for installation by developers associated with the account.

@noise - is this something that could be put on the Store team’s roadmap? (Ie, if snap is private, run the review-tools like normal except don’t block publication).

@jdstrand what if one starts a snap as private, publish something that doesn’t pass the tools, and then turns the full snap public?

I might be caught in some terminology confusion here between publication vs release

That’s a good question-- I was (perhaps mistakenly) assuming that a particular revision of snap could either be private or public, and not move back and forth. In that way, a new upload would be required which would trigger another review, since it is public, it would be blocking.

If that is not the case, I think the act of going private -> public would simply trigger another automated review and then we follow the normal procedures as if it was uploaded as public.

This is a store capability that is really confusing to me as when we worked out the user story, privateness was determined at registration time.

public / private is a flag on the whole snap atm

I suppose the store could when going from private to public, put any failed revisions into the ‘failed review’ bucket and and passing revisions publish like normal. I think we need store team input…