Debian Bug report logs - #866786
unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sat, 01 Jul 2017 13:35:20 -0400

Package: cryptsetup
Version: 2:1.7.3-4
Severity: wishlist

I have multiple crypto partitions I need to unlock when the machine
starts up. I use the dropbear-initramfs hack to unlock those
remotely. Unfortunately, the current implementation in
"cryptroot-unlock" doesn't seem to handle multiple devices at once.

I used to have a custom initramfs script that would do that for me in
jessie, but since the stretch upgrade, it stopped working, and I'm not
exactly sure why: i just don't get the prompt on the SSH commandline
at all anymore when I run my script.

The normal "cryptroot-unlock" program doesn't work either for multiple
partitions.

Is this something that could be considered?

-- Package-specific info:

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin         2:1.7.3-4
ii  debconf [debconf-2.0]  1.5.61
ii  dmsetup                2:1.02.137-2
ii  libc6                  2.24-11+deb9u1

Versions of packages cryptsetup recommends:
ii  busybox                                 1:1.22.0-19+b3
ii  console-setup                           1.164
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kbd                                     2.0.3-2+b1

Versions of packages cryptsetup suggests:
ii  dosfstools              4.1-1
pn  keyutils                <none>
ii  liblocale-gettext-perl  1.07-3+b1

-- debconf information excluded

Message #10 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: 866786@bugs.debian.org

Subject: Re: Bug#866786: Acknowledgement (unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking))

Date: Sat, 01 Jul 2017 14:00:19 -0400

Some more information. Attached is the script I originally used.

Here's the output of an interactive SSH session where I try to unlock
the device(s) using the normal cryptroot-unlock command:

[1002]anarcat@curie:~255$ unlock-marcos 
To unlock root partition, and maybe others like swap, run `cryptroot-unlock`
To unlock root-partition run unlock


BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # cryptroot-unlock 
Please unlock disk Crucial_CT480M500SSD1-crypto: 

cryptsetup: Crucial_CT480M500SSD1-crypto set up successfully
~ # 
~ # 
~ # Connection to 192.168.0.3 closed by remote host.
Connection to 192.168.0.3 closed.

cryptsetup lied: at this point there's still a password prompt
(plymouth) on the console, which I need to fill in.

Message #15 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Acknowledgement (unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking))

Date: Sat, 1 Jul 2017 21:11:29 +0200

[Message part 1 (text/plain, inline)]

On Sat, 01 Jul 2017 at 14:00:19 -0400, Antoine Beaupré wrote:
> Some more information. Attached is the script I originally used.

Looks like you forgot the attachement :-P

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupre <anarcat@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sat, 1 Jul 2017 21:10:37 +0200

[Message part 1 (text/plain, inline)]

Hi Antoine,

On Sat, 01 Jul 2017 at 13:35:20 -0400, Antoine Beaupre wrote:
> I used to have a custom initramfs script that would do that for me in
> jessie, but since the stretch upgrade, it stopped working, and I'm not
> exactly sure why: i just don't get the prompt on the SSH commandline
> at all anymore when I run my script.

Could actually be a problem with dropbear's hook scripts.  From 2015.68-1's
changelog:

    + Bring down interfaces and flush IP routes and addresses before exiting
      the ramdisk, to avoid dirty network configuration in the regular kernel.
      (Closes: #715048, #720987, #720988.)  The interfaces considered are
      those matching the $DROPBEAR_IFDOWN shell pattern (default: '*'); the
      special value 'none' keeps all interfaces up and preserves routing
      tables and addresses.

But that script is run at local-bottom stage, so just after the local root FS
has been mounted.  (At the time I chose it rather than init-bottom because for
NFS mounts you clearly don't want to bring down the interface ;-)  Since
devices needed to mount / are the first ones to be unlocked, the network
interface is brought down before you have a chance to remotely type in your
password for other devices :-/

Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
solves your problem?  Please file a bug against dropbear-initramfs if it does.

> The normal "cryptroot-unlock" program doesn't work either for multiple
> partitions.

That's something which would be nice to have, indeed.  In principle it should
work (at least if the network interface was up) if you were to reconnect for
each disk, but I see some benefits in using the same script for all passphrase
prompts ;-)  I'll need to test this, but AFAICT a while loop would be enough as
dropbear's cleanup script kills the sshd and all its children (hence the script
itself) at init-bottom stage.

Cheers,
-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sat, 01 Jul 2017 16:10:01 -0400

