Subject: shim: Supporting rootless builds by default

From: Niels Thykier <[email-masked]>
Date: Sat, 7 Dec 2024 21:37:28 +0100

Source: shim
Version: 15.8-1
Severity: important
Tags: ftbfs
Justification: FTBFS
X-Debbugs-Cc: [email-masked]
User: [email-masked]
Usertags: rrr-no-as-default-issue

Dear maintainer,

During a test rebuild for building packages with
`Rules-Requires-Root: no` as the default in `dpkg`,
shim failed to rebuild.

Log Summary:
-------------------------------------------------------------------------------
[...]
aarch64-linux-gnu-gcc-12 -I/<<PKGBUILDDIR>>/gnu-efi//gnuefi 
-I/<<PKGBUILDDIR>>/gnu-efi/inc -I/<<PKGBUILDDIR>>/gnu-efi/inc/aarch64 
-I/<<PKGBUILDDIR>>/gnu-efi/inc/protocol -std=gnu11 -ggdb -ffreestanding 
-fmacro-prefix-map=/<<PKGBUILDDIR>>/= -fno-stack-protector 
-fno-strict-aliasing -fpic -fshort-wchar -Os -Wall -Wextra 
-Wno-missing-field-initializers  -DMDE_CPU_AARCH64 -DPAGE_SIZE=4096 
-mstrict-align -Werror -nostdinc -I/<<PKGBUILDDIR>>/Cryptlib 
-I/<<PKGBUILDDIR>>/Cryptlib/Include -I/<<PKGBUILDDIR>>/gnu-efi/inc 
-I/<<PKGBUILDDIR>>/gnu-efi/inc/aarch64 
-I/<<PKGBUILDDIR>>/gnu-efi/inc/protocol -I/<<PKGBUILDDIR>>/include 
-iquote /<<PKGBUILDDIR>> -iquote /<<PKGBUILDDIR>> -isystem 
/<<PKGBUILDDIR>>/include/system -isystem 
/usr/lib/gcc/aarch64-linux-gnu/12/include 
-DDEFAULT_LOADER='L"\\\\grubaa64.efi"' 
-DDEFAULT_LOADER_CHAR='"\\\\grubaa64.efi"' -DEFI_ARCH='L"aa64"' 
-DDEBUGDIR='L"/usr/lib/debug/usr/share/shim/aa64-15.8-15.8/"' 
-DVENDOR_CERT_FILE=\"debian/debian-uefi-ca.der\" 
-DVENDOR_DBX_FILE=\"dbx.esl\" -DSBAT_AUTOMATIC_DATE=2024010900 
-DGNU_EFI_USE_EXTERNAL_STDARG -Wno-error=pragmas -fpic  -Os -Wall 
-Wextra -Wno-missing-field-initializers -Werror -fshort-wchar 
-fno-strict-aliasing -ffreestanding -fno-stack-protector 
-fno-stack-check -nostdinc   -isystem 
/<<PKGBUILDDIR>>/gnu-efi/../include/system -isystem 
/usr/lib/gcc/aarch64-linux-gnu/12/include -fno-merge-all-constants 
-Wno-error=pragmas -fpic  -Os -Wall -Wextra 
-Wno-missing-field-initializers -Werror -fshort-wchar 
-fno-strict-aliasing -ffreestanding -fno-stack-protector 
-fno-stack-check -nostdinc   -isystem 
/<<PKGBUILDDIR>>/gnu-efi/../include/system -isystem 
/usr/lib/gcc/aarch64-linux-gnu/12/include -fno-merge-all-constants 
-fno-jump-tables -Wdate-time -D_FORTIFY_SOURCE=2 -DCONFIG_aarch64 
-DCONFIG_aarch64 -c /<<PKGBUILDDIR>>/gnu-efi//gnuefi/reloc_aarch64.c -o 
reloc_aarch64.o
/<<PKGBUILDDIR>>/gnu-efi//gnuefi/crt0-efi-aarch64.S: Assembler messages:
/<<PKGBUILDDIR>>/gnu-efi//gnuefi/crt0-efi-aarch64.S:54: Warning: setting 
incorrect section attributes for .note.GNU-stack
aarch64-linux-gnu-gcc-ar rv -U libgnuefi.a reloc_aarch64.o
/usr/bin/ar: creating libgnuefi.a
a - reloc_aarch64.o
make: Leaving directory '/<<PKGBUILDDIR>>/gnu-efi/aarch64/gnuefi'
make: Leaving directory '/<<PKGBUILDDIR>>/gnu-efi'
aarch64-linux-gnu-ld -o shimaa64.so --hash-style=sysv -nostdlib 
-znocombreloc -T /<<PKGBUILDDIR>>/elf_aarch64_efi.lds -shared -Bsymbolic 
-Lgnu-efi/aarch64/gnuefi -Lgnu-efi/aarch64/lib -LCryptlib 
-LCryptlib/OpenSSL gnu-efi/aarch64/gnuefi/crt0-efi-aarch64.o 
--build-id=sha1  --no-undefined shim.o globals.o mok.o netboot.o cert.o 
replacements.o tpm.o version.o errlog.o sbat.o sbat_data.o sbat_var.o 
pe.o pe-relocate.o httpboot.o csv.o load-options.o 
Cryptlib/libcryptlib.a Cryptlib/OpenSSL/libopenssl.a lib/lib.a 
gnu-efi/aarch64/lib/libefi.a gnu-efi/aarch64/gnuefi/libgnuefi.a -lefi 
-lgnuefi --start-group Cryptlib/libcryptlib.a 
Cryptlib/OpenSSL/libopenssl.a --end-group 
/usr/lib/gcc/aarch64-linux-gnu/12/libgcc.a lib/lib.a
aarch64-linux-gnu-ld: warning: shimaa64.so has a LOAD segment with RWX 
permissions
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data -j .data.ident \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame \
	-j .vendor_cert -j .sbat -j .sbatlevel \
	--target efi-app-aarch64 shimaa64.so shimaa64.efi
