Your message dated Thu, 13 Mar 2025 11:37:45 +0100
with message-id <[email protected]>
and subject line Re: Bug#1100158: wipes LUKS keys on exit?
has caused the Debian Bug report #1100158,
regarding wipes LUKS keys on exit?
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 [email protected]
immediately.)
--
1100158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100158
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: fai-setup-storage
Version: 6.2.3
Severity: important
I have used setup-storage as part of a bespoke installer we've built
here over the years, made of setup-storage and grml-debootstrap,
essentially. The source code is kind of embarrassing, but it's here if
you want to see the gory details:
https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/ca6d9584c2a57fa8933fc2b499394c550326aa1f/fabric_tpa/install.py
This was working well: setup-storage was doing the hard work of
partitioning and mounting the disks, and grml-debootstrap was doing
the rest.
(I know we should probably just be using FAI, but i've been having
trouble setting it up in our heterogenous environment.)
One of the things our setup does is use the LUKS keyfiles generated by
setup-storage to add a new, password-based, encryption key that gets
added to the key slots. This was working because a keyfile was
leftover in /tmp/fai, and indeed the setup-storage manual page
indicates that's expected behavior.
Except something happened recently that made that file disappear. I
have verified this during an install, where the file was removed at
some point. I can't exclude the possibility that something in grml or
our script wipes away that keyfile, but I don't understand why it
would wipe *just* that keyfile. And indeed, if I copy the file out
*while* setup-storage is running, i can restore it after it exits, and
our installer works again.
So it looks like setup-storage's behavior changed there, and it
deletes keyfiles on exit.
Is that intentional? Is that a correct assessment?
Could we revert this? I understand having plain text keyfiles in /tmp
is probably not the best idea, security wise, but it's something we
currently depend on. Writing a secret in the setup-storage
configuration file is not an option.
Thanks!
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fai-setup-storage depends on:
ii e2fsprogs 1.47.2-1
pn liblinux-lvm-perl <none>
ii libparse-recdescent-perl 1.967015+dfsg-4
ii parted 3.6-5
ii perl 5.40.1-2
Versions of packages fai-setup-storage recommends:
pn fai-client <none>
ii lvm2 2.03.27-1
ii mdadm 4.4-5
Versions of packages fai-setup-storage suggests:
ii cryptsetup 2:2.7.5-1
ii dmsetup 2:1.02.201-1
ii dosfstools 4.2-1.1
pn jfsutils <none>
ii ntfs-3g 1:2022.10.3-5
ii reiserfsprogs 1:3.6.27-9
ii xfsprogs 6.13.0-2
--- End Message ---
--- Begin Message ---
Closing, because the variable FAI_KEEP_CRYPTKEYFILE is now documented
in the man page.
The default should not to keep this file, because it will also be
stored in the log folder.
--
regards Thomas
--- End Message ---