On 2017-07-01 21:10:37, Guilhem Moulin wrote:
> Hi Antoine,
>
> On Sat, 01 Jul 2017 at 13:35:20 -0400, Antoine Beaupre wrote:
>> I used to have a custom initramfs script that would do that for me in
>> jessie, but since the stretch upgrade, it stopped working, and I'm not
>> exactly sure why: i just don't get the prompt on the SSH commandline
>> at all anymore when I run my script.
>
> Could actually be a problem with dropbear's hook scripts.  From 2015.68-1's
> changelog:
>
>     + Bring down interfaces and flush IP routes and addresses before exiting
>       the ramdisk, to avoid dirty network configuration in the regular kernel.
>       (Closes: #715048, #720987, #720988.)  The interfaces considered are
>       those matching the $DROPBEAR_IFDOWN shell pattern (default: '*'); the
>       special value 'none' keeps all interfaces up and preserves routing
>       tables and addresses.
>
> But that script is run at local-bottom stage, so just after the local root FS
> has been mounted.  (At the time I chose it rather than init-bottom because for
> NFS mounts you clearly don't want to bring down the interface ;-)  Since
> devices needed to mount / are the first ones to be unlocked, the network
> interface is brought down before you have a chance to remotely type in your
> password for other devices :-/
>
> Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
> solves your problem?  Please file a bug against dropbear-initramfs if it does.

It doesn't: the script still kills my shell and dropbear unwraps
everything and kills itself as well. I then have a password prompt on
the console and no ssh access from the outside.

I am *guessing* that systemd may do the right thing next: in theory, the
system *can* start without that partition (it's /srv), or at least the
real sshd and then I could login and unlock the other partition. But on
my first try, this is not what happened, at least I wasn't patient
enough to let the machine go down any longer...

But that's my current use case: it would be a perfectly legitimate use
case to have /, /usr and /var in three different LUKS filesystems, in
which case the current configuration would just fail completely.

>> The normal "cryptroot-unlock" program doesn't work either for multiple
>> partitions.
>
> That's something which would be nice to have, indeed.  In principle it should
> work (at least if the network interface was up) if you were to reconnect for
> each disk, but I see some benefits in using the same script for all passphrase
> prompts ;-)  I'll need to test this, but AFAICT a while loop would be enough as
> dropbear's cleanup script kills the sshd and all its children (hence the script
> itself) at init-bottom stage.

I tried to figure out how to do this myself, but ended up writing my own
shell script with hardcoded defaults.

A.

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
                        - Aristote

Message #30 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Acknowledgement (unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking))

Date: Sat, 01 Jul 2017 16:15:59 -0400

[Message part 1 (text/plain, inline)]

On 2017-07-01 21:11:29, Guilhem Moulin wrote:
> On Sat, 01 Jul 2017 at 14:00:19 -0400, Antoine Beaupré wrote:
>> Some more information. Attached is the script I originally used.
>
> Looks like you forgot the attachement :-P

Typical.

Here's /etc/initramfs-tools/hooks/crypt_unlock.sh attached. It calls
cryptroot-unlock and then runs its own extra unlocking.

I haven't tested it recently so i don't remember exactly how it
fails. Maybe with the dropbear change it will work correctly...

A.
-- 
Twenty years from now you will be more disappointed by the things that
you didn't do than by the ones you did do. So throw off the bowlines.
Sail away from the safe harbor. Catch the trade winds in your sails.
Explore. Dream. Discover.  - Mark Twain

[crypt_unlock.sh (text/x-sh, inline)]

#!/bin/sh

# this script is designed to unlock partitions on marcos. rerun
# update-initramfs -u when changing. newer cryptsetup versions (1.7.x
# from stretch) may deal with this better, although by reading the
# cryptroot-unlock script, it doesn't look like it.

# some of this is cargo-culted from:
# https://stinkyparkia.wordpress.com/2014/10/14/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu-server-14-04-1-with-static-ipst/
# and /usr/share/doc/cryptsetup/README.remote.gz

# unfortunately, neither of those support multiple crypto devices: they unlock
# the first one and then systemd is stuck waiting for a passphrase for the
# other ones

PREREQ="dropbear"
# this should be autodetected
EXTRA_DISK="/dev/sdb2"
EXTRA_LABEL="4tb_crypt"

echo "setting up crypto unlock hook with extra $EXTRA_LABEL"

case "$1" in
    prereqs)
        echo $PREREQ
        exit 0
        ;;
esac

. "${CONFDIR}/initramfs.conf"
. /usr/share/initramfs-tools/hook-functions

if [ "${DROPBEAR}" != "n" ] && [ -r "/etc/crypttab" ] ; then
    cat > "${DESTDIR}/bin/unlock" << EOF
