As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.
For example, to request <interface> auto-connect:
- Is application publisher considered trusted by the Snap Store?
<instructions on how to become one>
- Has publisher agreed that they are in accordance to with the <access control policy for authentication keys which can push to store>?
This agreement would help minimize the risk that an unauthorized user can obtain the keys to push an unauthorized <snap> version to the store. It may include consequences if it is discovered that the policy is not adhered to.
- Does the snapcraft recipe perform a repeatable build in accordance to <version policy>?
This could be useful to automate validation of builds and provide an audit trail in case of abuse.
- Does the requested auto-connect interface enable a feature that a reasonable user would expect to work?
That is, does the non-snap version expose this functionality to the user?
- Are there alternatives to using the requested interface that do not impact “reasonable user” functionality?
- Are the alternative(s) documented?
- Is this request intended to be temporary?
- Has publisher agreed on path towards this implementation?
- Has publisher documented grievance on the recommended alternative approach(es)?
- Is this application documented as a core, or security-critical snap?
Is there a documented reason to ensure this application is as hardened / locked down as possible for system security reasons? Presumably this would make the case harder to get auto-connect.