I know that if you’re planning to install a snap from a local .snap file, you need to first ack it’s corresponding .assert file. So my question is very basic: How do I know that the filename of the assertion is the same as it’s contents?
snap ack didn’t seem to mind when I renamed the files. I did open the assert file and I think I did find what I needed. So would best practice for installing a snap from unknown origins be something like:
the snap assertion ties the snap’s sha3_384 into the chain of trust; snap ack adds that information to snapd’s assertion database. On install we’ll compute that hash of the snap, and look it up in the assertion database. The filename doesn’t come into it at all, really.
If you’re given an assertion that’s for a different snap than the filename would imply, then the installation would fail (without --dangerous). If you’re given an assertion that isn’t ultimately signed by the canonical key, then adding it to the database will fail.
Is there something in particular that you’re worried about?
To be clear, this a fairly hypothetical questions. Recently, I had given someone else some snaps, so they wouldn’t have to download them, so I was thinking about how to do this securely.
Anyways, imagine a scenario where a (nefarious) user takes a legitimate snap from the store and renames the snap and the associated assert files. If I ack’d and installed those files (without first inspecting the assert file), I would end up installing a different snap than I intended. Some of the risk would be mitigated of course, because it would have to be another legitimate snap from the snap store.
@ryanjyoder the assert file, it’s either signed and ok (even though it might not be relevant to the snap at hand), in which case adding it to the assertion database can do no harm, or it’s not ok and it will be rejected.
For the snap file, snap info will tell you what snap it is by inspecting it, and if it’s not the one the assertion refers to the installation will fail.
The problem with having something that would print something useful about the assertion file is that it’s going to be a half dozen assertions one after the other, so it’s not entirely clear what could be printed that would be useful and concise enough for what I think you want…