Hi Dan, The customer is using an air-gapped landscape mirror and a gpg key that they've generated. Our test environment doesn't have a landscape archive mirror to test with so to simulate the workflow of providing a custom mirror and key we are using the plug mirror and its gpg key. Particularly to investigate curtin's behaviour with writing a key to ubuntu.sources and apt recognizing said key as a trusted key.
I didn't explain myself well in the previous response but you're right that the two configs I shared accomplish different things and achieve different goals. The first config sources: localrepokey: key: | <key> creates an ascii-armored key at /etc/apt/trusted.gpg.d/localrepokey.asc, which is the expected behaviour. The "problem" in this case is that it's not in ubuntu.sources so the requests to the primary and security mirrors fail. Though, this isn't an actual issue because we shouldn't expect the key in ubuntu.sources as we didn't modify the template. That's where the second config comes in If the key is provided in the sources_list template (and the sources section is removed), sources_list: | Types: deb URIs: http://plug-mirror.rcac.purdue.edu/ubuntu/ Suites: noble noble-updates noble-security Components: main universe restricted multiverse Signed-By: -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK----- the key is successfully written to ubuntu.sources, which is also expected. However, based on the NO_PUBKEY error, my understanding (feel free to correct me if this isn't correct) is that either the supplied key wasn't added to apt's trusted keys, or as you mentioned, the supplied key doesn't match the intended plug mirror key. The 871920D1991BC93C key in the config was obtained from here: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x871920d1991bc93c, which differs from the ascii output obtained when running gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 871920D1991BC93C followed by gpg --armor --export 871920D1991BC93C. Though, I don't believe there is an issue with the original key because apt update succeeds if that public key is dearmored to /etc/apt/trusted.gpg.d/localkey.gpg and the Signed-By field is modified to reflect that (Signed-By: /etc/apt/trusted.gpg.d/localkey.gpg). In any case, in the first config, apt becomes aware of the key, but we haven't modified the template. In the second, the template is updated, but apt doesn't have the key. So it seems that both fragments have to be used in the config but the install crashes if Signed-By is assigned any value other than the gpg key fingerprint. The following config works and can be extended by adding a security stanza to the template. Is this the intended approach to add a custom key to apt and reflect that in the ubuntu.sources? sources_list: | Types: deb URIs: $PRIMARY Suites: $RELEASE $RELEASE-updates $RELEASE-security Components: main universe restricted multiverse Signed-By: F6ECB3762474EDA9D21B7022871920D1991BC93C sources: localkey: key: | -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK----- -- https://code.launchpad.net/~bryanfraschetti/curtin/+git/curtin/+merge/476864 Your team curtin developers is subscribed to branch curtin:master. -- Mailing list: https://launchpad.net/~curtin-dev Post to : curtin-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~curtin-dev More help : https://help.launchpad.net/ListHelp
