v253 batch #399
Merged
v253 batch #399
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If we request a DS and the resolver offers an unsigned SOA, a new auxiliary transaction for the DS will be rejected as a loop, and we might not make any progress toward finding the DS we need. Let's ensure that we at least always check the parent in this case. Fixes: 4769063 ("resolved: don't request the SOA for every dns label") (cherry picked from commit d840783) (cherry picked from commit 52c17fe) (cherry picked from commit 16c79fe)
Previously, sd-resolved unnecessarily requested SOA records for each dns label in the query, even though they are not needed for the chain of trust. Since 4769063, only the necessary records are queried when validating. This is actually a problem in allow-downgrade mode, since we will no longer attempt a query for a record that we know is signed a priori, and will therefore never update our belief about the state of dnssec support in the recursive resolver. Rectify this by reintroducing a query for the root zone SOA in the allow-downgrade case, specifically to test that the resolver attaches the RRSIGs which we know must exist. Fixes: 4769063 ("resolved: don't request the SOA for every dns label") (cherry picked from commit 5237ffd) (cherry picked from commit ee15f5e) (cherry picked from commit 2ecdb3f)
If the parent zone uses a non-opt-out method that provides authenticated negative DS replies, we still can't expect signatures from the child zone. sd-resolved was using the authenticated status of the DS reply to require signatures for CNAMEs, even though it had already proved that no signature exists. Fixes: 4769063 ("resolved: don't request the SOA for every dns label") (cherry picked from commit 414a9b8) (cherry picked from commit a158022) (cherry picked from commit 37662f9)
The current output of 'systemctl list-jobs' with the --after and/or --before switches seems backwards. With artificial units # check-oil.service [Unit] Description=Check the oil level Before=engine-ready.target # fill-gas.service [Unit] Description=Fill the tank with gasoline Before=engine-ready.target # engine-ready.target [Unit] Description=The engine is ready [Unit] Description=Start the engine! After=engine-ready.target Wants=engine-ready.target running 'systemctl list-jobs --before --after' produces JOB UNIT TYPE STATE 93 check-oil.service start running └─ waiting for job 94 (engine-ready.target/start) - - 102 fill-gas.service start running └─ waiting for job 94 (engine-ready.target/start) - - 94 engine-ready.target start waiting └─ waiting for job 111 (start-engine.service/start) - - └─ blocking job 93 (check-oil.service/start) - - └─ blocking job 102 (fill-gas.service/start) - - 111 start-engine.service start waiting └─ waiting for job 1 (multi-user.target/start) - - └─ blocking job 94 (engine-ready.target/start) - - Obviously, job 93 is not waiting for job 94, but rather blocking it. (cherry picked from commit dc3058e) (cherry picked from commit bf3e64f) (cherry picked from commit a0d974a)
If a user only presses ENTER when the PIN is requested (without actually typing
the PIN), an assertion is reached and no other unlock method is requested.
```
sh-5.2# systemctl status systemd-cryptsetup@cr_root
× systemd-cryptsetup@cr_root.service - Cryptography Setup for cr_root
Loaded: loaded (/etc/crypttab; generated)
Drop-In: /etc/systemd/system/systemd-cryptsetup@.service.d
└─pcr-signature.conf
Active: failed (Result: core-dump) since Thu 2024-04-25 08:44:30 UTC; 10min ago
Docs: man:crypttab(5)
man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
Process: 559 ExecStartPre=/usr/bin/pcr-signature.sh (code=exited, status=0/SUCCESS)
Process: 604 ExecStart=/usr/bin/systemd-cryptsetup attach cr_root /dev/disk/by-uuid/a8cbd937-6975-4e61-9120-ce5c03138700 none x-initrd.attach,tpm2-device=auto (code=dumped, signal=ABRT)
Main PID: 604 (code=dumped, signal=ABRT)
CPU: 19ms
Apr 25 08:44:29 localhost systemd[1]: Starting Cryptography Setup for cr_root...
Apr 25 08:44:30 localhost systemd-cryptsetup[604]: Assertion '!pin || pin_size > 0' failed at src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-tpm2.c:60, function cryptsetup_token_open_pin(). Aborting.
Apr 25 08:44:30 localhost systemd[1]: systemd-cryptsetup@cr_root.service: Main process exited, code=dumped, status=6/ABRT
Apr 25 08:44:30 localhost systemd[1]: systemd-cryptsetup@cr_root.service: Failed with result 'core-dump'.
Apr 25 08:44:30 localhost systemd[1]: Failed to start Cryptography Setup for cr_root.
```
In this case, `cryptsetup_token_open_pin()` receives an empty (non-NULL) `pin`
with `pin_size` equals to 0.
```
🔐 Please enter LUKS2 token PIN:
Breakpoint 3, cryptsetup_token_open_pin (cd=0x5555555744c0, token=0, pin=0x5555555b3cc0 "", pin_size=0, ret_password=0x7fffffffd380,
ret_password_len=0x7fffffffd378, usrptr=0x0) at ../src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-tpm2.c:42
42 void *usrptr /* plugin defined parameter passed to crypt_activate_by_token*() API */) {
(gdb) continue
Assertion '!pin || pin_size > 0' failed at src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-tpm2.c:60, function cryptsetup_token_open_pin(). Aborting.
```
(cherry picked from commit 5cef6b5)
(cherry picked from commit 723a7c8)
(cherry picked from commit 8ca0368)
LinkLocalAddressing accepts a boolean. This can be seen by looking at `link_local_address_family_from_strong(cont char *s)` in `src/network/netword-util.c#L102-108` which falls back to `address_family_from_string`, defined two lines above (L100) using `DEFINE_STRING_TABLE_LOOKUP_WITH_BOOLEAN`. (cherry picked from commit 07b6924) (cherry picked from commit 586e10f) (cherry picked from commit 2b822b9)
If the file was removed by some other program, we should just go to the next one without failing. item_do() is only used for recursive globs instead of fixed paths so skipping on missing files makes sense (unlike if the path was fixed where we should probably fail). Fixes #32691 (hopefully) (cherry picked from commit 677430b) (cherry picked from commit 4641952) (cherry picked from commit 3abc0cb)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.