Interface developers typically will modify the policy on the system in /var/lib/snapd/*/profiles directly when developing the policy. The digest approach complicates that, but not in an insurmountable way. It does mean we need to document the new way so people can see where the profiles are. It only affects admins and users who care about the policy on the system, but again, not in an insurmountable way. The point of my comment on this is to capture what needs documenting.
There is the “We need to make snap-confine wait for some amount of time and warning about it if its required profile is not yet in place” idea-- this puts snapd in the critical path. I put forth one way to get out of the critical path in addition to @mvo’s proposal, snapd-confine could itself strategically call snap-generate-profiles or some other appropriate tool that doesn’t rely on snapd running when the profile isn’t there, so you don’t have a timeout and services can start without snapd.
My point is what is missing in all other views of the problem. The quoted ‘general view’ only talks about ‘format data’ but it isn’t just about parseable policy; it is also about the content of the policy. Consider a rule is added in a new version of snapd that fixes a security issue in the policy where that rule is parseable in previous revisions. We want to rev the digest input there so that snaps don’t race and run with the old policy.
Yes, I was summarizing why I consider the proposed change a good one.
I don’t quite understand this comment. @mvo is certainly aiming for this in the proposal, and I agree with the proposal (with a few additional details), and we can certain expand on the digest input as we see fit in the future… What’s the problem?
Perhaps you are confused because we were responding at the same time and it seemed like I was countering you? Regardless, I think this approach does add complexity but, again, in a way that IMO is acceptable.