Bug 45559

Summary: RFE: Add gpg option for /etc/crypttab
Product: systemd Reporter: Orson Teodoro <orsonteodoro>
Component: generalAssignee: Lennart Poettering <lennart>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: medium CC: seschwar
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: patch for cryptsetup.c adding gpg option support
rewrite of the patch using gpgme
gpgme patch cleanup

Description Orson Teodoro 2012-02-02 11:22:06 UTC
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.

/etc/crypttab:
swap	/dev/sda2	/mnt/usb/swap.gpg	luks,gpg
Comment 1 Lennart Poettering 2012-02-10 15:39:36 UTC
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"?
Comment 2 Orson Teodoro 2012-02-15 02:39:50 UTC
Created attachment 57074 [details] [review]
rewrite of the patch using gpgme

This is a complete rewrite of the previous patch using gpgme.
Comment 3 Orson Teodoro 2012-02-15 03:11:34 UTC
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.
Comment 4 Orson Teodoro 2012-02-17 00:10:50 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.