Installing with .snap and .assert

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:

grep snap <assert file>
# verify output is expected
snap ack <assert file>
snap install <snap file>

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.

During snap install it tells you the name of the snap from inside the snap file and who published it, not the filename.

alan@KinkPad-K450:~/testing$ snap info null
name:      null
summary:   ∅
publisher: Alan Pope (popey)
license:   unset
description: |
  ∅
snap-id: pkq6z3c0BWk1qq734AafcLDsBxY2r89P
channels:
  stable:    null 2019-08-03 (3) 4kB -
  candidate: ↑                       
  beta:      ↑                       
  edge:      ↑                       
alan@KinkPad-K450:~/testing$ snap download null
Fetching snap "null"
Fetching assertions for "null"
Install the snap with:
   snap ack null_3.assert
   snap install null_3.snap
alan@KinkPad-K450:~/testing$ ls
null_3.assert  null_3.snap
alan@KinkPad-K450:~/testing$ mv null_3.assert scary_3.assert
alan@KinkPad-K450:~/testing$ mv null_3.snap scary_3.snap
alan@KinkPad-K450:~/testing$ snap ack scary_3.assert
alan@KinkPad-K450:~/testing$ snap install ./scary_3.snap
null null from Alan Pope (popey) installed
alan@KinkPad-K450:~/testing$ 
alan@KinkPad-K450:~/testing$ snap info scary
error: no snap found for "scary"
alan@KinkPad-K450:~/testing$ snap info null
name:      null
summary:   null
publisher: Alan Pope (popey)
license:   unset
description: |
  null
commands:
  - null
snap-id:      pkq6z3c0BWk1qq734AafcLDsBxY2r89P
refresh-date: today at 18:29 GMT
channels:
  stable:    null 2019-08-03 (3) 4kB -
  candidate: ↑                       
  beta:      ↑                       
  edge:      ↑                       
installed:   null            (3) 4kB -


also, snap info ./scary_3.snap would’ve told you something about the snap… :slight_smile:

2 Likes

Maybe snap install foo.snap should print the header out if it’s a local snap and not a store one, with a --silent option perhaps? :slight_smile:

@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…

1 Like

Ah thanks for the replies. I think this is maybe the thing I’m missing:

I didn’t think about using info on a local file.

1 Like