Kamil Szczęk

Yeah we could use the type checking with Object. Actually while changing dynamics to Objects I've found a potential bug with the remove method because of the dynamic type.

Yeah, I agree with keeping the filtering mechanism agnostic, although we still could make it easier for developers to add their own filter implementations, for example we could remove the...

plus this is technically an agnostic approach, because there is no implementation, so we would still be compliant with JSON:API specs, although maybe we could keep some sample filter implementations...

## Example configuration/use case ### `/usr/local/bin/get-secret` ```bash #!/bin/bash echo -n "secret" ``` ### `/etc/dracut.conf.d/get-secret.conf` ```plaintext install_items+=" /usr/local/bin/get-secret " ``` ### `/etc/systemd/system/root-volume-key.socket` ```plaintext [Unit] Description=Root Volume Key Socket DefaultDependencies=no Conflicts=multi-user.target shutdown.target...

Commenting to keep this open. Also opened a PR in the fork: https://github.com/dracut-ng/dracut-ng/pull/257

Force pushed to fix the commit message and shell lint issues.

BTW, if you're concerned about cold boot attacks, then an attacker would probably not perform a graceful shutdown, thus rendering all those protective measures useless as they're executed only on...

Overlooked an issue with the default value for PKCS#11 tokens, fixed it. Sorry for the noise.

After performing some additional tests with `strace -e add_key,request_key,keyctl` I've discovered that currently the cache behavior is somewhat inconsistent. When attempting to unlock with a TPM2 device via token plugin...

There actually is a way to get multiple PIN attempts when unlocking with a TPM2 device, but you have to use the **non-plugin** execution path. Currently `systemd-cryptsetup` maintains two code...