Adrian Reber
0cb06c715a
Secrets sealed to the SRK, e.g. via the --tpm2-device-key= switch of systemd-cryptenroll and systemd-repart, can only be unsealed by the TPM the SRK lives in, and sealing needs no access to that TPM. With the SRK certified by the attestation key, a verifier of the report hence has a public key it can trust to encrypt data for the reporting system specifically. Since TPM2_Clear replaces the SRK, a certification of the same SRK in a later report also shows that the TPM has not been cleared in between. Certify the SRK with each signing key, and provide its public area as TSS2 JSON, like the signing key's. Marshalled into a TPM2B_PUBLIC this is what --tpm2-device-key= consumes. If there is no SRK one is created, like systemd-cryptenroll does. Whatever sits at the SRK handle is certified. Judging its attributes is up to the verifier, and whether it can be authorized with a password session is left to TPM2_Certify. The one exception is noDA: an object without it with an auth value we don't know would count every failed attempt towards the TPM's dictionary attack lockout, and reports are requested repeatedly, so such an object is not certified at all. Apart from that we only make sure up front that we can calculate the name and encode the public area, so that a pre-existing SRK we cannot handle doesn't fail the whole report, and hand the vetted public area to the report generator, so that an object swapped in at the handle afterwards fails the name check rather than being certified. Failing to acquire the SRK is not fatal either, the report is still useful without the certification.
System and Service Manager
Details
Most documentation is available on systemd's website.
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