miscellaneous development log

Patrick · October 23, 2023, 12:39pm

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

opened 12:39PM - 23 Oct 23 UTC

closed 04:09PM - 25 Oct 23 UTC

``` 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

Patrick · November 10, 2023, 7:11pm

Patrick · November 13, 2023, 3:46pm

CodeQL vulnerability scanning enabled for all projects containing non-trivial C or C++ code:

LKRG
hardned-malloc
bindp
kloak

Patrick · November 13, 2023, 3:47pm

Avoid intermediary installation of initramfs-tools when using INITRD_GENERATOR=dracut. by adrelanos · Pull Request #236 · grml/grml-debootstrap · GitHub

github.com/grml/grml-debootstrap

busybox should be moved to local packages file instead of being hardcoded in chroot-script

opened 03:45PM - 13 Nov 23 UTC

adrelanos

busybox had some security vulnerabilities. I didn't check how severe these were …or how to exploit there. However, busybox doesn't seem to be a a critically required dependency for a fully functional image. At least if using dracut. So lets move it from being hardcoded in chroot-script to the local packages files. Happy to send a PR. Seems to be a trivial change. Waiting with the PR until https://github.com/grml/grml-debootstrap/pull/236 is merged otherwise there would be a merge conflict.

Patrick · November 19, 2023, 6:16am

Patrick · November 22, 2023, 5:22am

github.com/grml/grml-debootstrap

my closed pull requests

opened 04:47AM - 22 Nov 23 UTC

adrelanos

Sorry about the closed pull requests noise. I was attempting to make github a…ctions work in my personal (soft) fork (only for the purpose of contributing and carrying delta until merged here upstream). Previously I had pressed the github fork button. But apparently such repositories cannot run github actions. To have a "real" fork I deleted the repository, manually created and pushed. That fixed the github actions in my personal repository but had the unwanted side effects of closing all my prior pull requests here upstream. I am trying to figure out how to re-open these.

Patrick · November 22, 2023, 5:40am

Patrick · November 24, 2023, 5:26am

--vmefi too small size of ESP partition / grub partition? / make size of ESP configurable (EFI) · Issue #221 · grml/grml-debootstrap · GitHub

Patrick · December 7, 2023, 7:10pm

more work on https://github.com/grml/grml-debootstrap/pull/255

Patrick · December 8, 2023, 8:39am

github.com/grml/grml-debootstrap

Comment by adrelanos to ci: diff back-to-back built images

grml:master ← zeha:b2b

This is probably considered blocked by: * https://github.com/grml/grml-deboot…strap/issues/252 But I think it should not be considered blocked because of that. I think this PR would be good to be merged rather sooner than later to avoid merge conflicts. It seems to be a nice feature towards reproducible builds. While the actual test is still broken on CI, it's still adding informative output to grml-debootstrap. I might even send a PR to improve that debug output. Also any scripts to diff two different VM images are nice for local use. As long as https://github.com/grml/grml-debootstrap/issues/252 is pending, simply keep the test disabled on CI so CI does not break until this gets fixed in the future?

Patrick · December 8, 2023, 11:19am

github.com/grml/grml-debootstrap

VM loop device not cleaned up in CI

opened 07:51PM - 19 Nov 23 UTC

zeha

``` * Removing loopback mount of file /code/qemu-1.img. previous state: loop…3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) after kpartx-d loop3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) loop_part is: loop3p1 loop3p1 (253:0) /dev/loop1: [2065]:72205 (/var/lib/snapd/snaps/core20_2015.snap) /dev/loop2: [2065]:72206 (/var/lib/snapd/snaps/snapd_20290.snap) /dev/loop0: [2065]:72204 (/var/lib/snapd/snaps/lxd_24322.snap) /dev/loop3: [2065]:282883 (/code/qemu-1.img) * Finished execution of grml-debootstrap. Enjoy your Debian system. ``` At least in GitHub Actions the cleanup of the loop device doesn't seem to work properly.

Patrick · December 12, 2023, 4:35pm

github.com/grml/grml-debootstrap

consistently use ESP label for the EFI system partition

grml:master ← adrelanos:patch-1

opened 04:34PM - 12 Dec 23 UTC

adrelanos

+1 -1

change from EFI to ESP for arm64 builds Use of ESP is more popular. * http…s://en.wikipedia.org/wiki/EFI_system_partition * https://wiki.archlinux.org/title/EFI_system_partition * https://www.diskpart.com/articles/efi-system-partition-4348.html If we'd use the long label it would be "EFI system partition" but since we use the short label it should be ESP. Why bother? Because then later `PARTLABEL` can be used in `/etc/fstab`. https://wiki.archlinux.org/title/fstab#GPT_partition_labels Any label with spaces is more error-prone. I haven't found any convention for partition labels but consistency makes sense.

Patrick · December 21, 2023, 2:24pm

Debian mkosi bug report:
outdated package description - mkosi is no longer legacy-free (and that’s okay)

Patrick · December 21, 2023, 2:37pm

Support iso9660 as output format · Issue #1220 · systemd/mkosi · GitHub