[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#393363: marked as done (loop-aes-utils: Common loop-AES configuration file for initramfs creators)

Your message dated Sat, 25 Aug 2012 12:03:15 +0000
with message-id <E1T5F59-0001xb-7t@franck.debian.org>
and subject line Bug#680748: Removed package(s) from unstable
has caused the Debian Bug report #393363,
regarding loop-aes-utils: Common loop-AES configuration file for initramfs creators
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

393363: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393363
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: loop-aes-utils
Version: 2.12r-14
Severity: wishlist


concerning full loop-AES support for yaird (and for initramfs-tools),
I would like to discuss the idea of a common configuration file for
loop-AES devices.

First of all, why could an extra config file be needed?

The problem with loop-AES devices is that most, but not all device
attributes required to set up a device with losetup can also be
retrieved by calling losetup (i.e. with 'losetup -a'). More specifically,
losetup output can not be used to gain information about the GPG key file
used for (possibly multi-key mode) encryption.

An existing solution is to describe a loop device with a loop= option
for the underlying device in fstab, along with gpgkey= and optionally
gpghome= options.

However, such an fstab entry is only feasible for loop devices which are
directly mounted (i.e. /dev/hda3 => /dev/loop0 => "/home"), but fails to
work for more complex setups in which loop devices are not mounted, like
using an encrypted loop-AES device as a physical LVM volume.

For yaird, I recently wrote full loopback and loop-AES device support.
As to handling GPG keys, there are two modes of operation, either
copying the GPG key (and optionally GPG home directory) to the initramfs
image, or mounting a device containing the key (and GPG home directory)
upon boot (comparable to the build-init.sh script accompanying

This code handles every corner case one could think of regarding loop-AES
devices, but there exists a (at least to me) major design flaw with the
code (which is also the reason why I was not yet confident to publish it
to the yaird list or BTS):

In order to solve the above dilemma with GPG keys, a new config option
(or more precisely a goal) had to be introduced, which specifies for
each GPG key encrypted loop-AES device
* the loop device (i.e. /dev/loop0),
* an absolute GPG key path (compare gpgkey= fstab option),
* optionally, a GPG home directory (compare gpghome= fstab option),
* and optionally, a mount point on the initramfs image, if the key device
  is to be mounted upon boot (instead of copying the key to the image).

This works very well, but does shows its weaknesses when running yaird
in --test mode (where the config file is not read and thus yaird does
not have the required information about keys), and more importantly:
It is a *serious abuse* of the yaird config file. Device configuration
info should never be located in an initramfs creator config file, but
instead gained from a device-specific config file or tool (e.g. mdadm,
cryptsetup and /etc/crypttab, (pv|vg|lv)display, ...).

Finally, this is where my idea for a loop-AES config file comes in.

I propose to have a file (named something like '/etc/loopaestab' or
maybe '/etc/default/loopaes') with the loop-aes-utils package, that
fully describes every loop-AES device for which the configuration
cannot be derived from losetup output or fstab.

The format could be modeled after /etc/crypttab, for example:

  # <target name>  <source device>  <options>
  /dev/loop5       /dev/md0         encryption=AES256,gpgkey=/etc/keys/root.gpg

The following options would be supported:

- offset=...,  sizelimit=...,  encryption=..., loinit=...

  These options can also be parsed from losetup output, and would
  strictly have to match with the actual loop device configuration.

- pseed=..., phash=..., itercountk=...

  These options should be available for completeness only.

  An initramfs creator seeing these options would probably fail
  with an "unsupported option" message: We do not ever want to encrypt
  root filesystems with random keys, for example.

- gpgkey=..., gpghome=...

  These are the options we are so desperately trying to retrieve.

- gpgmount

  This option would be the only loop-AES losetup unrelated option.

  If the keyword "gpgmount" is specified, the initramfs creator is
  instructed to mount the (unencrypted) device which contains the GPG
  key [gpgkey=...] (and optionally GPG home directory [gpghome=...])
  upon boot.

  If the keyword "gpgmount" is not specified, the GPG key (and
  optionally GPG home directory) would be directly copied to the
  image by the initramfs creator.

This seems to be the most elegant solution, and the information about
loop-AES devices would be collected in a central place, and with a
package which it belongs to, namely loop-aes-utils.

It would also coexist peacefully with any potentially available
fstab entries: An initramfs creator would check for loop-AES info
* losetup output (partial description),
* /etc/fstab entries with a loop= option (full description) and
* /etc/loopaestab entries (full description),
and make sure that these match for each loop device.

Now, what do you think of this idea?

(I was not sure about where to send this first; it should maybe be
coordinated with at least the initramfs-tools and yaird maintainers.)


--- End Message ---
--- Begin Message ---
Version: 2.16.2-3+rm

Dear submitter,

as the package loop-aes-utils has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see http://bugs.debian.org/680748

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing

Debian distribution maintenance software
Luca Falavigna (the ftpmaster behind the curtain)

--- End Message ---

Reply to: