Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

[Guilhem Moulin]

Thanks, uploaded!  Hope this makes it to 10.1 :-)

And again, many thanks for your work on Buster!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

[Cyril Brulebois]

Hi,

Guilhem Moulin  (2019-08-26):
> A s-p-u was previously filed (#934956) — and accepted — for 2:2.1.0-5+deb10u1.
> The new commit cherry-picked from upstream also includes a unit test; like
> most of the test suite it'll be ignored by the build daemons as it requires
> root access, but I did verify that the entire test suite still passes on amd64
> and i386 (and that indeed large devices no longer overflow).
> 
> Given that Buster currently has 2:2.1.0-5, should the .changes include all
> changes since that version, or only since 2:2.1.0-5+deb10u1?
> 
> Thanks for considering its inclusion in Buster!  CC'ing KiBi for the d-i ack.

No obvious regressions, so no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

[Adam D. Barratt]

On Mon, 2019-08-26 at 18:41 +0100, Adam D. Barratt wrote:
> Control: tags -1 + d-i confirmed
> 

I don't know if that will be in time, but while we wait feel free to
upload so that the package is available if the timings turn out to be
on our side.

Regards,

Adam

Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

[Adam D. Barratt]

Control: tags -1 + d-i confirmed

On Mon, 2019-08-26 at 19:18 +0200, Guilhem Moulin wrote:
> Another regression was found in cryptsetup :-/  Its scope is quite
> narrow as it only affects mapped device size ≥2TiB (2³² 512-bits
> sectors) on 32-bits platforms.  And AFAICT ‘crypt’ targets are not
> affected, only ‘integrity’ ones are; both standalone dm-integrity
> volumes set up with integritysetup(8), as well as volumes used for
> *experimental* authenticated disk encryption and set
> up with cryptsetup(8).
> 
> In these scenarios the size overflows (due to size_t being
> incorrectly used in place of uint64_t) and the device is mapped with
> a truncated size.  There is a risk of data loss if the user writes
> inside the container, for instance while trying to recover it, so
> that should IMHO be fixed via s-p-u.
> 
> This is an upstream regression from 2.1.0, so Stretch is not
> affected. 2:2.2.0-3 from Sid contains the cherry-picked upstream fix,
> but Buster's 2:2.1.0-5 (and 2:2.1.0-5+deb10u1) is affected.
[...]
> Given that Buster currently has 2:2.1.0-5, should the .changes
> include all
> changes since that version, or only since 2:2.1.0-5+deb10u1?

+deb10u1 is already in the archive, so this would be no different from
any other upload. (i.e. just since +deb10u1.)

Regards,

Adam

Bug#935827: buster-pu: package cryptsetup/2:2.1.0-5+deb10u2

[Guilhem Moulin]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

Another regression was found in cryptsetup :-/  Its scope is quite narrow as
it only affects mapped device size ≥2TiB (2³² 512-bits sectors) on 32-bits
platforms.  And AFAICT ‘crypt’ targets are not affected, only ‘integrity’ ones
are; both standalone dm-integrity volumes set up with integritysetup(8), as
well as volumes used for *experimental* authenticated disk encryption and set
up with cryptsetup(8).

In these scenarios the size overflows (due to size_t being incorrectly used in
place of uint64_t) and the device is mapped with a truncated size.  There is a
risk of data loss if the user writes inside the container, for instance while
trying to recover it, so that should IMHO be fixed via s-p-u.

This is an upstream regression from 2.1.0, so Stretch is not affected.
2:2.2.0-3 from Sid contains the cherry-picked upstream fix, but Buster's
2:2.1.0-5 (and 2:2.1.0-5+deb10u1) is affected.  Changelog since 2:2.1.0-5 is
as follows, and debdiff against 2:2.1.0-5 and 2:2.1.0-5+deb10u1 attached.

--8<->8--

cryptsetup (2:2.1.0-5+deb10u2) buster; urgency=medium

  * Cherry pick upstream commit 8f8f0b32: Fix mapped segments overflow on
32bit architectures.  Regression since 2:2.1.0-1.  (Closes: #935702)

 -- Guilhem Moulin   Mon, 26 Aug 2019 14:54:10 +0200

cryptsetup (2:2.1.0-5+deb10u1) buster; urgency=high

  * Backport upstream commits c03e3fe8, 725720df and fe4e1de5 to fix support
for LUKS2 headers without any bound keyslot.  Adding a new key slot using
the volume key was failing, both via the crypt_keyslot_add_by_volume_key()
API call and with `luksAddKey --master-key`.  The former in particular
might yield data loss if, in order to change a passphrase, an application
destroys the keyslot before adding a new one (using the volume key), cf.
#928893.  Note that doing so is *unsafe*: applications should instead use
crypt_keyslot_change_by_passphrase() from libcryptsetup >=1.6.0.
Trying to open LUKS2 volume by supplying the volume key on the command
line was also failing if there were no bound keyslot on the header.
(Closes: #934715)

 -- Guilhem Moulin   Fri, 16 Aug 2019 19:18:10 +0200

--8<->8--

A s-p-u was previously filed (#934956) — and accepted — for 2:2.1.0-5+deb10u1.
The new commit cherry-picked from upstream also includes a unit test; like
most of the test suite it'll be ignored by the build daemons as it requires
root access, but I did verify that the entire test suite still passes on amd64
and i386 (and that indeed large devices no longer overflow).

Given that Buster currently has 2:2.1.0-5, should the .changes include all
changes since that version, or only since 2:2.1.0-5+deb10u1?

Thanks for considering its inclusion in Buster!  CC'ing KiBi for the d-i ack.
Cheers,
-- 
Guilhem.
diffstat for cryptsetup-2.1.0 cryptsetup-2.1.0

 changelog  |   23 +
 gbp.conf   |1 
 patches/Fix-getting-default-LUKS2-keyslot-encryption-paramet.patch |   56 +++
 patches/Fix-mapped-segments-overflow-on-32bit-architectures.patch  |  151 
++
 patches/Fix-volume-key-file-if-no-LUKS2-keyslots-are-present.patch |   86 +
 patches/Mention-limitation-of-crypt_get_volume_key_size.patch  |   20 +
 patches/series |4 
 7 files changed, 341 insertions(+)

diff -Nru cryptsetup-2.1.0/debian/changelog cryptsetup-2.1.0/debian/changelog
--- cryptsetup-2.1.0/debian/changelog   2019-06-10 14:51:15.0 +0200
+++ cryptsetup-2.1.0/debian/changelog   2019-08-26 14:54:10.0 +0200
@@ -1,3 +1,26 @@
+cryptsetup (2:2.1.0-5+deb10u2) buster; urgency=medium
+
+  * Cherry pick upstream commit 8f8f0b32: Fix mapped segments overflow on
+32bit architectures.  Regression since 2:2.1.0-1.  (Closes: #935702)
+
+ -- Guilhem Moulin   Mon, 26 Aug 2019 14:54:10 +0200
+
+cryptsetup (2:2.1.0-5+deb10u1) buster; urgency=high
+
+  * Backport upstream commits c03e3fe8, 725720df and fe4e1de5 to fix support
+for LUKS2 headers without any bound keyslot.  Adding a new key slot using
+the volume key was failing, both via the crypt_keyslot_add_by_volume_key()
+API call and with `luksAddKey --master-key`.  The former in particular
+might yield data loss if, in order to change a passphrase, an application
+destroys the keyslot before adding a new one (using the volume key), cf.
+#928893.  Note that doing so is *unsafe*: applications should instead use
+crypt_keyslot_change_by_passphrase() from libcryptsetup >=1.6.0.
+Trying to open LUKS2 volume by supplying the volume key on the command
+line was also failing if there were no bound