./post-process-pe -vv  shimaa64.efi
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame -j .sbat \
	-j .sbatlevel \
	-j .debug_info -j .debug_abbrev -j .debug_aranges \
	-j .debug_line -j .debug_str -j .debug_ranges \
	-j .note.gnu.build-id \
	shimaa64.so shimaa64.efi.debug
aarch64-linux-gnu-ld -o mmaa64.so --hash-style=sysv -nostdlib 
-znocombreloc -T /<<PKGBUILDDIR>>/elf_aarch64_efi.lds -shared -Bsymbolic 
-Lgnu-efi/aarch64/gnuefi -Lgnu-efi/aarch64/lib -LCryptlib 
-LCryptlib/OpenSSL gnu-efi/aarch64/gnuefi/crt0-efi-aarch64.o 
--build-id=sha1  --no-undefined MokManager.o PasswordCrypt.o 
crypt_blowfish.o errlog.o sbat_data.o globals.o Cryptlib/libcryptlib.a 
Cryptlib/OpenSSL/libopenssl.a lib/lib.a gnu-efi/aarch64/lib/libefi.a 
gnu-efi/aarch64/gnuefi/libgnuefi.a -lefi -lgnuefi --start-group 
Cryptlib/libcryptlib.a Cryptlib/OpenSSL/libopenssl.a --end-group 
/usr/lib/gcc/aarch64-linux-gnu/12/libgcc.a lib/lib.a
aarch64-linux-gnu-ld: warning: mmaa64.so has a LOAD segment with RWX 
permissions
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame -j .sbat \
	-j .sbatlevel \
	-j .debug_info -j .debug_abbrev -j .debug_aranges \
	-j .debug_line -j .debug_str -j .debug_ranges \
	-j .note.gnu.build-id \
	mmaa64.so mmaa64.efi.debug
aarch64-linux-gnu-ld -o fbaa64.so --hash-style=sysv -nostdlib 
-znocombreloc -T /<<PKGBUILDDIR>>/elf_aarch64_efi.lds -shared -Bsymbolic 
-Lgnu-efi/aarch64/gnuefi -Lgnu-efi/aarch64/lib -LCryptlib 
-LCryptlib/OpenSSL gnu-efi/aarch64/gnuefi/crt0-efi-aarch64.o 
--build-id=sha1  --no-undefined fallback.o tpm.o errlog.o sbat_data.o 
globals.o Cryptlib/libcryptlib.a Cryptlib/OpenSSL/libopenssl.a lib/lib.a 
gnu-efi/aarch64/lib/libefi.a gnu-efi/aarch64/gnuefi/libgnuefi.a -lefi 
-lgnuefi --start-group Cryptlib/libcryptlib.a 
Cryptlib/OpenSSL/libopenssl.a --end-group 
/usr/lib/gcc/aarch64-linux-gnu/12/libgcc.a lib/lib.a
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame -j .sbat \
	-j .sbatlevel \
	-j .debug_info -j .debug_abbrev -j .debug_aranges \
	-j .debug_line -j .debug_str -j .debug_ranges \
	-j .note.gnu.build-id \
	fbaa64.so fbaa64.efi.debug
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data -j .data.ident \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame \
	-j .vendor_cert -j .sbat -j .sbatlevel \
	--target efi-app-aarch64 mmaa64.so mmaa64.efi
