conditionally fallback to iface ref overrides when plug-names not present
Before snapd 2.44, snapd did not have proper controls on what the
interface reference must be in the snap declaration, so we had a cheap
test that utilized the overrides mechanism to ensure that the interface
reference is in the list of allowed references. Older snaps with
existing overrides will remain here, but new ones should use the
'plug-names' mechanism.
Since there are a number of snap declarations in the store without
plug-names where we've used the overrides mechanism, update
_check_constraints1() to fallback to the old overrides mechanism iff it
is checking an installation constraint for plugs and the interface
reference is listed in the new interfaces_needing_reference_checks list
(which is populated with 'personal-files' and 'system-files', the only
two interfaces which used the old override mechanism). Eg, for a snap
that uses personal-files:
There is only one error and no warning with no snap declaration (eg,
initial upload):
$ snap-review ./foo.snap
Errors
------
- declaration-snap-v2:plugs_installation:hostfs-opt-ros:system-files
human review required due to 'allow-installation' constraint (bool)
A snap declaration with matching plug-attributes and plug-names passes
(eg, new-style snap declaration):
$ snap-review --plugs=./matching-with-matching-plug-names ./foo.snap
./foo.snap: pass
A snap declaration with matching plug-attributes and unmatching plug-names
fails (eg, new-style snap declaration where the publisher used a
different name):
$ snap-review --plugs=./matching-with-unmatching-plug-names ./foo.snap
Errors
------
- declaration-snap-v2:plugs_installation:hostfs-opt-ros:system-files
human review required due to 'allow-installation' constraint (plug-names)
A snap declaration with matching plug-attributes, no plug-names but with
a matching override falls back to the old override checking and passes
(eg, old-style snap declaration):
$ snap-review --plugs=./matching-with-matching-override-only ./foo.snap
./foo.snap: pass
A snap declaration with matching plug-attributes but no plug-names and
without a matching override falls back to the old override checking and
fails (eg, old-style snap declaration where publisher used a different
name):
$ snap-review --plugs=./matching-without-plug-names-or-override ./foo.snap
Warnings
--------
- declaration-snap-v2:interface-reference:hostfs-opt-ros:system-files
override not found for 'plugs/hostfs-opt-ros'....
sr_declaration.py: fix matching for allow with multiple constraints
_check_constraints1() correctly handled deny* with multiple constraints
but would incorrectly match allow*. As an invariant, if multiple
constraints are specified, they all must match, but a 'match' is
dependent on if it is an allow or deny constraint. Specifically,
_check_constraints1() collects the error strings for a particular
alternation and when checks were performed will return an error if:
- at least one check errored with 'allow' since not fully matching
the allow means means we should display an error (not allowed)
- all checks errored with 'deny' since not fully matching the
deny means we should pass (allowed)
In practice, this wasn't a problem since declarations didn't have
constraints that when combined would exhibit the error (eg, snap-type
other than 'app' are handled elsewhere; the same is true of
on-store/on-brand). plug-names was added to be used with plug-attributes
but needed store support which was only added (relatively) recently. In
making the corresponding updates to the review-tools to consider
plug-names with plug-attributes to verify interface references for
personal-files and system-files, the issue was discovered.
