Control: reassign 975343 tang 7-1 Control: tags 975343 upstream Control: retitle 975343 tang: Race condition between keygen and update, resulting in "Key derivation key not available!" Control: severity 975343 important
Dominique Dumont wrote...
> $ echo foo | clevis encrypt tang '{"url": "http://192.168.1.14"}' > bar.txt
> The advertisement contains the following signing keys:
>
> jvCF5[...]8s5A
>
> Do you wish to trust these keys? [ynYN] y
> Key derivation key not available!
Okay, here's the story: tangd-keygen creates two files in /var/db/tang/, the
second one containing '(...)"key_ops":["deriveKey"](...)'. In parallel,
tangd-update takes all the files in that directory to build (among
other) /var/cache/tang/default.jws. Now if tangd-keygen hasn't finished
the job yet, the second one is not taken into account, and this happens
on slower hardware.
Possibly upstream was in the assumption the multiple After=... in
tangd.socket are being started serialized, not in parallel.
You can check your situation using the following command:
jq -r .payload </var/cache/tang/default.jws | base64 -d -i | jq .
There must be two elements in the top-level "keys" list, one having an
element '(...)"key_ops":["deriveKey"](...)' as above.
Workaround to get a working setup:
* Back up files in /var/cache/tang/, just in case.
* Re-run tangd-update, the command
systemctl restart tangd-update.service
should do the trick. Else manually something like
$(which /usr/lib/*/tangd-update) /var/db/tang /var/cache/tang
This will see a fix in stable (10, "buster") as well.
Christoph
signature.asc
Description: PGP signature
