cryptsetup --type 'luks' can refer to LUKS v1 or v2 depending on build time configuration

Bug #1834851 reported by Lee Yarwood
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
os-brick
Fix Released
Undecided
Unassigned

Bug Description

Bug #1831994 previously attempted to ensure LuksEncryptor volumes were formatted using the v1 header format by providing a type of `luks`. However it was missed that this type itself can point to v1 or v2 depending on build time options provided when compiling cryptsetup:

$ cryptsetup --version
cryptsetup 2.1.0

$ cryptsetup --help | grep for\ luksFormat\ action
Default compiled-in metadata format is LUKS2 (for luksFormat action).

We should just default to luks1 to avoid this.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (master)

Reviewed: https://review.opendev.org/668448
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=97b085f448e15269c28ed8adc60601894c470747
Submitter: Zuul
Branch: master

commit 97b085f448e15269c28ed8adc60601894c470747
Author: Lee Yarwood <email address hidden>
Date: Mon Jul 1 12:31:23 2019 +0100

    luks: Explicitly use the luks1 type to ensure LUKS v1 is used

    I152fe10ff5a3131950b789d3fd4efa15c554ff09 attempted to ensure LUKS
    volumes were formatted using the LUKS v1 header format by using a type
    of `luks`. However from cryptsetup 2.1.0 (incorrectly referenced as
    2.0.6 in the previous change) this type can actually refer to the newer
    LUKS v2 header format in environments where cryptsetup has not complied
    with the `--with-default-luks-format=LUKS1` build time configuration
    option [1].

    This change now explicitly uses the luks1 type when formatting a device
    to ensure the correct LUKS v1 header format is used.

    [1] https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/v2.1.0-ReleaseNotes

    Closes-Bug: #1834851
    Change-Id: I0010e9014c06a3a812d24d9d5ef598425ac5d5d4

Changed in os-brick:
status: New → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/668877

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/stein)

Reviewed: https://review.opendev.org/668877
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=4c2b25391091b5ad4935e552f2be53c0cf3ee738
Submitter: Zuul
Branch: stable/stein

commit 4c2b25391091b5ad4935e552f2be53c0cf3ee738
Author: Lee Yarwood <email address hidden>
Date: Mon Jul 1 12:31:23 2019 +0100

    luks: Explicitly use the luks1 type to ensure LUKS v1 is used

    I152fe10ff5a3131950b789d3fd4efa15c554ff09 attempted to ensure LUKS
    volumes were formatted using the LUKS v1 header format by using a type
    of `luks`. However from cryptsetup 2.1.0 (incorrectly referenced as
    2.0.6 in the previous change) this type can actually refer to the newer
    LUKS v2 header format in environments where cryptsetup has not complied
    with the `--with-default-luks-format=LUKS1` build time configuration
    option [1].

    This change now explicitly uses the luks1 type when formatting a device
    to ensure the correct LUKS v1 header format is used.

    [1] https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/v2.1.0-ReleaseNotes

    Closes-Bug: #1834851
    Change-Id: I0010e9014c06a3a812d24d9d5ef598425ac5d5d4
    (cherry picked from commit 97b085f448e15269c28ed8adc60601894c470747)

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/os-brick 2.9.1

This issue was fixed in the openstack/os-brick 2.9.1 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/os-brick 2.8.2

This issue was fixed in the openstack/os-brick 2.8.2 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.