Custom assertion possible?

I want to install snaps from our S3 bucket without using the --dangerous flag. We’d sign the snap packages with our own private key and generate an assertion.

If it requires patching snapd, I can look into that as well.

Is something like that possible ?

You won’t be able to do this without patching for sure (afaik).

I have done a good portion of what’s required to make this work but it’s a tad complicated and you need a variety of assertions.

I’ve also started a store implementation but it’s only the most minimal to test some assumptions and start validating my ideas.

I am working on getting it in a state that is more ready to release as an open-source project but I’m not quite there yet. And even then it would be in just a “toy” state.

Just do a snap download on any snap and then look at the .assert file that comes with it and you can start to get an idea that it’s not quite so straight-forward as at least you described. Also, if you have interfaces that need to be connected those require assertions.

If you’re intent on pulling on this thread (like I was), I believe this is where you want to start:

And that will start you down a lot of different paths to understanding. :slight_smile:

Let me rephrase what we are looking to achieve. We want to only install snapd and core20 snaps from the public store. All other snaps will come from our own store. Snap interface connections will be dealt separately with our custom logic.

We want to add some sort of “trust” into snapd so it trusts our keys (I guess I am a bit off here in my understanding of things).

I would be quite interested in that, maybe we could collaborate on that eventually (I am investigating currently on our available options. Exploring Brand Store as well)

you will need to loop your snaps at least once through a (brand)store to get a proper gpg signature (and the matching assertion) … then you do indeed not need the --dangerous option

i guess while you could hack snapd to accept additional keys, this is likely non-trivial to achieve… not to mention that you will need to quickly adapt your hack for each and every new snapd release to not have production devices run with an outdated snapd …

Just having snapd trust other accounts/account-keys is easy and not really hacky. In fact with Go 1.16+ and embed it could be very straight-forward to extract the default account/account-key assertions for the trust and have them as separate files. Then it wouldn’t be a hack at all to have a directory of “trusted” keys when you build. Or you could just load them on the fly from a separate location. There are reasons that all of this might not be desirable of course.

The non-trivial part comes in making all of that useful. That is definitely, 100% non-trivial. :slight_smile:

1 Like

That is the ultimate goal (to start collaborating with others). A brand store will be the most straight-forward and timely, if expensive, approach.

You would always have a patched/forked snapd with the other approach. That may be viable down the road but it definitely is not right now.