How to find URL for .assert file

I have a situation where I have no choice but to manually download (using wget) the .snap and .assert files for all snaps that I want to install. I’m able to obtain download URLs for the .snap files through the store’s snap info API endpoint ( Is there a way to get download URLs for the corresponding .assert files?

I’ve poked around but can’t quite work it out. It’s not clear whether the store API’s assertions endpoint ( is the place to look (or how to use it). Any pointers?

Snapd has a command specifically for this use case that will download both the snap binary and related assertions - snap download:

$ snap download hello-world

Fetching snap "hello-world"
Fetching assertions for "hello-world"
Install the snap with:
   snap ack hello-world_29.assert
   snap install hello-world_29.snap

You can then transport those to another machine and install via:

snap ack hello-world_29.assert
snap install hellow-world_29.snap

Is there a reason you can’t use the snap command? Note that the snap download command works even if you don’t have a running snapd available, and it also is build-able on Mac OS, we do this for example so that snapcraft natively on Mac is able to download snaps.

Thanks both! I should have provided the context; as you point out snap download is of course the obvious way to do this.

This is on a device that has a slow connection which also drops every few minutes - meaning that it can’t download more than a couple of MB at a time. Ordinarily, snap download would still work in that case since it can resume downloads (and with your help I bent it to my will in another similar situation: Refreshing/downloading a snap over a poor connection - #8 by svet). But the version of snap installed on that device (2.21) is unfortunately too old to support download resumption - or at least it doesn’t appear to resume downloads in practice.

So my workaround to that is to download the .snap files with wget, which does support resumption of partial downloads. Now I also need to get the .assert files - hence my question.

Of course the .asset files themselves are not too large, so another viable workaround would be to run snap download on another device and then copy over the .assert files manually. But I did wonder if there’s a less convoluted way to get them, by finding out the URLs directly.

Hope that helps clarify the slightly odd question :slight_smile:

Out of curiosity, why are you running such an old core/snapd? There have been a lot of feature and important security updates since.

That’s a very good question! It’s an old Raspberry Pi with Raspbian 9 (stretch) on it - so that’s the version that that OS supports. I tried to install a newer version of snapd via dpkg, but ran into libc6 dependency issues, which I don’t think would be easy to overcome. The device’s Internet connection is also too poor to do a dist upgrade. So…the above seemed the most promising way out.

FYI I’ve now manually copied over the assert files (having downloaded them onto another device using snap download), and everything is fine. So the original post remains as a theoretical question I suppose.

Perhaps if you use your wget method to grab and install the snapd snap itself, which is at 2.45, you might have more success with resuming downloads later?

Wouldn’t snapd’s re-exec be able to solve that issue? Is it possible for users to enable re-exec when distro’s disable it?

I think the issue is that the snapd they have installed is too old to properly support re-exec, 2.21 is very very old

Thanks all for the pointers. I suppose we’re straying a bit from the original question, but it’s been a chance for me to learn that re-exec is a thing. Indeed, after installing the core snap, I now have

pi@raspberrypi:~ $ snap version
snap      2.45.2
snapd     2.45.2
series    16
raspbian  9
kernel    4.14.52-v7+

which I suppose indicates that I’ve “re-exec-ed” into an up-to-date snapd. I didn’t try the resume functionality of snap download on the other snaps after installing core (at that point I had already downloaded everything I needed manually), but will test it out if another similar opportunity arises.

1 Like

To answer your original question, the .assert file is actually made up of multiple different assertions, so to build that file you will need to manually get each and every assertion for a given snap. I don’t know for sure off the top of my head but I think the full set of assertion types that could be included in the .assert file is:

  • snap-revision
  • account-key
  • snap-declaration
  • account

where if the snap is published by Canonical, there will not be an account key, because it will be the same account as the account-key assertion. To get one such assertion from the assertion service, you can use the following snap known command:

snap known --direct snap-declaration snap-id=OZ7LxjGo2W76qWvpNpiklbRtCA4u84L3 series=16

where currently --direct means go straight to the store, or you can also use --remote to first proxy via snapd, but in your case probably --direct is better.

Unfortunately there is not a simple equivalent cURL call to the snap known command above due to the complexities surrounding the assertion service, but the snap known command should be very lightweight in terms of bandwidth usage so hopefully it works for you.

1 Like

Right, that makes sense - also given what I saw when poking through some of the assert files. So I guess the answer is “It’s complicated and there’s no single URL“. Thanks a lot for helping me understand how it all works!