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 (https://api.snapcraft.io/docs/info.html). 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 (https://api.snapcraft.io/docs/assertions.html) 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 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
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
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.
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:
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.
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!