miscellaneous development log

Threat model: * website is more trusted * mirrors / CDNs are less trusted … Under this threat model it would make sense if something similar to subresource integrity could be used. ``` <script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script> ``` Unfortunately, subresource integrity does not support user downloaded files at the of writing. Ticket: https://github.com/w3c/webappsec-subresource-integrity/issues/68 And from the ticket it also doesn't seem like support for that is coming anytime soon. Meanwhile would it be possible to do integrity check with javascript? Could the javascript look at the download stream, run it through "`$sha512`" [1] hashing and notify at the end of the download if the hashsum matches or mismatches? Tails implemented a similar solution. References: * https://tails.boum.org/contribute/design/download_verification/ * https://tails.boum.org/install/inc/js/download.js The disadvantage is, that the user has to: 1. complete the download 2. click at the `Verify your download` button 3. select the file 4. press ok 5. wait for the verification to be completed That's non-ideal from a usability perspective. feature request: Could `download.js` automate this? ---- [1] Writing `$` `sha512` because that's just a placeholder for "hashing algorithm". Shouldn't be hardcoded to be future-proof.

Patrick · June 22, 2023, 1:36pm

Patrick · October 1, 2023, 7:10pm

github.com/minfrin/retry

launching `retry` into the background disrupts `bash`'s `while read -r`

opened 07:07PM - 01 Oct 23 UTC

adrelanos

test script: ``` #!/bin/bash set -x set -e command -v retry >/dev/nul…l testfile=./testfile echo "1 2 3" > "$testfile" while read -r testvar ; do true "testvar: $testvar" retry --times=3 --delay=1 -- /bin/true & pid=$! wait "$pid" true "WAIT OK" done < "$testfile" true "END" ``` chmod +x ./test ./test actual output: ``` + set -e + command -v retry + testfile=./testfile + echo '1 2 3' + read -r testvar + true 'testvar: 1' + pid=395200 + wait 395200 + retry --times=3 --delay=1 -- /bin/true + true 'WAIT OK' + read -r testvar + true END ``` The loop runs actually only 1 time instead of the expected 3 times.

Patrick · October 16, 2023, 2:02pm

github.com/grml/grml-debootstrap

Comment by adrelanos to Initial arm64 support

grml:master ← GavinPacini:master

I tested it but a bit too slow. Before today's rebase. I am not an expert for… qemu but this is my quick way to test boot it. ``` #!/bin/bash set -x set -e ## We might get away with --no-install-recommends, fewer packages. sudo apt-get install qemu-system-arm qemu-system-aarch64 qemu-efi-aarch64 qemu-utils qemu-system-aarch64 \ -M virt \ -cpu cortex-a57 \ -m 1024 \ -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \ -drive format=raw,file=/home/user/grml-debootstraptestbin/test.img \ -nographic ``` Happy to report that build + boot was success.

Patrick · October 19, 2023, 1:44pm

Patrick · October 19, 2023, 3:41pm

github.com/grml/grml-debootstrap

Comment by adrelanos to Initial arm64 support

grml:master ← grml:mika/arm64