./post-process-pe -vv  mmaa64.efi
aarch64-linux-gnu-objcopy -D -j .text -j .sdata -j .data -j .data.ident \
	-j .dynamic -j .rodata -j .rel* \
	-j .rela* -j .dyn -j .reloc -j .eh_frame \
	-j .vendor_cert -j .sbat -j .sbatlevel \
	--target efi-app-aarch64 fbaa64.so fbaa64.efi
./post-process-pe -vv  fbaa64.efi
gcc -I/usr/include -Og -g3 -Wall -Werror -Wextra -o buildid 
/<<PKGBUILDDIR>>/buildid.c -lelf
Making BOOTAA64.CSV
install -d -m 0755 /<<PKGBUILDDIR>>/debian/tmp/
install -d -m 0755 
/<<PKGBUILDDIR>>/debian/tmp//usr/lib/debug/boot/efi/EFI/debian//
install -d -m 0755 
/<<PKGBUILDDIR>>/debian/tmp//usr/src/debug//shim-15.8-15.8
find /<<PKGBUILDDIR>> -type f -a '(' -iname '*.c' -o -iname '*.h' -o 
-iname '*.S' ')' | while read file ; do \
	outfile=$(echo ${file} | sed -e "s,^/<<PKGBUILDDIR>>,,") ; \
	install -d -m 0755 
/<<PKGBUILDDIR>>/debian/tmp//usr/src/debug//shim-15.8-15.8/$(dirname 
${outfile}) ; \
	install -m 0644 ${file} 
/<<PKGBUILDDIR>>/debian/tmp//usr/src/debug//shim-15.8-15.8/${outfile} ; \
done
install -d -m 0755 /<<PKGBUILDDIR>>/debian/tmp/
install -d -m 0700 /<<PKGBUILDDIR>>/debian/tmp/boot/efi/
install -d -m 0755 /<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/BOOT/
install -d -m 0755 /<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/debian/
install -m 0644 shimaa64.efi 
/<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/BOOT//BOOTAA64.EFI
install -m 0644 shimaa64.efi 
/<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/debian//
install -m 0644 BOOTAA64.CSV 
/<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/debian//
install -m 0644 fbaa64.efi /<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/BOOT//
install -m 0644 mmaa64.efi /<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/BOOT//
install -m 0644 mmaa64.efi /<<PKGBUILDDIR>>/debian/tmp/boot/efi/EFI/debian//
make: Leaving directory '/<<PKGBUILDDIR>>'
# Remove the copy of the source that's installed - we have git
# already...
rm -rf debian/tmp/usr
# And remove the extra removable-media copy of shim too, it's
# not needed for our build and causes debhelper to complain
rm -f debian/tmp/boot/efi/EFI/BOOT/BOOT*.EFI
install -m 644 debian/debian-uefi-ca.der debian/shim-unsigned/usr/share/shim
# Generate the template packages that we'll use for SB signing later
./debian/signing-template.generate
install: cannot change owner and permissions of 
‘debian/shim-helpers-arm64-signed-template/usr/share/code-signing/shim-helpers-arm64-signed-template’: 
Operation not permitted
make[1]: *** [debian/rules:93: override_dh_auto_install] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:69: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2
--------------------------------------------------------------------------------
Build finished at 2024-11-18T14:43:48Z

-------------------------------------------------------------------------------

The above is just how the build ends and not necessarily the most
relevant part. If required, the full build log is available here:

https://people.debian.org/~nthykier/rrr-no-as-default/logs/1044526.gz

You can find common solutions at
https://people.debian.org/~nthykier/rrr-no-as-default/docs/solutions.md

If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.

If this package is listed in
https://people.debian.org/~nthykier/rrr-no-as-default/docs/static-ownership.list,
then please just set `Rules-Requires-Root: binary-targets` to the source
stanza of `debian/control` as a fix to this bug.

If this package is listed in
https://people.debian.org/~nthykier/rrr-no-as-default/docs/maybe-misbuilds.list,
then the package was deemed at risk for misbuilding (having wrong
ownership) but had a FTBFS problem we tested it. Please test whether the
package works with `Rules-Requires-Root: no` validating that the
resulting deb has the correct ownership for all paths in the deb.

The goal is to have the default changed in `dpkg` either in `Trixie` or
`Forky`, depending on progress and feasibility with the release schedule
for Trixie.

