miscellaneous development log

Patrick · January 19, 2023, 10:46am

Patrick · June 2, 2023, 1:26pm

check integrity of downloaded files

opened 01:25PM - 02 Jun 23 UTC

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

Patrick · October 21, 2023, 7:41pm

Patrick · October 23, 2023, 11:52am

Patrick · October 23, 2023, 12:39pm

github.com/grml/grml-debootstrap

`eend 0` does effectively nothing, so let's remove it

opened 12:39PM - 23 Oct 23 UTC

closed 04:09PM - 25 Oct 23 UTC

adrelanos

``` eend() { local retval="${1:-0}" shift if [ "$retval" -gt 0 ]; then… printf " %s-> Failed (rc=%s)%s\\n" "${BAD}" "${retval}" "${NORMAL}" fi return "$retval" } ``` `eend 0` just results in `return 0` which doesn't do anything. In preparation of https://github.com/grml/grml-debootstrap/issues/224 for code simplification it would be best to remove these. A very few cases are a tiny bit more complex. ``` if cp "$AUTHORIZED_KEYS_SOURCE" "$AUTHORIZED_KEYS_TARGET" ; then eend 0 else eerror "Error: copying '$AUTHORIZED_KEYS_SOURCE' to '$AUTHORIZED_KEYS_TARGET' failed" eend 1 bailout 1 fi ``` Could rewrite to: ``` if ! cp "$AUTHORIZED_KEYS_SOURCE" "$AUTHORIZED_KEYS_TARGET" ; then eerror "Error: copying '$AUTHORIZED_KEYS_SOURCE' to '$AUTHORIZED_KEYS_TARGET' failed" eend 1 bailout 1 fi ```

Patrick · October 23, 2023, 12:57pm

Patrick · October 25, 2023, 5:37pm

github.com/grml/grml-debootstrap

improve error handling

grml:master ← adrelanos:error-handling

opened 05:34PM - 25 Oct 23 UTC

adrelanos

+107 -182

WIP Not yet tested. Will test soon. My commit messages are more explanator…y for the reviewer than useful in the git history of the master branch. Due the difficulty and extensive scope of these changes, I won't be able to split this into different logical sets of changes. It was so extensive, I had to randomly start somewhere and adjust it step by step for the new error handler. I would suggest to squash all of these commits into a single commit since functionality wise hopefully nothing changed, just the error handling was improved and the code simplified. Fixes https://github.com/grml/grml-debootstrap/issues/224

Patrick · November 9, 2023, 3:13pm

github.com/QubesOS/qubes-issues

Qube failed to start

opened 09:16AM - 13 Oct 23 UTC

grnklod

T: bug C: core P: default needs diagnosis affects-4.2

### Qubes OS release R4.2 ### Brief summary I've started a new Whon…ix disposable qube by launching Tor Browser but it failed to start. Seems like it hung for some reason but there is no related info in logs. Maybe it has happened because of this: https://github.com/QubesOS/qubes-issues/issues/7956 Disposable qube is from whonix-ws-17-dvm disposable template based on whonix-workstation-17 template with latest updates and Tor Browser 13 using kernel 6.5.6-2.qubes.fc37.x86_64 with default initial memory 400 MB and 2 VCPUs. Dom0 has latest updates but is using kernel 6.4.13-1.qubes.fc37.x86_64. I think this is the second time it happened but I'm not sure and I couldn't reproduce it. [guest-disp6708.log](https://github.com/QubesOS/qubes-issues/files/12891836/guest-disp6708.log) [journalctl-disp6708.log](https://github.com/QubesOS/qubes-issues/files/12891837/journalctl-disp6708.log)

Patrick · November 9, 2023, 4:03pm

github.com/QubesOS/qubes-issues

Renaming `sys-whonix` results in `Denied whonix.NewStatus+status from dispXXXX to sys-whonix`

opened 10:37AM - 09 Nov 23 UTC

andrewdavidwong

T: bug C: core C: Whonix P: default needs diagnosis affects-4.1

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release 4.1 ### Brief summary Renaming `sys-whonix` causes a problem with `whonix.NewStatus`. ### Steps to reproduce 1. Rename `sys-whonix`. 2. Start a disposable based on the default Whonix Workstation disposable template. ### Expected behavior No errors. ### Actual behavior Dom0 notification: ``` Denied whonix.NewStatus+status from dispXXXX to sys-whonix ``` (Note: At this point, no VM with the name `sys-whonix` exists in the system.) ### Additional information All of this is after renaming `sys-whonix` to `newname-sys-whonix`: - `newname-sys-whonix` still has the `anon-gateway` tag. - `dispXXXX` has the `anon-vm` tag. - `qvm-features newname-sys-whonix` doesn't show `whonix-default-gw`. Not sure if it did before the rename. - `qvm-features newname-sys-whonix whonix-default-gw` does nothing. Not sure if it's supposed to. ### Related issues https://github.com/QubesOS/qubes-issues/issues/7276 CC: @adrelanos

Patrick · November 9, 2023, 7:25pm

177 posts were merged into an existing topic: Some thoughts on anti-stylometry research

Patrick · July 11, 2022, 6:00pm

2 posts were split to a new topic: # change Qubes network policy, UpdatesProxy to network disabled by default for better leak-proofness