<div dir="ltr"><div><div><div><div><div>Hi, this might seem like an odd request but I'm currently trying to port clevis (<a href="https://github.com/latchset/clevis">https://github.com/latchset/clevis</a>) to initramfs, and right now I have run into a bit of a problem.<br><br></div>In short, there isn't really a 'good' way to wait for the password request from the cryptroot script and act upon it: right now, I have been using a subshell with a loop and sleep calls to check to see if the ask-for-password/askpass processes are running, and if they are to scrape and find which disk they are attempting to unlock, before piping the correct password to /lib/cryptsetup/passfifo.<br><br></div>It WORKS, but it's somewhat kludgy, and #debian-kernel recommended (more than once!) to talk to the cryptsetup team to discuss what you thought I should do.<br><br></div>One problem with the way it works now (Of course discarding the whole subshell business and how I have to grep ps and then /proc/pid/cmdline to get the disk path) is that if clevis fails to get the password and the user enters a password manually, then after a while the script will close out the subshell saying that sleep can't be found. I did set it up so that I use set -e in the subshell (clevis itself already uses bash, so there isn't really a problem with importing that to initramfs) so it doesn't SPAM it, but I'd still rather avoid it.<br><br></div>I'll be honest, even with edits I can't really see any way to avoid a subshell, but I am somewhat new to this kind of thing and it would be nice to have the clevis project properly packaged for debian and derivatives, so I want to make a good faith in getting it working in a proper fashion.<br></div><div><br></div><div>Here's the script that I have thus far if you want to see how it works.<br><br><a href="https://github.com/ShaRose/clevis/blob/master/src/initramfs/clevis-script">https://github.com/ShaRose/clevis/blob/master/src/initramfs/clevis-script</a><br></div><div><br>Just as a short description, clevis-luks works by storing an encrypted JWE containing a password which is added to the luks container, and then storing this in luks metadata using the luksmeta project (<a href="https://github.com/latchset/luksmeta">https://github.com/latchset/luksmeta</a>). When clevis runs, it uses luksmeta to get the JWE and then attempts to decrypt it. The decryption can require a few different pins: the contents of an http page, or use a tang server (<a href="https://github.com/latchset/tang">https://github.com/latchset/tang</a>), or even use shamir's secret sharing so that N pins are required to decrypt the password. Long story short: If the server boots and can access the right servers, then it can unlock itself automatically, sort of like how bitlocker can do a network unlock.<br></div></div>