Created attachment 56552 [details] [review]
patch for cryptsetup.c adding gpg option support
This patch adds the gpg option for /etc/crypttab and uses the existing ask-password-api. You must supply the path to the gpg file in the keyfile field of the /etc/crypttab file.
swap /dev/sda2 /mnt/usb/swap.gpg luks,gpg
Is that option known anywhere else?
This patch isn't really acceptable for a variety of reasons: it doesn't do any kind of OOM checking (or other kind of error control), and more importantly invoking shell commands via popen is nothing we ever want to do. This will also break on systems which have /usr split off. It's also highly fragile becuase p might include " chars and thus the echo will be broken.
Sorry, we just don't do stuff like this. This is only acceptable if it does proper error checking, uses libraries instead of external commands and is not vulnerable to escaping problems.
Also, please explain what exactly this option should accomplish. What is a "gpg file"?
Created attachment 57074 [details] [review]
rewrite of the patch using gpgme
This is a complete rewrite of the previous patch using gpgme.
This option allows for use of using gpg encrypted keyfiles versus the current plaintext keyfile. The encrypted keyfile is preferred because it adds another additional n-factor authentication to the keyfile. If someone took your keyfile then they can easily decrypt your drive.
The gpg file I was referring to is actually an asc file is the output of dd if=/dev/random count=1 | gpg --symmetric -a > test.gpg. The file must be in ascii armor format (-a option). Currently at this time on my mini prototype that the unarmored ascii protected binary is getting killed. I will be looking into why.
Created attachment 57189 [details] [review]
gpgme patch cleanup
cleanup of 57074 removing extra variable.
I can confirm that armored (asc) and non-armored (gpg) files should work. I found out that my testing code was outdated due to the misplacement of creation of gpgme data buffers that caused the segmentation faults.