Bug 45559 - RFE: Add gpg option for /etc/crypttab
Summary: RFE: Add gpg option for /etc/crypttab
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Lennart Poettering
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-02 11:22 UTC by Orson Teodoro
Modified: 2012-08-29 11:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch for cryptsetup.c adding gpg option support (3.86 KB, patch)
2012-02-02 11:22 UTC, Orson Teodoro
Details | Splinter Review
rewrite of the patch using gpgme (8.55 KB, patch)
2012-02-15 02:39 UTC, Orson Teodoro
Details | Splinter Review
gpgme patch cleanup (8.62 KB, patch)
2012-02-17 00:10 UTC, Orson Teodoro
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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.