Files
snapd/tests/lib/assertions
alfonsosanchezbeato d5f47ca71f many: read system options when handling kernel command line (#12561)
* o/devicestate: read system options when handling kernel command line

Use the kernel command line options when building the kernel command
line.

* tests: add cmdline-option test

cmdline-option checks that we can change the kernel command line using
the kernel system options.

* overlord: make task keys for the update cmdline task constants

* o/devicestate: export CurrentGadgetInfo so it can be used from configcore

* o/configcore: validate kernel command line against allow list

* o/devicestate: use the full string when looking for the kernel command

line options.

* tests/nested/manual/cmdline-option: run remotely all commands

* overlord: copy strings instead of using constants for task keys

Until some better way is found.

* gadget,overlord: change checking allowed parameters to a filter function

* o/devicestate: filter out unallowed arguments when building the kernel cmdline

Filter arguments not allowed by the gadget.

* gadget: name return params in FilterKernelCmdline and add test cases

* overlord: address review comments

* gadget,overlord: address review comments
2023-03-07 17:48:17 +01:00
..
2017-01-11 10:19:50 +01:00
2022-05-11 11:27:06 +02:00

Generating model assertions

Test keys and developer accounts

Signed model assertions for use in the spread tests can be generated using gendeveloper1 tool. The assertion is signed by developer1 key, which is built-into the snapd binary used during the tests.

To build the tool:

$ go install ./tests/lib/gendeveloper1

Generating the assertions is done like this:

$ cd tests/lib/assertions
$ gendeveloper1 sign-model < developer1-pc-18.model.json > developer1-pc-18.model

The GPG of developer1 can be obtained with:

$ gendeveloper1 show-key

Valid keys and developer accounts

Some tests, particularly remodel, require valid model assertions that are signed by developer account keys known to the store. For instance, valid-for-testing-*.model files are such assertions. There is a corresponding *.json file for each of the assertions. The models were signed by one of snapd developers using their private keys.

When there is a need to regenerate the assertions and sign them again using a different set of keys be sure to update both authority-id and brand-id in each of the json files. Then follow the procedure outlined in the Ubuntu Core docs https://ubuntu.com/core/docs/custom-images#heading--signing which boils down to:

$ snap create-key my-models
$ snapcraft register-key
$ snap sign -k my-models < valid-for-testing-some-file.json > valid-for-testing-some-file.model

The value for authority-id and brand-id, is the same as the developer-id which can be obtained by running:

$ snapcraft login
$ snapcraft whoami
email:        <your-email>@...
developer-id: <your-developer-id>