Include all validation sets used to check in the validation error
instead of wrapping error with additional information.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Wrap the error returned by CheckInstalledSnaps with the new sets
that are not currently tracked. The previous approach required
marking those sets as "extra" in the validation set but was out
of place since this is only required for callers of "TryEnforce" to
resolve constraints that led to the validation error
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Take a typed ValidationSetKey in the store package instead of a
[][]string, to help prevent wrong keys from being passed. To the same
end, also renames the field from ValidationSet to ValidationSetKey.
Also adds a Components() helper to split the key into its primary key
components.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
snapsserts.DeriveSideInfo* cannot deal with snap-revisions with the
same hash but different provenance in the local system assertion
database, this should be an acceptable limitation for a while
the seedwriter code now assumes that the input can be trusted, this is
reasonable
systems.go uses already installed snaps, so it's fine but probably
would still be good to address the TODO in it for efficiency/clarity
as the code in seedwriter DeriveSideInfo is even more clunky now for
this use case, we should be able to find an applicable snap-revision
by other means
snap revision fetching and cross-checking should take provenance into
account and also verify device scope constraints for revision
authority delegation
provenance is taken as a hint from the store, but then matching
assertions must be found and then provenance is double checked
a failure of the latter check is likely a sign of a bug or
error as an attacker that can submit or forge/sign a blob could
as well do one with the expected provenance
provenance goals are tracing and avoiding the risk of polluting
the snap-revision namespace
this leaves alone the DeriveSideInfo* functions mainly used for
asserted local installs, this means they might fail to find a
snap-revision sometimes, they will be updated in a different branch.
function tries to enforce extra validation sets passed to it (and
updates v-s tracking state) or returns an error.
ValidationSetsValidationError can be used by the caller to resolve
validation issues and retry.
