Lennart Poettering
f7786f2508
This adds the following: 1. systemd-report gains a new --sign= option, taking a boolean. If true, this makes systemd-report generate + systemd-report upload generate a signed report, instead of a regular one. The signatures are collected from Varlink-based backends. 2. One such backend is added which does a simple Ed21159 based signing scheme. 3. this adds a new metrics source which just reports text files symlinked into a special dir as metrics. This is used to report the Ed21159 public key as metric, by default, if it exists. 4. finally, systemd-report itself is turned into a varlink service. this is useful for example for extracting a report from a system coming in via the varlink/http bridge. I thought a long time about the format of signing of reports. Initially i intended to do this like homed's user record signing, i.e. require normalization of the record, then normalize the record, and write it out in dense form, since the result. Finally insert the resulting hash into the user record itself. People have pointed me to the inherent messiness of signing JSON this way though, as it requires any participant that wishes to sign/authenticate records this way to implement the exact same normalization/formatting rules, and in particular in the area of floating point numbers (of which metrics presumably will have many) this is quite problematic. This signing hence goes a different way. instead of expecting signer+verifier to independently come to the same normalized text form of the json data, let's instead output a JSON-SEQ sequence, where the first object is the report, and any subsequent objects are one signature each. the signatures are supposed to cover the precise binary representation of the first element in the JSON-SEQ stream. (i.e. from the RS to the NL). or in other words: a verifier would receive the JSON-SEQ stream, split it up before each RS. Then it would leave object 1 unparsed for the moment, and parse objects 2…n. It would then authenticate object 1's precise binary representation with objects 2…n. Once that checks out, it would parse object 1, and use it as report.
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