For more information on this bug filing, please see:
https://lists.debian.org/debian-dpkg/2024/11/msg00016.html

Thanks,

PS: The builds were performed in mid-November. If you fixed the problem
between between then and this bug being filed, then please just close
the bug with the version it was fixed in.

---

From: Niels Thykier <[email-masked]>
Date: Sat, 28 Dec 2024 13:00:45 +0100

Control: tags -1 patch

> `Rules-Requires-Root: no` as the default in `dpkg`,

There is an MR at
https://salsa.debian.org/efi-team/shim/-/merge_requests/17 with a patch 
for how to solve this.

Best regards,
Niels

---

From: Niels Thykier <[email-masked]>
Date: Sat, 4 Jan 2025 09:59:06 +0100

> https://salsa.debian.org/efi-team/shim/-/merge_requests/17 with a patch 

Hi

The bugs are now become RC (both this for shim and the one for
shim-helpers-arm64-signed).

I can do an NMU for this package to resolve the RC bug. However, I am 
not sure if will be helpful or just be in the way. My end goal is to 
have the bug fixed in testing and I am not sure my fix would transition 
(I am unclear on how the shim signing interacts with the packages and 
the transition).

Note the patch does not affect the produced binaries but there has been 
changes to the toolchains changing a "MinorLinkerVersion" and a 
"CheckSum" field in many of the efi files. I assume this means it will 
need a resign on upload and I don't remember if it is something Debian 
can just do.

There are also a lot of changes in shim-helpers-amd64-helpers that I do 
not understand which includes a whole debian/ subdir under 
"usr/share/code-signing/shim-helpers-amd64-signed-template/source-template", 
which are unrelated to my change (FWIW, I built from git rather than a 
minimum patch on top of latest sid version).

So, we are back to: Would it be helpful if I NMUed the shim or/and 
shim-helpres-arm64-signed package? If not, then I will leave it in your 
capable hands.

Best regards,
Niels

---

From: Steve McIntyre <[email-masked]>
Date: Sat, 4 Jan 2025 17:43:11 +0000

Hey Niels!

>shim-helpers-arm64-signed).

ACK.

>I can do an NMU for this package to resolve the RC bug. However, I am not
>sure if will be helpful or just be in the way. My end goal is to have the bug
>fixed in testing and I am not sure my fix would transition (I am unclear on
>how the shim signing interacts with the packages and the transition).

Thanks for being cautious and reaching out to me! In general, NMUing
shim is *never* the correct thing to do due to its special nature. The
interaction with the Microsoft signing (etc.) makes things difficult
here.

>changes to the toolchains changing a "MinorLinkerVersion" and a "CheckSum"
>field in many of the efi files. I assume this means it will need a resign on
>upload and I don't remember if it is something Debian can just do.
>
>There are also a lot of changes in shim-helpers-amd64-helpers that I do not
>understand which includes a whole debian/ subdir under

I'm looking at your MR now, thanks!

I should warn you: I'm *not* planning on doing a new upload of the
current packages soon, even so. There's a new upstream version due
soon, and I'll fold things in there.

-- 
Steve McIntyre, Cambridge, UK.                                [email-masked]
"C++ ate my sanity" -- Jon Rabone

---

From: Niels Thykier <[email-masked]>
Date: Sun, 5 Jan 2025 09:03:05 +0100

> soon, and I'll fold things in there.

I had a feeling that might be case with the NMUs (I got a similar 
feeling for debian-installer, that also turned out to be correct). I am 
fine with leaving this as it is. The most important part is that it is 
fixed before the freeze and I suspect the RT is ok knowing you got this.

Thanks for merging the patch! :)

Best regards,
Niels

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 26 Apr 2025 19:06:47 +0200

> soon, and I'll fold things in there.

Do you have an update on this?

Kurt

---

From: Steve McIntyre <[email-masked]>
Date: Sun, 27 Apr 2025 16:19:14 +0100

>Do you have an update on this?

Sorry, I've not been updating bugs here enough to share progress.

I've had changes for this ready for some time, just not pushed yet.

The shim 16.0 release has already happened upstream, and it passes CI
for me locally.

*However*, we're waiting on a bugfix for

  https://github.com/rhboot/shim/issues/741

which is a show-stopper bug for secure boot chains where UKIs are
going to be a thing. A fix is coming Real Soon Now, I've been
promised. That's going to prompt a 16.1 release.

In the meantime, I really don't want to upload a 16.0 build, as that
makes things much more awkward in terms of the signing pipeline (etc.)

-- 
Steve McIntyre, Cambridge, UK.                                [email-masked]
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"