[PATCH 1/2] Revert "meta: Add option to specify additional dependencies for package expand-on-first-boot in case an encrypted disk has to be resized"

[Jan Kiszka]

From: Jan Kiszka <jan.k...@siemens.com>

This reverts commit 8b30a4f86cb3ea3369bff3884141872c3a7d9979.

On second thought, this approach turned out to be inapplicable on the
long-run. It is built around the assumption that the disk encryption
secret is still accessible after initramfs used it to unload the disk.
While the downstream implementation of cip-core currently fulfills this,
it is not expected to stay like that because of the increase attack
surface.

We will need a different solution for expanding encrypted partitions,
most likely with the help of the encryption hook in the initramfs.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---
.../expand-on-first-boot_1.5.bb | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.5.bb b/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.5.bb
index 2596706d..4b9cf376 100644
--- a/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.5.bb
+++ b/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.5.bb
@@ -10,19 +10,7 @@ inherit dpkg-raw
DESCRIPTION = "This service grows the last partition to the full medium during first boot"
MAINTAINER = "isar-users <isar-...@googlegroups.com>"

-# Additional packages that are needed to resize the disk if it is encrypted.
-ADDITIONAL_DISK_ENCRYPTION_PACKAGES ?= ""
-DEBIAN_DEPENDS = " \
- systemd, \
- sed, \
- grep, \
- coreutils, \
- mount, \
- e2fsprogs, \
- fdisk (>=2.29.2-3) | util-linux (<2.29.2-3), \
- util-linux, \
- ${ADDITIONAL_DISK_ENCRYPTION_PACKAGES} \
- "
+DEBIAN_DEPENDS = "systemd, sed, grep, coreutils, mount, e2fsprogs, fdisk (>=2.29.2-3) | util-linux (<2.29.2-3), util-linux"

SRC_URI = " \
file://expand-on-first-boot.service \
--
2.43.0

[Uladzimir Bely]

On Fri, 2024-11-08 at 12:27 +0100, 'Jan Kiszka' via isar-users wrote:
> From: Jan Kiszka <jan.k...@siemens.com>
>
> This reverts commit 8b30a4f86cb3ea3369bff3884141872c3a7d9979.
>
> On second thought, this approach turned out to be inapplicable on the
> long-run. It is built around the assumption that the disk encryption
> secret is still accessible after initramfs used it to unload the
> disk.
> While the downstream implementation of cip-core currently fulfills
> this,
> it is not expected to stay like that because of the increase attack
> surface.
>
> We will need a different solution for expanding encrypted partitions,
> most likely with the help of the encryption hook in the initramfs.
>

Hello.

Does this mean that current solution we revert here is not working
anymore in some downstream it was originally implemented for? We
wouldn't like to revert any functionality if it's still used somewhere.

Im asking since in the meanwhile I was trying to test/merge other
patches (https://groups.google.com/g/isar-users/c/sDsUCt0zMgQ and
https://groups.google.com/g/isar-users/c/BkAmajnmVIk) and found out
that they depend on this patchset applied first.

It happens due to pure technical reasons (e.g., one-line/row
representation of DEBIAN_DEPENDS).

If we apply these reverts, does it mean "proper" patches for expanding
encrypted partition are expected later? Or will they be implemented on
downstream side providing that new "configurable" expand-on-first boot
patches together with
https://groups.google.com/g/isar-users/c/rSZGRUCVvus would allow this
without changes in Isar required?

--
Best regards,
Uladzimir.

[Jan Kiszka]

On 16.11.24 07:00, Uladzimir Bely wrote:
> On Fri, 2024-11-08 at 12:27 +0100, 'Jan Kiszka' via isar-users wrote:
>> From: Jan Kiszka <jan.k...@siemens.com>
>>
>> This reverts commit 8b30a4f86cb3ea3369bff3884141872c3a7d9979.
>>
>> On second thought, this approach turned out to be inapplicable on the
>> long-run. It is built around the assumption that the disk encryption
>> secret is still accessible after initramfs used it to unload the
>> disk.
>> While the downstream implementation of cip-core currently fulfills
>> this,
>> it is not expected to stay like that because of the increase attack
>> surface.
>>
>> We will need a different solution for expanding encrypted partitions,
>> most likely with the help of the encryption hook in the initramfs.
>>
>
> Hello.
>
> Does this mean that current solution we revert here is not working
> anymore in some downstream it was originally implemented for? We
> wouldn't like to revert any functionality if it's still used somewhere.
>

It was originally designed to be used in isar-cip-core, but there it was
never pulled in, and it won't be anymore. Theoretically, there could be
users outside, but I don't expect any. And those would suffer from the
same conceptual limitation which makes this path useless.

Jan

--
Siemens AG, Technology
Linux Expert Center

[Uladzimir Bely]

On Fri, 2024-11-08 at 12:27 +0100, 'Jan Kiszka' via isar-users wrote:

> From: Jan Kiszka <jan.k...@siemens.com>
>
> This reverts commit 8b30a4f86cb3ea3369bff3884141872c3a7d9979.
>
> On second thought, this approach turned out to be inapplicable on the
> long-run. It is built around the assumption that the disk encryption
> secret is still accessible after initramfs used it to unload the
> disk.
> While the downstream implementation of cip-core currently fulfills
> this,
> it is not expected to stay like that because of the increase attack
> surface.
>
> We will need a different solution for expanding encrypted partitions,
> most likely with the help of the encryption hook in the initramfs.
>
> Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
> ---
>  .../expand-on-first-boot_1.5.bb                    | 14 +-----------
> --
>  1 file changed, 1 insertion(+), 13 deletions(-)
>

> diff --git a/meta/recipes-support/expand-on-first-boot/expand-on-
> first-boot_1.5.bb b/meta/recipes-support/expand-on-first-boot/expand-
> on-first-boot_1.5.bb
> index 2596706d..4b9cf376 100644
> --- a/meta/recipes-support/expand-on-first-boot/expand-on-first-
> boot_1.5.bb
> +++ b/meta/recipes-support/expand-on-first-boot/expand-on-first-
> boot_1.5.bb

> @@ -10,19 +10,7 @@ inherit dpkg-raw
>  DESCRIPTION = "This service grows the last partition to the full
> medium during first boot"
>  MAINTAINER = "isar-users <isar-...@googlegroups.com>"
>  
> -# Additional packages that are needed to resize the disk if it is
> encrypted.
> -ADDITIONAL_DISK_ENCRYPTION_PACKAGES ?= ""
> -DEBIAN_DEPENDS = " \
> -    systemd, \
> -    sed, \
> -    grep, \
> -    coreutils, \
> -    mount, \
> -    e2fsprogs, \
> -    fdisk (>=2.29.2-3) | util-linux (<2.29.2-3), \
> -    util-linux, \
> -    ${ADDITIONAL_DISK_ENCRYPTION_PACKAGES} \
> -    "
> +DEBIAN_DEPENDS = "systemd, sed, grep, coreutils, mount, e2fsprogs,
> fdisk (>=2.29.2-3) | util-linux (<2.29.2-3), util-linux"
>  
>  SRC_URI = " \
>      file://expand-on-first-boot.service \
> --
> 2.43.0
>

Applied to next, thanks.

--
Best regards,
Uladzimir.