Paul Meyer
9e7b8b734f
PID1's import_credentials_boot() so far always treated initrd-delivered credentials as untrusted: anything found under /.extra/credentials/ was routed into ENCRYPTED_CREDENTIALS_DIRECTORY, forcing consumers to use LoadCredentialEncrypted= and provide credentials in systemd-creds encrypted form. That matches the trust model for stub which sources credentials from the EFI System Partition (mountable and editable offline). Host-side producers that take responsibility for the trust of the cpio they hand to the kernel have a different model: e.g. systemd-vmspawn builds an initrd-credentials cpio whose bytes are covered by the SEV-SNP launch measurement via QEMU's kernel-hashes=on (or, in non-confidential setups, by the host itself being the trust root). Forcing those through the @encrypted bucket would require null-key wrapping on the host and LoadCredentialEncrypted= on the consumer side, a needless API split for unit files that should otherwise be portable between confidential and non-confidential boots. Extend import_credentials_boot() to import credentials from /.extra/system_credentials/, routed into SYSTEM_CREDENTIALS_DIRECTORY. Consumers access these via LoadCredential= directly, with no encrypted-credential ceremony. The per-directory walk is hoisted into a small static helper so the new target bucket can share the existing copy/validation logic; behavior for the existing untrusted paths is unchanged. Also set the new RECURSE_DIR_MUST_BE_REGULAR flag as a drive-by. Signed-off-by: Paul Meyer <katexochen0@gmail.com>
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release