#!/bin/sh
if PATH=/lib/unlock:/bin:/sbin /scripts/local-top/cryptroot && /sbin/cryptsetup luksOpen "${EXTRA_DISK}" "${EXTRA_LABEL}"; then
kill \`ps | grep cryptroot | grep -v "grep" | awk '{print \$1}'\`
# following line kill the remote shell right after the passphrase has
# been entered.
kill -9 \`ps | grep "\-sh" | grep -v "grep" | awk '{print \$1}'\`
exit 0
fi
exit 1
EOF

    chmod 755 "${DESTDIR}/bin/unlock"

    mkdir -p "${DESTDIR}/lib/unlock"
    cat > "${DESTDIR}/lib/unlock/plymouth" << EOF
#!/bin/sh
[ "\$1" == "--ping" ] && exit 1
/bin/plymouth "\$@"
EOF

    chmod 755 "${DESTDIR}/lib/unlock/plymouth"

    echo To unlock root-partition run "unlock" >> ${DESTDIR}/etc/motd
fi

Message #35 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sat, 1 Jul 2017 23:16:32 +0200

[Message part 1 (text/plain, inline)]

On Sat, 01 Jul 2017 at 16:10:01 -0400, Antoine Beaupré wrote:
> On 2017-07-01 21:10:37, Guilhem Moulin wrote:
>> Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
>> solves your problem?  Please file a bug against dropbear-initramfs if it does.
> 
> It doesn't: the script still kills my shell and dropbear unwraps
> everything and kills itself as well. I then have a password prompt on
> the console and no ssh access from the outside.

Hmm odd, OTHO dropbear's shutdown script is very late.  From
initramfs-tools(8):

    init-bottom  are the last scripts to be executed before procfs and
    sysfs are moved to the real rootfs and execution is turned over to
    the init binary which should now be found in the mounted rootfs.
    udev is stopped.

I'm surprised that initramfs went so far in the init process while the
cryptroot script is still pending on a passphrase prompt.

Could you pass ‘debug’ to the kernel command line, then sanitize and
attach /run/initramfs/initramfs.debug?  Probably your /etc/crypttab and
/etc/fstab (at least the relevant lines) would be helpful, too.
 
> I am *guessing* that systemd may do the right thing next: in theory, the
> system *can* start without that partition (it's /srv), or at least the
> real sshd and then I could login and unlock the other partition. But on
> my first try, this is not what happened, at least I wasn't patient
> enough to let the machine go down any longer...
> 
> But that's my current use case: it would be a perfectly legitimate use
> case to have /, /usr and /var in three different LUKS filesystems, in
> which case the current configuration would just fail completely.

Unlike / and /usr, /var isn't needed at initramfs stage, so the
cryptsetup boot scripts won't try to unlock it early.  If for some
reason it needs to be mounted before systemd kicks in (for instance
because its lacking a crypttab(5) feature you need, such as keyscripts),
adding ‘initramfs’ to crypttab(5)'s 4th column should do the trick.
 
>>> The normal "cryptroot-unlock" program doesn't work either for multiple
>>> partitions.
>>
>> That's something which would be nice to have, indeed.  In principle it should
>> work (at least if the network interface was up) if you were to reconnect for
>> each disk, but I see some benefits in using the same script for all passphrase
>> prompts ;-)  I'll need to test this, but AFAICT a while loop would be enough as
>> dropbear's cleanup script kills the sshd and all its children (hence the script
>> itself) at init-bottom stage.
> 
> I tried to figure out how to do this myself, but ended up writing my own
> shell script with hardcoded defaults.

Same here.  Then I joined the cryptsetup and dropbear maintaining team,
and tried to make my solution generic enough to ship it along with the
packages ;-)

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sun, 2 Jul 2017 11:44:35 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 moreinfo

On Sat, 01 Jul 2017 at 23:16:32 +0200, Guilhem Moulin wrote:
> On Sat, 01 Jul 2017 at 16:10:01 -0400, Antoine Beaupré wrote:
>> On 2017-07-01 21:10:37, Guilhem Moulin wrote:
>>> Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
>>> solves your problem?  Please file a bug against dropbear-initramfs if it does.
>> 
>> It doesn't: the script still kills my shell and dropbear unwraps
>> everything and kills itself as well. I then have a password prompt on
>> the console and no ssh access from the outside.
> 
> Hmm odd, OTHO dropbear's shutdown script is very late.  From
> initramfs-tools(8):
> 
>    init-bottom  are the last scripts to be executed before procfs and
>    sysfs are moved to the real rootfs and execution is turned over to
>    the init binary which should now be found in the mounted rootfs.
>    udev is stopped.
> 
> I'm surprised that initramfs went so far in the init process while the
> cryptroot script is still pending on a passphrase prompt.

Actually I can't reproduce this (regardless of the value of
dropbear-initramfs' $IFDOWN variable).

    $ grep ^crypt_test /etc/crypttab
    crypt_test  UUID=113eb3e1-8342-4f9e-86d6-17af3d976cd4 none luks,initramfs

At boot time, when dropbear starts I'm able to unlock both my root FS
and crypt_test using `cryptroot-unlock` twice.

    ~ # cryptroot-unlock 
    Please unlock disk luksRoot: 
    cryptsetup: luksRoot set up successfully
    ~ # cryptroot-unlock 
    Please unlock disk crypt_test: 
    cryptsetup: crypt_test set up successfully
    ~ # packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe

> Could you pass ‘debug’ to the kernel command line, then sanitize and
> attach /run/initramfs/initramfs.debug?  Probably your /etc/crypttab and
> /etc/fstab (at least the relevant lines) would be helpful, too.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>, 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sun, 02 Jul 2017 17:03:53 -0400

On 2017-07-02 11:44:35, Guilhem Moulin wrote:
> Control: tag -1 moreinfo
>
> On Sat, 01 Jul 2017 at 23:16:32 +0200, Guilhem Moulin wrote:
>> On Sat, 01 Jul 2017 at 16:10:01 -0400, Antoine Beaupré wrote:
>>> On 2017-07-01 21:10:37, Guilhem Moulin wrote:
>>>> Does setting “IFDOWN=none” (the option was latter renamed) in /etc/dropbear-initramfs/config 
>>>> solves your problem?  Please file a bug against dropbear-initramfs if it does.
>>> 
>>> It doesn't: the script still kills my shell and dropbear unwraps
>>> everything and kills itself as well. I then have a password prompt on
>>> the console and no ssh access from the outside.
>> 
>> Hmm odd, OTHO dropbear's shutdown script is very late.  From
>> initramfs-tools(8):
>> 
>>    init-bottom  are the last scripts to be executed before procfs and
>>    sysfs are moved to the real rootfs and execution is turned over to
>>    the init binary which should now be found in the mounted rootfs.
>>    udev is stopped.
>> 
>> I'm surprised that initramfs went so far in the init process while the
>> cryptroot script is still pending on a passphrase prompt.
>
> Actually I can't reproduce this (regardless of the value of
> dropbear-initramfs' $IFDOWN variable).
>
>     $ grep ^crypt_test /etc/crypttab
>     crypt_test  UUID=113eb3e1-8342-4f9e-86d6-17af3d976cd4 none luks,initramfs
>
> At boot time, when dropbear starts I'm able to unlock both my root FS
> and crypt_test using `cryptroot-unlock` twice.
>
>     ~ # cryptroot-unlock 
>     Please unlock disk luksRoot: 
>     cryptsetup: luksRoot set up successfully
>     ~ # cryptroot-unlock 
>     Please unlock disk crypt_test: 
>     cryptsetup: crypt_test set up successfully
>     ~ # packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe

Oh. Interesting. For some reason I didn't think I could call the unlock
script multiple times!!!

By adding "initramfs" to my crypttab, I can succesfully unlock both
devices by calling the script multiple times.

Maybe what is needed then is simply a patch to the motd to warn the user
the command may need to be called multiple times? Or just loop over the
devices as you suggested before?

Thanks for the tip, it certainly works around the issue for me right
now. I think we would at least need to fix the documentation before this
is completely resolved however.

A.

-- 
Premature optimization is the root of all evil
                        - Donald Knuth

Message #52 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sun, 2 Jul 2017 23:16:22 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 = pending

On Sun, 02 Jul 2017 at 17:03:53 -0400, Antoine Beaupré wrote:
> Maybe what is needed then is simply a patch to the motd to warn the user
> the command may need to be called multiple times? Or just loop over the
> devices as you suggested before?

I have implemented the later already :-)  Not super happy about it as it
relies on dropbear to clean up the session properly (also implemented,
should be in dropbear-initramfs 2017.75-2), but it does the job.

By the way adding a command= authorized_keys(5) option works fine, too
:-)

    $ sudo sed -nr 's/\s.*//p' /etc/dropbear-initramfs/authorized_keys 
    no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #59 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: [pkg-cryptsetup-devel] Bug#866786: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sun, 02 Jul 2017 17:33:00 -0400

On 2017-07-02 23:16:22, Guilhem Moulin wrote:
> Control: tag -1 = pending
>
> On Sun, 02 Jul 2017 at 17:03:53 -0400, Antoine Beaupré wrote:
>> Maybe what is needed then is simply a patch to the motd to warn the user
>> the command may need to be called multiple times? Or just loop over the
>> devices as you suggested before?
>
> I have implemented the later already :-)  Not super happy about it as it
> relies on dropbear to clean up the session properly (also implemented,
> should be in dropbear-initramfs 2017.75-2), but it does the job.
>
> By the way adding a command= authorized_keys(5) option works fine, too
> :-)
>
>     $ sudo sed -nr 's/\s.*//p' /etc/dropbear-initramfs/authorized_keys 
>     no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"

ah that's neat too. the only problem is it won't work until that
workaround of yours is shipped... in stretch, in my case! ;)

do i still need the IFDOWN=none hack now? i feel that i won't be able to
run the unlock script multiple times if i remove that tweak...

a.

-- 
Use for yourself little but give to others much.
                       - Albert Einstein

Message #64 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: Bug#866786: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Sun, 2 Jul 2017 23:42:37 +0200

[Message part 1 (text/plain, inline)]

On Sun, 02 Jul 2017 at 17:33:00 -0400, Antoine Beaupré wrote:
> On 2017-07-02 23:16:22, Guilhem Moulin wrote:
>> Control: tag -1 = pending
>>
>> On Sun, 02 Jul 2017 at 17:03:53 -0400, Antoine Beaupré wrote:
>>> Maybe what is needed then is simply a patch to the motd to warn the user
>>> the command may need to be called multiple times? Or just loop over the
>>> devices as you suggested before?
>>
>> I have implemented the later already :-)  Not super happy about it as it
>> relies on dropbear to clean up the session properly (also implemented,
>> should be in dropbear-initramfs 2017.75-2), but it does the job.
>>
>> By the way adding a command= authorized_keys(5) option works fine, too
>> :-)
>>
>>  $ sudo sed -nr 's/\s.*//p' /etc/dropbear-initramfs/authorized_keys 
>>  no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"
> 
> ah that's neat too. the only problem is it won't work until that
> workaround of yours is shipped... in stretch, in my case! ;)

That should already work, but to execute the script twice you'll need to
connect twice to the remote host.
 
> do i still need the IFDOWN=none hack now? i feel that i won't be able to
> run the unlock script multiple times if i remove that tweak...

That should still work because the cryptoot boot script is run at
local-top and local-block time, while the network is currently brought
down afterwards (local-bottom) and dropbear is killed last
(init-bottom).

Unfortunately this means that if your shell is still open when the
network goes away, the SSH connection will hang until it timeouts.  But
if you issue two SSH connections (with a forced command) you shouldn't
have this problem as the command should have time to exit properly.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #69 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 866786@bugs.debian.org

Subject: Re: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Mon, 3 Jul 2017 23:21:25 +0200

[Message part 1 (text/plain, inline)]

On Sun, 02 Jul 2017 at 23:16:22 +0200, Guilhem Moulin wrote:
> On Sun, 02 Jul 2017 at 17:03:53 -0400, Antoine Beaupré wrote:
>> Maybe what is needed then is simply a patch to the motd to warn the user
>> the command may need to be called multiple times? Or just loop over the
>> devices as you suggested before?
> 
> I have implemented the later already :-)  Not super happy about it as it
> relies on dropbear to clean up the session properly (also implemented,
> should be in dropbear-initramfs 2017.75-2), but it does the job.

Actually I came up with a better solution that doesn't rely on the
behavior of dropbear.  It passes my tests, but perhaps you could try it
as well?  Then we won't have to go through this again after the Buster
release ;-)

To test the new script [0] you need to copy it (with mode +x) to
/usr/share/cryptsetup/initramfs/bin/cryptroot-unlock, update the
initramfs afterwards, and reboot (or hibernate + resume).

When its standard input is a TTY, the script should now wait until all
configured devices are unlocked, and prompt for passphrases when
required.  Since it exits on its own once it has detected that there is
nothing more to to, SSH sessions should be terminated cleanly (ie, no
hang), at least when there no shell involved.  (Well hang might still
occur as polling is racy, but it's merely convenience at stake and it
seems to work fine here with boot and resume.)

When its standard input is not a TTY the behavior is unchanged: the
whole standard input is dumped to the askpass FIFO, regardless of NUL
bytes or newlines (the TTY prompt above doesn't work with binary
passphrases), then the script exits.  Hence one needs to invoke it as
many times as there are devices to unlock.

-- 
Guilhem.

[0] https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/tree/debian/initramfs/cryptroot-unlock

[signature.asc (application/pgp-signature, inline)]

Message #74 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>, 866786@bugs.debian.org

Subject: Re: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Mon, 03 Jul 2017 19:08:52 -0400

On 2017-07-03 23:21:25, Guilhem Moulin wrote:
> On Sun, 02 Jul 2017 at 23:16:22 +0200, Guilhem Moulin wrote:
>> On Sun, 02 Jul 2017 at 17:03:53 -0400, Antoine Beaupré wrote:
>>> Maybe what is needed then is simply a patch to the motd to warn the user
>>> the command may need to be called multiple times? Or just loop over the
>>> devices as you suggested before?
>> 
>> I have implemented the later already :-)  Not super happy about it as it
>> relies on dropbear to clean up the session properly (also implemented,
>> should be in dropbear-initramfs 2017.75-2), but it does the job.
>
> Actually I came up with a better solution that doesn't rely on the
> behavior of dropbear.  It passes my tests, but perhaps you could try it
> as well?  Then we won't have to go through this again after the Buster
> release ;-)

Hehe.. That's a great idea! Any chance this could hit stretch as well?
Or would that be... stretching it? *rimshot*

> To test the new script [0] you need to copy it (with mode +x) to
> /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock, update the
> initramfs afterwards, and reboot (or hibernate + resume).

hibernate doesn't seem to work here for some reason, but rebooting works
perfectly. excellent job, thanks!

> When its standard input is a TTY, the script should now wait until all
> configured devices are unlocked, and prompt for passphrases when
> required.  Since it exits on its own once it has detected that there is
> nothing more to to, SSH sessions should be terminated cleanly (ie, no
> hang), at least when there no shell involved.  (Well hang might still
> occur as polling is racy, but it's merely convenience at stake and it
> seems to work fine here with boot and resume.)
>
> When its standard input is not a TTY the behavior is unchanged: the
> whole standard input is dumped to the askpass FIFO, regardless of NUL
> bytes or newlines (the TTY prompt above doesn't work with binary
> passphrases), then the script exits.  Hence one needs to invoke it as
> many times as there are devices to unlock.

from my perspective, I ssh into the box and call the script. it asks me
for the passwords one after the other without any noticable delay, than
the scripts exits and shortly after the ssh session is killed.

good job. :)

thanks, i guess this is done? or do we need to document the "initramfs"
tag in crypttab better?

a.

-- 
Soyons réalistes, faisons l'impossible.
                        - Ernesto "Che" Guevara

Message #79 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Tue, 4 Jul 2017 10:34:04 +0200

[Message part 1 (text/plain, inline)]

On Mon, 03 Jul 2017 at 19:08:52 -0400, Antoine Beaupré wrote:
> On 2017-07-03 23:21:25, Guilhem Moulin wrote:
>> Actually I came up with a better solution that doesn't rely on the
>> behavior of dropbear.  It passes my tests, but perhaps you could try it
>> as well?  Then we won't have to go through this again after the Buster
>> release ;-)
> 
> Hehe.. That's a great idea! Any chance this could hit stretch as well?
> Or would that be... stretching it? *rimshot*

Aha :-)  If there is enough interest I guess we could maintain a
backport as well.
 
>> When its standard input is a TTY, the script should now wait until all
>> configured devices are unlocked, and prompt for passphrases when
>> required.  Since it exits on its own once it has detected that there is
>> nothing more to to, SSH sessions should be terminated cleanly (ie, no
>> hang), at least when there no shell involved.  (Well hang might still
>> occur as polling is racy, but it's merely convenience at stake and it
>> seems to work fine here with boot and resume.)
>>
>> When its standard input is not a TTY the behavior is unchanged: the
>> whole standard input is dumped to the askpass FIFO, regardless of NUL
>> bytes or newlines (the TTY prompt above doesn't work with binary
>> passphrases), then the script exits.  Hence one needs to invoke it as
>> many times as there are devices to unlock.
> 
> from my perspective, I ssh into the box and call the script. it asks me
> for the passwords one after the other without any noticable delay, than
> the scripts exits and shortly after the ssh session is killed.

Great, thanks for the feedback!  The new workflow will be documented in
Sec. 8 “Remotely unlock encrypted rootfs” of README.Debian.

    https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/diff/debian/README.Debian?id=d80853c26f67a31c769e6fc1859803d9a602ca96
 
> thanks, i guess this is done? or do we need to document the "initramfs"
> tag in crypttab better?

Anything in particular you have in mind?  crypttab(5) currently reads:

    initramfs
        The initramfs hook processes the root device, any resume devices
        and any devices with the “initramfs” option set.  These devices
        are processed within the initramfs stage of boot.  As an
        example, that allows the use of remote unlocking using dropbear.

    […]
    keyscript
        The executable at the indicated path is executed with the key
        file from the third field of the crypttab as its only argument
        and the output is used as the key.  This also works with
        encrypted root filesystems via initramfs if the executable is
        self-contained (i.e. an executable which does not rely on any
        external program which is not present in the initramfs
        environment).
        […]
        WARNING: With systemd as init system, this option might be
        ignored.  At the time this is written (December 2016), the
        systemd cryptsetup helper doesn't support the keyscript option
        to /etc/crypttab.  For the time being, the only option to use
        keyscripts along with systemd is to force processing of the
        corresponding crypto devices in the initramfs.  See the
        'initramfs' option for further information.

See you at DebConf in a month, I guess ;-)
-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #84 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Guilhem Moulin <guilhem@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Tue, 04 Jul 2017 10:47:36 -0400

On 2017-07-04 10:34:04, Guilhem Moulin wrote:
> On Mon, 03 Jul 2017 at 19:08:52 -0400, Antoine Beaupré wrote:
>> On 2017-07-03 23:21:25, Guilhem Moulin wrote:
>>> Actually I came up with a better solution that doesn't rely on the
>>> behavior of dropbear.  It passes my tests, but perhaps you could try it
>>> as well?  Then we won't have to go through this again after the Buster
>>> release ;-)
>> 
>> Hehe.. That's a great idea! Any chance this could hit stretch as well?
>> Or would that be... stretching it? *rimshot*
>
> Aha :-)  If there is enough interest I guess we could maintain a
> backport as well.

That may make more sense yes.

>>> When its standard input is a TTY, the script should now wait until all
>>> configured devices are unlocked, and prompt for passphrases when
>>> required.  Since it exits on its own once it has detected that there is
>>> nothing more to to, SSH sessions should be terminated cleanly (ie, no
>>> hang), at least when there no shell involved.  (Well hang might still
>>> occur as polling is racy, but it's merely convenience at stake and it
>>> seems to work fine here with boot and resume.)
>>>
>>> When its standard input is not a TTY the behavior is unchanged: the
>>> whole standard input is dumped to the askpass FIFO, regardless of NUL
>>> bytes or newlines (the TTY prompt above doesn't work with binary
>>> passphrases), then the script exits.  Hence one needs to invoke it as
>>> many times as there are devices to unlock.
>> 
>> from my perspective, I ssh into the box and call the script. it asks me
>> for the passwords one after the other without any noticable delay, than
>> the scripts exits and shortly after the ssh session is killed.
>
> Great, thanks for the feedback!  The new workflow will be documented in
> Sec. 8 “Remotely unlock encrypted rootfs” of README.Debian.
>
>     https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/diff/debian/README.Debian?id=d80853c26f67a31c769e6fc1859803d9a602ca96

Excellent.

>> thanks, i guess this is done? or do we need to document the "initramfs"
>> tag in crypttab better?
>
> Anything in particular you have in mind?  crypttab(5) currently reads:
>
>     initramfs
>         The initramfs hook processes the root device, any resume devices
>         and any devices with the “initramfs” option set.  These devices
>         are processed within the initramfs stage of boot.  As an
>         example, that allows the use of remote unlocking using dropbear.

I did see that, but only after you mentioned it. I guess the problem is
the documentation is kind of split up all over the place. There's that
README.Debian, then there's:

 * /usr/share/doc/cryptsetup/README.initramfs.gz
 * "Some keyscripts have an own README file at
   /usr/share/doc/cryptsetup/"
 * crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8)
 * /usr/share/doc/cryptsetup/FAQ.gz
 * /usr/share/doc/dropbear-initramfs/README.initramfs

Which one is relevant here? Probably the last one? Who knows! :) In this
case, I should have read README.initramfs and crypttab(5) but even the
latter is not clearly outlined in Sec. 8 of the README.Debian...

>     […]
>     keyscript
>         The executable at the indicated path is executed with the key
>         file from the third field of the crypttab as its only argument
>         and the output is used as the key.  This also works with
>         encrypted root filesystems via initramfs if the executable is
>         self-contained (i.e. an executable which does not rely on any
>         external program which is not present in the initramfs
>         environment).
>         […]
>         WARNING: With systemd as init system, this option might be
>         ignored.  At the time this is written (December 2016), the
>         systemd cryptsetup helper doesn't support the keyscript option
>         to /etc/crypttab.  For the time being, the only option to use
>         keyscripts along with systemd is to force processing of the
>         corresponding crypto devices in the initramfs.  See the
>         'initramfs' option for further information.

Not sure how or if this applies to my current use case. :)

> See you at DebConf in a month, I guess ;-)

Definitely :)

A.

-- 
Le féminisme n'a jamais tué personne
Le machisme tue tous les jours.
                        - Benoîte Groulx

Message #89 received at 866786@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 866786@bugs.debian.org

Subject: Re: Bug#866786: unlock all crypto devices in cryptroot-unlock (remote SSH-based unlocking)

Date: Tue, 4 Jul 2017 19:02:24 +0200

[Message part 1 (text/plain, inline)]

On Tue, 04 Jul 2017 at 10:47:36 -0400, Antoine Beaupré wrote:
> On 2017-07-04 10:34:04, Guilhem Moulin wrote:
>> On Mon, 03 Jul 2017 at 19:08:52 -0400, Antoine Beaupré wrote:
>>> thanks, i guess this is done? or do we need to document the "initramfs"
>>> tag in crypttab better?
>>
>> Anything in particular you have in mind?  crypttab(5) currently reads:
>>
>>   initramfs
>>       The initramfs hook processes the root device, any resume devices
>>       and any devices with the “initramfs” option set.  These devices
>>       are processed within the initramfs stage of boot.  As an
>>       example, that allows the use of remote unlocking using dropbear.
> 
> I did see that, but only after you mentioned it. I guess the problem is
> the documentation is kind of split up all over the place.

Fair enough, the documentation needs some love…  Your setup is probably
not very common but if other DDs have trouble with our docs I'm not too
hopeful about wider adoption :-(

> There's that README.Debian, then there's:
> 
> * /usr/share/doc/cryptsetup/README.initramfs.gz
> * "Some keyscripts have an own README file at
>  /usr/share/doc/cryptsetup/"
> * crypttab(5), cryptdisks_start(8) and cryptdisks_stop(8)
> * /usr/share/doc/cryptsetup/FAQ.gz
> * /usr/share/doc/dropbear-initramfs/README.initramfs
> 
> Which one is relevant here? Probably the last one? Who knows! :)

Yup, and it contains the following paragraph:

Unlocking procedure
-------------------

You can unlock your rootfs on bootup remotely, using SSH to log in to
the booting system while it's running with the initramfs mounted.
Consult cryptsetup's /usr/share/doc/cryptsetup/README.Debian section 8
for details.

> In this case, I should have read README.initramfs and crypttab(5) but
> even the latter is not clearly outlined in Sec. 8 of the
> README.Debian...

Alright, I think I understood the source of the confusion now.  I'll add
a paragraph to clarify that in Sec. 8 applies to any device unlocked at
initramfs stage, not only the root device; and that to force the device
to be unlocked at initramfs stage one might need to add the 'initramfs'
option to its crypttab(5) entry.  I'll think about the wording over
night ;-)  Anyway, this is beyond of the scope of this bug.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #94 received at 866786-close@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: 866786-close@bugs.debian.org

Subject: Bug#866786: fixed in cryptsetup 2:1.7.5-1

Date: Thu, 14 Sep 2017 11:19:47 +0000

Source: cryptsetup
Source-Version: 2:1.7.5-1

We believe that the bug you reported is fixed in the latest version of
cryptsetup, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 866786@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guilhem Moulin <guilhem@debian.org> (supplier of updated cryptsetup package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 14 Sep 2017 13:00:23 +0200
Source: cryptsetup
Binary: cryptsetup cryptsetup-bin libcryptsetup4 libcryptsetup-dev cryptsetup-udeb libcryptsetup4-udeb
Architecture: source amd64
Version: 2:1.7.5-1
Distribution: unstable
Urgency: low
Maintainer: Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>
Changed-By: Guilhem Moulin <guilhem@debian.org>
Description:
 cryptsetup - disk encryption support - startup scripts
 cryptsetup-bin - disk encryption support - command line tools
 cryptsetup-udeb - disk encryption support - commandline tools (udeb) (udeb)
 libcryptsetup-dev - disk encryption support - development files
 libcryptsetup4 - disk encryption support - shared library
 libcryptsetup4-udeb - disk encryption support - shared library (udeb) (udeb)
Closes: 866786 870673
Changes:
 cryptsetup (2:1.7.5-1) unstable; urgency=low
 .
   * New upstream release 1.7.5.
   * cryptroot-unlock: When the standard input is a TTY, keep prompting for
     passphrases until there are no more devices to unlock. (Closes: #866786)
   * cryptsetup.prerm: Don't try to call `dmsetup table` to list dm-crypt
     devices when the dm_mod module isn't loaded. (Closes: #870673)
   * Rename upstream signing key from debian/upstream/signing-key.asc to
     debian/upstream-signing-key.asc in order to avoid lintian error
     orig-tarball-missing-upstream-signature" (we use the key to verify
     signature on upstrem's git tags).
   * Remove deprecated upstart configuration files: /etc/init/cryptdisks.conf
     and /etc/init/cryptdisks-udev.conf.  Cf. `lintian-info --tags
     package-installs-deprecated-upstart-configuration`.
   * debian/cryptsetup.{postinst,postrm}: Don't hard-code path to
     update-initramfs(1).
   * debian/rules: Include /usr/share/dpkg/pkg-info.mk to avoid parsing
     dpkg-parsechangelog(1) output.
   * debian/control: Bump Standards-Version to 4.0.0 (no changes necessary).
Checksums-Sha1:
 c7ae05edcdc9d8f5c7b0701c7e2adfa62ca71443 2704 cryptsetup_1.7.5-1.dsc
 d911ab6ac7df100e84b840c5a3bae9652e97f11b 914236 cryptsetup_1.7.5.orig.tar.xz
 032e53df45a51921cbd86f47574f9fc91300296e 94268 cryptsetup_1.7.5-1.debian.tar.xz
 560dde7372f0c5e9cd71e585049a5a5e2e678429 113534 cryptsetup-bin-dbgsym_1.7.5-1_amd64.deb
 5a92f17e0c640624eb0c8328402f6919eb3e556f 222770 cryptsetup-bin_1.7.5-1_amd64.deb
 bd0f4effd0a5773a398be19d82f4fd46087ab160 16964 cryptsetup-dbgsym_1.7.5-1_amd64.deb
 44a3a5540ca3c3960e4fc41e5f7ba614f78b6a03 39032 cryptsetup-udeb_1.7.5-1_amd64.udeb
 a46e392f8acfd390727565bf0e37c143f1a7d51a 8198 cryptsetup_1.7.5-1_amd64.buildinfo
 3aad89c2974868d8970156bb66e5efb6b97e8d66 177598 cryptsetup_1.7.5-1_amd64.deb
 6e2193d241617af503319cbb38408cee2c3779d5 55322 libcryptsetup-dev_1.7.5-1_amd64.deb
 effe9a5fbb4d1f51aae21e3dea5a7dd47cf1a06f 177640 libcryptsetup4-dbgsym_1.7.5-1_amd64.deb
 d6e3221083a6f0a287fb38a1a4aff662254d8e18 67480 libcryptsetup4-udeb_1.7.5-1_amd64.udeb
 a85522f8c615304f4db73476e96ec7ccf16d010e 110766 libcryptsetup4_1.7.5-1_amd64.deb
Checksums-Sha256:
 c0b69e595cff8682c030e36eec45239a008a7c59b4ee97f8c1f5cb1a0b454f52 2704 cryptsetup_1.7.5-1.dsc
 f305d55bd5f0228baa512c727690785c35e3c1ff978b5a8dd5ec5635b85ae9cc 914236 cryptsetup_1.7.5.orig.tar.xz
 6f73107694e4e9f7a6a0d2d54fc408f093db8773ed92f964c75516ab6a8965a0 94268 cryptsetup_1.7.5-1.debian.tar.xz
 0296acfd0609bb7878206cb516fcd93d7700436ab8bd8de5e2636b61d9687353 113534 cryptsetup-bin-dbgsym_1.7.5-1_amd64.deb
 8ef3ee4076626476ff5d83f07ad4d4d91d435a26170a7b0291a927865792287f 222770 cryptsetup-bin_1.7.5-1_amd64.deb
 4e46f6ed4f67f712461e372f7d94795192fa68e8f8af59ac1ea1fa0d4cc2df01 16964 cryptsetup-dbgsym_1.7.5-1_amd64.deb
 0b30fd1217d5d3a3068f3afc041d35cbb24f32e16bfaf24d51dedc734307c9f8 39032 cryptsetup-udeb_1.7.5-1_amd64.udeb
 2cb61fffcefaec45e00ae82be320ae5260153475d287dc0c493079bce395b2d2 8198 cryptsetup_1.7.5-1_amd64.buildinfo
 0d26af71a2a50b83329b0f39fde019571f835e7d9e88eb4775e6270271bd29a6 177598 cryptsetup_1.7.5-1_amd64.deb
 e7bd9f6c280e839ec60efda378fc6fd4d9eb4b20414c3ceffed4a644fc17192f 55322 libcryptsetup-dev_1.7.5-1_amd64.deb
 bd629767d1d7c9e820a681d3a141edf817ba12c385a24969d0e552d0d78683b2 177640 libcryptsetup4-dbgsym_1.7.5-1_amd64.deb
 1cc931c5d6295ec3585af4e211eb41b12f6a0f18fd0e5e1e6c9c67a2ba009537 67480 libcryptsetup4-udeb_1.7.5-1_amd64.udeb
 2c36591e1698588c102305a47af1dea50344c397833c746a0cf544d4316d8dd4 110766 libcryptsetup4_1.7.5-1_amd64.deb
Files:
 cc7f086a5ec983b715b979f42d92f254 2704 admin optional cryptsetup_1.7.5-1.dsc
 17f43780064308a67c69a1d7b95827d8 914236 admin optional cryptsetup_1.7.5.orig.tar.xz
 617a4257b0098fa6325b37e751bb39cd 94268 admin optional cryptsetup_1.7.5-1.debian.tar.xz
 d8ff63bc9e7a5f3688126eaa4b1d12b1 113534 debug optional cryptsetup-bin-dbgsym_1.7.5-1_amd64.deb
 85f4283464648686ed69814e020c9d6e 222770 admin optional cryptsetup-bin_1.7.5-1_amd64.deb
 643618b641ec629ff0d0fb71cddd9cfe 16964 debug optional cryptsetup-dbgsym_1.7.5-1_amd64.deb
 2689ed5d85c73d01f76a45d2a7abcddf 39032 debian-installer optional cryptsetup-udeb_1.7.5-1_amd64.udeb
 0dee92488e46427d75f5608d218a998c 8198 admin optional cryptsetup_1.7.5-1_amd64.buildinfo
 05206861b42915024b531b19493618db 177598 admin optional cryptsetup_1.7.5-1_amd64.deb
 fbef18624c45392d47f561ae9317a08f 55322 libdevel optional libcryptsetup-dev_1.7.5-1_amd64.deb
 c4f5c88a333db85974656dbe23311689 177640 debug optional libcryptsetup4-dbgsym_1.7.5-1_amd64.deb
 b39d0f050ecb1a596c10a17d53e815bb 67480 debian-installer optional libcryptsetup4-udeb_1.7.5-1_amd64.udeb
 ef2469d7ea0651ac7e429a931a4af1dc 110766 libs optional libcryptsetup4_1.7.5-1_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAlm6YXoACgkQ05pJnDwh
pVKWQQ/9GBtg6GomF52Klonjd6J5FdpvpPykv68zagoPkGU9sLDPRoHvMVoMX+kr
mCducG/HSWJaOcS2sCHHMAhZen9uyDC1dFZyhdZ8qJIqlOB0F6CxKi4rn7owVymY
90VZZhD+G7Epmq03BIyG2J80tle7oeghh6xpNBJdEPERInG8VClnyI9azJQC4WeE
0aNuicdQViGQuA63Gu8psbcsjJkrI+gYak5tLEHvvN9dhD/m813v8TAWbcp/EmkM
nM3Sb41V0W5lq7zNSPFKHFdERuwz/p/x5I/UaAQpe6dR4z98FiVGqH/mRUb7UddL
8usFL8+NP1fhzSUXKctcp4YA3XE7LuE6U+xveYiS50HVZISUVYOP+XmQtU4Xv5U8
zvcVmpwHyPOb7EBd+JjwgOU66IhJD7rEypah8oIAP9Vsi7Nr23ipEk4HjC6voXkw
HytL9mBjazc9H6qBKdcq0vvadSOWK4B7VefI7DmNF98MkmBfpUL85CE7YPHffrwi
+MPjt7G5L+fllhbkRqjgeIAYxRC9rQy5JAM/QAUA9jYe4SAmb5oBvipMVuyDG+I5
trLrn6nKrgA9oN2Rkxcwb1xFSQ3n+5QZif7cOK1+7erkOftUW2ZWJZxxS3iLmkBE
N6CYLn7eI+Arne9lvhnxfw7GQtjXKbtZlCPoSMteS4NpNPUw3vU=
=k2q6
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.