Clarification on how snap refresh control handles revisions


We have been testing snap refresh control, and following the documentation here:

We have everything set-up, and it basically works. The gated snap is downgraded to the revision we specified, and if I check the local assertions via snap known validation I can see the validation assertion.

However, we then tried changing the policy to an older revision. So we created and uploaded the new assertion, that worked fine, and if we query the remote assertions we see it listed. However, the new assertion with the older revision never seems to get downloaded onto the device. WE have tried purging the gating snap, re-installing it, doing a full snap refresh, and even a reboot for good measure ! Nothing seems to make it notice the newer assertion.

I have a hunch it may be because the approved-snap-revision in the newer assertion is a lower than the previous assertion. If so, it feels a bit like a bug, or at least undocumented behaviour.

Can anyone confirm what the behaviour should be ?


What is your expected behavior after moving the approved-snap-revision to a lower revision number in the new assertion for devices that already installed the new revision ?

Hi @ijohnson - happy new year :slight_smile:

I was expecting it to downgrade to the lower revision. That may not be a valid expectation, but it’s not obvious from the docs that it should not work like that as far as I could tell.

When you initially install the gating snap, if the gated snap was installed previously [ un-gated ] it does downgrade it to the gated revision. If that’s not expected, I could test that again to double check it.

Cheers, Just

1 Like

All validations are independent, they don’t replace one after another. They can be revoked though at which point one for an older revision could/can come in effect again. ATM there might be gaps in the tooling wrt revocations, that is something to discuss with #store .

@pedronis Thanks for the info, that’s starting to make more sense.

I’ll ask about revocation in #store as you suggest.


…just in case anyone follows this thread: Can a Store validation-assertion be revoked?