I cannot speak for @GavinPacini. > Is @GavinPacini somehow connected/related …to you/your work? That shouldn't matter. I hope it doesn't matter. I didn't think any transparency is required here. But for full transparency... Gavin has been active here: https://forums.whonix.org/t/whonix-on-mac-m1-arm-user-support-still-unsupported-at-time-of-writing/11310 At some point I said something like "the first step to make Whonix on ARM64 work would be contributing https://github.com/grml/grml-debootstrap/issues/169 to upstream grml-debootstrap". Gavin contributed towards that. The pull request was made from grml-debootstrap (upstream) perspective. So upstream doesn't need to spend time on any unrelated history. > I'm wondering whether to accept this PR which I did with some commit squashing and style adjustments but under Gavin's name is a) fine for him, So the easy, proper attribution so we don't have to wait for Gavin or anyone's input would be... Merge Gavin's pull request "somehow" if that's still possible. Quick and dirty. Then in the next commit "revert" to your [670035b](https://github.com/grml/grml-debootstrap/commit/670035bdde9ac232b3869eea4a66f5412d1d1132). Otherwise attribution in the commit message should be sufficient too? When I look at https://github.com/grml/grml-debootstrap/pull/214/commits it reads: > @[**GavinPacini**](https://github.com/grml/grml-debootstrap/commits?author=GavinPacini) authored and @[mika](https://github.com/grml/grml-debootstrap/commits?author=mika) committed. So it seems that would already as of now been properly recorded in the git history? > b) whether we could further improve current state? I hope that could be done in form of new issues posted and new pull requests? > (Also making sure that we didn't break non-arm64 would be good :)) I can test booworm amd64 now.

Patrick · October 20, 2023, 11:52am

github.com/grml/grml-debootstrap

--vmefi too small size of ESP partition / grub partition? / make size of ESP configurable (EFI)

opened 11:51AM - 20 Oct 23 UTC

adrelanos

``` if [ -n "$VMEFI" ]; then parted -s "${TARGET}" 'mklabel gpt' pa…rted -s "${TARGET}" 'mkpart ESP fat32 1MiB 101MiB' parted -s "${TARGET}" 'set 1 boot on' parted -s "${TARGET}" 'mkpart bios_grub 101MiB 102MiB' parted -s "${TARGET}" 'set 2 bios_grub on' parted -s "${TARGET}" 'mkpart primary ext4 102MiB 100%' ``` Could this lead to issues over time? Too small? As per: https://unix.stackexchange.com/questions/623304/size-of-efi-system-partition-esp calamares [uses](https://github.com/calamares/calamares/blob/calamares/src/modules/partition/partition.conf) `300M`. [Roderick W. Smith](https://www.rodsbooks.com/linux-uefi/) ([rEFIt](http://refit.sourceforge.net/) boot manager developer) recommends: > , I recommend creating an ESP that's 550MiB in size. That's why I would go with. Quote https://www.rodsbooks.com/efi-bootloaders/principles.html > Although the EFI specification is mute on the subject of the ESP's size, most OSes make it fairly small—Macs ship with 200MiB ESPs, and the Windows 7 installer creates one of just 100MiB. (That value has been raised to a bit over 200MiB on newer versions of Windows.) Some users, however, have found that some EFIs have bugs that cause problems with FAT32 ESPs that are under 512MiB (537MB) in size. One very common problem is files that can't be read by the EFI. The Linux mkdosfs command defaults to using FAT16 for partitions of up to 520MiB (546MB). Therefore, adding a margin of safety to protect against MiB/MB confusion and rounding errors, I recommend creating an ESP that's at least 550MiB in size. If you must use a smaller ESP and if you encounter mysterious problems, try converting it to FAT16; most ESPs will work fine with this, and it may eliminate your problems. On the other hand, this may cause the Windows installer to fail should you need to install this OS. https://www.rodsbooks.com/gdisk/advice.html#ESP_Sizing with more detailed reasoning: > 550 MiB. I'd like to use the grml-debootstrap created raw image as a base to create an ISO from it so it can be written to USB or DVD. (Using grml-debootstrap, grml-live or other tools.) (https://github.com/grml/grml-debootstrap/issues/215) Does that change the size requirements?

Patrick · October 21, 2023, 12:27pm

Patrick · October 21, 2023, 6:02pm

github.com/grml/grml-debootstrap

error not caught

opened 05:55PM - 21 Oct 23 UTC

adrelanos

``` + mount -t vfat /dev/mapper/loop0p1 /mnt/derivative-maker-grml-debootstrap.…42265/boot/efi mount: /mnt/derivative-maker-grml-debootstrap.42265/boot/efi: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p1, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. + chroot /mnt/derivative-maker-grml-debootstrap.42265 dpkg --list shim-signed ``` ``` + chroot /mnt/derivative-maker-grml-debootstrap.42265 grub-install --target=x86_64-efi --efi-directory=/boot/efi --uefi-secure-boot --removable /dev/loop0 Installing for x86_64-efi platform. grub-install: error: /boot/efi doesn't look like an EFI partition. + chroot /mnt/derivative-maker-grml-debootstrap.42265 grub-install --target=i386-pc /dev/loop0 Installing for i386-pc platform. Installation finished. No error reported. ``` Why this is happening is I need to investigate. Could be a localized issue. However, I can see REPORT_TRAP_ERR and FAIL_TRAP_ERR being `yes`. Yet, the error handler does not fire. The error is only caught later but not thorugh the `error_handler`. ``` + umount /mnt/derivative-maker-grml-debootstrap.42265/boot/efi umount: /mnt/derivative-maker-grml-debootstrap.42265/boot/efi: not mounted. + bailout 2 grub_install + cleanup ```

Patrick · October 21, 2023, 7:37pm