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?
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.
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?
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.
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.
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!