Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement]: Apt Keyring Location Should Be Configurable #5952

Open
RiverHeart opened this issue Jan 7, 2025 · 0 comments
Open

[enhancement]: Apt Keyring Location Should Be Configurable #5952

RiverHeart opened this issue Jan 7, 2025 · 0 comments
Labels
enhancement New feature or request new An issue that still needs triage

Comments

@RiverHeart
Copy link

Enhancement

Cloud-init is very nice for bootstrapping a machine before running desired state utilities against it, in particular, repositories to ensure tooling is available before a script/program runs. For ongoing management of those repositories I'd like to standardize the location of the apt keys with ones I'll add outside of the purview of cloud-init. Right now, the apt module hard codes CLOUD_INIT_GPG_DIR to a special folder. For semi-trusted keyrings, there seems to be some consensus around placing them in /etc/apt/keyrings or /usr/share/keyrings.

CLOUD_INIT_GPG_DIR = "/etc/apt/cloud-init.gpg.d/"

I thought I might be able to specify the path to the key but looking at the source but it doesn't seem like it parses the source for signed-by. Just a binary choice between the special folder and trusted folder.

key_dir = (
CLOUD_INIT_GPG_DIR if hardened else APT_TRUSTED_GPG_DIR
)

Is there a technical reason for placing them in their own directory? It would be really nice if there were an apt::keyring_dir property to override the default value. :)

@RiverHeart RiverHeart added enhancement New feature or request new An issue that still needs triage labels Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request new An issue that still needs triage
Projects
None yet
Development

No branches or pull requests

1 participant