{{Header}} {{title|title= ToDo for Developers }} {{#seo: |description=TODO }} {{devwiki}} {{intro| TODO }} = TODO DEV = == faillock == === security-misc - review pam-configs === * please have a look here in security-misc usr/share/pam-configs/ for introduction * Looked at it, seems reasonable and useful === security-misc - faillock - stop reset after reboot === * should not be reset after reboot * the faillock status file is configureable already, see man pam_faillock * Requires pam config modifications to make work right, working proof-of-concept config determined and shared in chat. === security-misc - faillock - stop reset after 24 hours === * should not be reset after 24 hours * no need to automatically reset at all * user should always have a chance to learn about failed login attempts * this can (likely?) be configured in our already existing configuration file in security-misc * Lockout reset is preventable, tally reset cannot be configured out and the largest possible delay between resets that can be set is arbitrarily limited to 7 days. == desktop-config-dist rd.live.image == * FYI: this is now fixed in git. no more patch for live-build required. == ISO - port to live-build == * check derivative-maker source code git history: previously there was a port to live-build. Useful to resurrect it? * port to live-build * make use of Debian's dracut branch for live-build * add live-build git submodule to derivative-maker (as long all our changes aren't upstramed) * WIP config repo for building Kicksecure with live-build: https://github.com/ArrayBolt3/kicksecure-live-build * Fork of live-build used: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads == live-build - use derivative-maker variable APT_OPTIONS == * for reference, see derivative-maker help-steps/variables APTGETOPT, APTGETOPT_ALT, APTGETOPT_WITHOUT_APT_CACHE * set live-build APT_OPTIONS to APTGETOPT * these include --error-on=any and more == live-build - investigate options == * because it contains options and todo * (originally from build-steps.d/1350_create-iso-config) * not all comments might be needed. some of my comments might be superfluous / obvious.
   ## folder derivative-maker/live-build can be re-created using:
   ## 2. help-steps/live-config

   ## TODO: cleaner to not have these? better for reproducible builds?
   #--apt-indices false
   # arraybolt3: Added.

## Kicksecure enabled backports by default so live-build does not need to
## (kicksecure ships /etc/apt/sources.list.d/debian.list static file in package anon-apt-sources-list)
   #--backports true|false
   # arraybolt3: Left unset, seems to work.

## Should not be done at live-build level if avoidable? Better done in package live-config-dist as /etc/default/grub.d drop-in
   #--bootappend-live PARAMETER|"PARAMETERS"

## Probably not needed.
   #--checksums md5|sha1|sha224|sha256|sha384|sha512|none
   # arraybolt3: left unset
   #--debian-installer cdrom|netinst|netboot|businesscard|live|none
   # arraybolt3: This MUST be set to "--debian-installer=live" (different values other than "none" may also work?). Not doing so results in the on-CD apt repo that contains bootloader packages not being created, and alternate ways of making that repo ended up erroring out in my experiments.

   ## Kicksecure enables fasttrack repository by default. If build works, probably not needed.
   #--keyring-packages PACKAGE|"PACKAGES"
   # arraybolt3: left unset, but perhaps it should be set to include the fasttrack repository key. Currently I'm using "--debootstrap-options" to include it.

   #--cache-stages "bootstrap rootfs"
   # arraybolt3: left unset. This automatically "just works".

## For cross-build support.
   # --architecture "$dist_build_target_arch"
   # arraybolt3: Note that for cross builds to work, this must be paired with "--bootstrap-qemu-arch" if building for a foreign architecture like arm64. Needs testing.

   ## --distribution "$dist_build_apt_stable_release"

## TODO: should we keep as is (Debian default) for better compatibility or set to
##       $SHORT_VMNAME / $VMNAME (already defined in help-steps/variables) to avoid conflicts with Debian (dual-boot)?
   ## --hdd-label LABEL
   ## --image-name NAME
   ## --iso-application NAME
   ## --iso-publisher NAME
   ## --iso-volume NAME

## Not applicable?
   ## --hdd-size SIZE

## TODO: source not needed
   # --source
   # arraybolt3: left unset, defaults to false.

## yes. not bothering/mixing any other bootloaders such as isolinux (except shim, which live-build handles automatically)
   # --bootloaders grub-efi
   # arraybolt3: left unset, live-build figures this out automatically and generates an ISO that is both BIOS-bootable and UEFI-bootable with GRUB by default.

## already existing variable
  # --linux-packages "$BUILD_KERNEL_PKGS"
  # arraybolt3: set to install linux-image and linux-headers. May be set differently once integration with derivative-maker is done.

## already existing variable
## usability feature
## we want kernel headers installed by default (required for tirdad compilation (has a dependency); virtualbox guest utils (lacks dependency))
## probably
   ## --linux-packages "$BUILD_HEADER_PKGS"

## We can probably set this because we cache using ${REPO_PROXY}? Double caching not useful?
## This option might have side effects.
   # --cache-packages false

   ## TODO: Does this work? Is our apt-cache-ng (already existing variable ${REPO_PROXY}) functional?
   # --apt-ftp-proxy "${REPO_PROXY}"
   # --apt-http-proxy "${REPO_PROXY}"

## important. using apt with --no-install-recommends
## but not setting and apt config file for the user
      # --apt-recommends false \
      # arraybolt3: already set.

## if using debootstrap
## important because we pull packages using packaging not using $debootstrap or live-build
      # --debootstrap-options "--variant=minbase" \
      # arraybolt3: set.

## if using mmdebstrap
## '--variant=required' is only supported by 'mmdebstrap'. It might not be supported by 'debootstrap'.
      # --debootstrap-options "--variant=required" \
      # arraybolt3: "required" and "minbase" appear to be treated identically by mmdebstrap, therefore not setting this.

## same as above
   # --firmware-binary false
   # --firmware-chroot false
   # arraybolt3: already set.

## Seems correct.
      # --binary-image iso-hybrid \
      # arraybolt3: set.


   lb config \
      --distribution "$dist_build_apt_stable_release" \
      --mirror-binary "$dist_build_apt_sources_mirror" \
      --mirror-binary-security "$dist_build_apt_sources_security_mirror" \
      --mirror-bootstrap "$dist_build_apt_sources_mirror" \
      --mirror-chroot "$dist_build_apt_sources_mirror" \
      --mirror-chroot-security "$dist_build_apt_sources_security_mirror" \
      --mirror-debian-installer "$dist_build_apt_sources_mirror" \
      --parent-mirror-binary "$dist_build_apt_sources_mirror" \
      --parent-mirror-binary-security "$dist_build_apt_sources_security_mirror" \
      --parent-mirror-bootstrap "$dist_build_apt_sources_mirror" \
      --parent-mirror-chroot "$dist_build_apt_sources_mirror" \
      --parent-mirror-chroot-security "$dist_build_apt_sources_security_mirror" \
      --parent-mirror-debian-installer "$dist_build_apt_sources_mirror" \
      --archive-areas "main contrib non-free non-free-firmware" \
## use $dist_build_apt_stable_release instead of hardcoded "bookworm"
    --distribution "bookworm"

## probably needed? same as Kicksecue default APT sources archive areas
## should we get this by parsing? in buildconfig.d/25_apt_sources.conf
    --archive-areas "main contrib non-free non-free-firmware" \

## sources not needed
    --apt-source-archives false \
    --source false \

## zsync not used
    --zsync false \

## useful? irrelevant?
    # --chroot-filesystem ext4 \
    # --binary-filesystem ext4 \
    # arraybolt3: both seem irrelevant.

## useful to see what is going on. why not.
    # --verbose \
    # --debug
    # arraybolt3: set.

## sanity testing and nice to compare logs
lb config --dump
lb config --validate

## better verbose than not knowing what is going on
lb build --verbose --debug
== live-build - keep generated live-build folder out of source code folder == * treat "lb config" as pristine/source code * place live-build folder in ~/derivative_binary folder (use already existing variable binary_build_folder_dist) * reason: live-build mixes config and binaries inside the same folder This is how it was done in the past:
   mkdir --parents "$binary_build_folder_live_build"
   cd "$binary_build_folder_live_build"
== live-build - build raw images == Building fully persistent images? Replacing grml-debootstrap?
--system normal
--binary-image hdd
Useful? Low priority? arraybolt3: this would potentially be very useful, will investigate. == live-check - run once only == * to avoid log spam (passwordless root) * create a done file in folder /run/user/$USER so the livecheck script does not run sudo over and over again == rootless X11 == * only if doable with low effort such as just changing some configs (such as in lightdm config) or changing some installed packages == review root related documentation == * read * improve * https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation ** Read, added improvements including rewriting the console login attacks section. * https://www.kicksecure.com/wiki/Root ** Read, added improvements including documenting how to run GUI applications as root under Wayland * https://www.kicksecure.com/wiki/Default_Passwords ** Read, didn't see anything that needed added. * https://www.kicksecure.com/wiki/Protection_Against_Physical_Attacks * https://www.kicksecure.com/wiki/Dev/boot_modes == fix broken recovery mode == * Recent Kicksecure ISOs seem to simply hang during boot when booted in recovery mode. Investigate. == audio == === audio generally === * https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879/40 * please read, comment if something useful to share === VirtualBox Intel HD Audio and PipeWire Incompatibility / Audio broken after increasing ram to 5 GB / No sound after latest updates - PipeWire Bug? === * https://forums.whonix.org/t/virtualbox-intel-hd-audio-and-pipewire-incompatibility-audio-broken-after-increasing-ram-to-5-gb-no-sound-after-latest-updates-pipewire-bug/18211 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081965 * please investigate if doable with reasonable effort * Tried switching between Pulseaudio and Pipewire on a booted VM, discovered I could "initialize" the speakers with Pulseaudio and then Pipewire would work thereafter * Virtually certain this is an upstream bug, was able to reproduce with both Ubuntu 24.04 and Arch Linux. * Suggest switching to AC97 audio (even Arch Linux defaults to this under Virtualbox). * Need to investigate upstream code * Could not get any meaningful hints from pipewire, wireplumber, and pipewire-pulse logs. Pulseaudio shows an "alsa woke us up to write new data to the device but there was actually nothing to write" error in its logs. At this point this is likely to be a bug in VirtualBox or the snd-hda-intel kernel driver. == Kicksecure grub-theme == * maybe https://github.com/AdisonCavani/distro-grub-themes can be helpful? * add to https://github.com/Kicksecure/kicksecure-base-files == Whonix grub-theme == * similar to above * add to https://github.com/Whonix/whonix-base-files * possible make a slightly different theme for [[Whonix-Host]], [[Whonix-Gateway]] and [[Whonix-Workstation]]? ** https://github.com/Whonix/anon-gw-base-files ** https://github.com/Whonix/anon-ws-base-files == review and refactor meta packages == * https://github.com/Kicksecure/kicksecure-meta-packages * https://github.com/Whonix/whonix-meta-packages * please review, discuss * purpose of this task is to address and (maybe required) refactoring, bug fixes in preparation for the future, maintainability, next task below == Split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server == * https://github.com/Kicksecure/security-misc/issues/187 * This is in preparation for the next task. == Kicksecure Firewall == https://forums.kicksecure.com/t/kicksecure-firewall/378/10 == Meta Packages, Kicksecure, Whonix - Desktop versus Server == https://forums.kicksecure.com/t/meta-packages-kicksecure-desktop-versus-kicksecure-server/415 == Secure Mount Options for better Security Hardening == * review discussions, wiki * comment * improve the solutions research * https://www.kicksecure.com/wiki/Dev/remount-secure * https://www.kicksecure.com/wiki/Noexec * https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/7707 == wipe video RAM == * add wipe video RAM support to [[ram-wipe]] * maybe based on https://wiki.archlinux.org/title/Swap_on_video_RAM * if doable with reasonable effort == Tor 0.4.8.9 broken in combination with vanguards == * https://gitlab.torproject.org/tpo/core/tor/-/issues/40892 * write a script to use git bisect to auto test which commit introduced this issue * if not done by upstream yet * if doable with reasonable effort == Implement live mode with 90overlayfs == * context: [[grub-live]] * https://github.com/Kicksecure/grub-live * https://github.com/Kicksecure/grub-live/blob/master/etc/grub.d/11_linux_live * stop using 90overlay-root * port grub-live to 90overlayfs * This does not work in Bookworm, but does work in Trixie. * Once Trixie is released and we're upgrading Kicksecure to it, switch modules. See https://github.com/dracutdevs/dracut/issues/1565#issuecomment-2378133277 == VirtualBox serial console == * {{CodeSelect|inline=true|code= sudo apt install serial-console-enable }} * [[Recovery#Serial_Console|Serial Console]] * causes bug (spam of journal) * https://forums.whonix.org/t/serial-console-in-virtualbox/8021/13 * fixable? upstream bug report? == KVM related == === KVM - 3D Graphics Acceleration - SPICE - Testing - drm === * please test: https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm * please mention your configuration (still using SPICE), quote Patrick and report here: https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22 * test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm * test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance === KVM - 3D Graphics Acceleration - Performance Test - Display SDL === * https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22 * test SDL * test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm * test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance === KVM - 3D Graphics Acceleration - Performance Test - Display GDK === * https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22 * test GTK * test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm * test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance == apparmor.d review == * https://github.com/roddhjav/apparmor.d * https://forums.whonix.org/t/apparmor-d-full-set-of-apparmor-profiles-1500-profiles/17389 ** review * https://github.com/roddhjav/apparmor.d/issues?q=is%3Aissue+author%3Aadrelanos ** check ticket status * lightweight security review ** conceivable or too much effort? = WAITING ON = == kloak - add Qubes support == * review to understand the history: ** https://github.com/QubesOS/qubes-issues/issues/1850 * [https://github.com/QubesOS/qubes-issues/issues/8534 enable qvm-service gui-agent-virtual-input-device for Whonix-Workstation App Qubes by default] ** https://github.com/QubesOS/qubes-gui-agent-linux/pull/194 ** https://github.com/QubesOS/qubes-app-linux-input-proxy/pull/30 * notify https://github.com/vmonaco/kloak/issues/74 Aaron: * Final implementation needs orchestration, asked for advice from Qubes OS devs at https://github.com/QubesOS/qubes-issues/issues/1850#issuecomment-2374908358 * May also implement as part of GUI daemon, see https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699 == kloak - Qubes support - consider using Qubes API for orchestration == * https://github.com/QubesOS/qubes-issues/issues/1850#issuecomment-2374908358 * Waiting on response from Qubes OS devs == kloak - Qubes support - implement kloak within qubes-gui-daemon == * https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699 * Ensure code is modular and can be easily broken out into a separate library or executable if requested by Qubes devs * Use common code between standalone version and Qubes version to keep differences as small as possible (perhaps create libkloak?) * Prototype implemented and mostly working, draft PR at https://github.com/QubesOS/qubes-gui-daemon/pull/149 * Waiting on response from Qubes OS devs * Got response and review, currently working out final implementation and doing testing == live-build - local repository support == * add support to build from local repository * Merge request: https://salsa.debian.org/live-team/live-build/-/merge_requests/369 == live-build - add mmdebstrap support == * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031932 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031929 * Merge request: https://salsa.debian.org/live-team/live-build/-/merge_requests/370 == live-build - use APT with error-on-any == * use option apt --error-on=any for all invocations of apt-get (update) * only needed for apt-get update, otherwise superfluous but non-issue * this is a security feature * this is to prevent inconsistent images that succeeded connecting to the "normal" repository but failed to connect to the security repository * can be implemented using already existing live-build option --apt-options OPTION|"OPTIONS"? * Requires a patch to live-build. Using --apt-options results in a build failure with E: Command line option --error-on=any is not understood in combination with the other options * Patch written, submitted upstream as https://salsa.debian.org/live-team/live-build/-/merge_requests/371. New configuration option now used in my branch of live-build. == security-misc - investigate PAM == * there is /etc/pam.d/sudo-i for interactive and /etc/pam.d/sudo * pam has concepts of common-session-noninteractive vs common-session (non-interactive) * how could we on the PAM level notice if faillock is used interactively or non-interactively? * if non-interactive, skip faillock * if interactive, do not skip faillock * Bug report: https://github.com/linux-pam/linux-pam/issues/842 = REVIEW PLEASE = = ARCHIVED = == security review == * as discussed * done, notes shared in chat == live-build - stop installation extraneous packages == * dhcp / networking related packages * whiptail * should not be pulled by live-build * if deemed useful packages, needs to be discussed in forums and and done inside the derivative-maker /packages/ folder through Depends: * Looks like this is solved, cannot find isc-related packages, ifupdown, or whiptail in my latest build. == live-build - dracut related fixes == * please report and/or fix upstream anything dracut related that needs fixing due to new results with live-build * Reported the one main issue I ran into at https://salsa.debian.org/live-team/live-build/-/merge_requests/353#note_537378, verified that other issues I had encountered were no longer a problem. == kloak - add support for /dev/input/mice == * VM has no /dev/input/mouseX * VM has only /dev/input/mice * kloak ignores /dev/input/mice. * (user reported using a Ubuntu 24.4 VM) * kloak only uses /dev/input/eventX devices by design, these are provided by the evdev driver and seem like they should always exist * Could not reproduce issue with QEMU using either Kicksecure or Lubuntu 24.04 - /dev/input/eventX devices for mouse always exist, as do individual /dev/input/mouse devices. Need to know what hypervisor was in use to test further Patrick: * asked user about which VM. waiting for reply. ** probably user error. archiving. == ISO - check git history == * check derivative-maker source code git history as it might have useful options * Found and extracted lb config command. Commit used was from 2023-07-20, and is the latest live-build commit on that day. == desktop-config-dist package version issue == * kicksecure /dists/bookworm-developers/main/binary-amd64/Packages
Package: desktop-config-dist
Version: 3:10.1-1
desktop-config-dist(master)]% git describe              
10.1-1
* todo: investigate ** How did an outdated desktop-config-dist version (older than in git) end up in the test ISO? Did it install packages from local repository? Then this issue should be impossible to happen. Or did it test wise use the remote, stable repository? Then this is not surprising. The stable repository often has older versions. These are for the most part only updated once a new stable release has been released. * note: updated due to below now * The version of the desktop-config-dist package installed on the ISO had contents older than in Git, but the version number was *newer*. This leads me to believe that most likely the machine used to build the ISO had testing code left in derivative-maker/packages/kicksecure/desktop-config-dist or similar. == research chvt security impact == * in context of root * Researched and added to console login attacks section of https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation. Does not appear to be a concern. == tirdad - fix == * please send a pull request for the recent tirdad fix to Kicksecure/tirdad * Merge commit at https://github.com/ArrayBolt3/tirdad-kicksecure/commit/2301b1c1413d8013b5c3b30976732bbf23d2f9ac, cannot open pull request due to having a fork of upstream already in my account. == Security Through Amnesia: A Software-Based Solution to the Cold Boot Attack on Disk Encryption == * https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e5f940decaa589f3b2030429f48739281839e4d8 * please read * add to [[Dev/confidential computing]] * Added notes, including one about a potential attack vector via NMIs. == wiki improvements related to Open Source hardware and firmware == * https://www.kicksecure.com/wiki/Open-source_Hardware * https://www.kicksecure.com/wiki/Out-of-band_Management_Technology * check for correctness * improve these pages * Added notes about OpenPOWER to the open-source hardware page. * Added notes about Computrace to the out-of-band management page. == e-mail processing == * read e-mail on confidential computing, digest, add to wiki (cannot be copied/pasted) * Added notes to confidential computing page. == keepassxc org.freedesktop.secrets Linux distribution compatibly feature request == * Shortcoming have been identified in https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/2 * Post a feature request for kepassxc what kind of changes they would have to make so keepssxc can be easily used as a org.freedesktop.secrets provider as a Linux distribution. ** Feature request at https://github.com/keepassxreboot/keepassxc/issues/11342 * kepassxc would probably need an /etc/kepassxc.d drop-in configuration folder where a distribution could add a configuration snippet to enable this functionality. * Post the link to the feature request in the forum thread. ** https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/4 == research enclaive == * https://github.com/enclaive == research constellation == * https://github.com/edgelesssys/constellation ** https://www.edgeless.systems/press-release-edgeless-systems-releases-first-runtime-encrypted-kubernetes-as-open-source * https://www.edgeless.systems/docs/ * https://docs.edgeless.systems/continuum/ * https://docs.edgeless.systems/continuum/security-goals * https://docs.edgeless.systems/continuum/attestation/overview * https://www.edgeless.systems/products/contrast * Added Constellation, Contrast, and Continuum to Confidential Computing page with notes (Constellation looks particularly handy if one trusts a silicon vendor) == research Intel TDX == * https://en.wikipedia.org/wiki/Trust_Domain_Extensions * https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html * https://github.com/intel/tdx-module * https://azure.microsoft.com/en-us/blog/azure-confidential-computing-on-4th-gen-intel-xeon-scalable-processors-with-intel-tdx/ * Integrated research into confidential computing page. == ISO - wrong bootloader entry == * https://forums.kicksecure.com/t/boot-issue-after-installking-kicksecure/602/16 * Unsure why this happened. Debian's Wiki has a recorded instance of this happening (at the bottom of https://wiki.debian.org/GrubEFIReinstall) and the suggested workaround is to install rEFInd instead of GRUB. == ISO - fallback boot loader broken == * Similar to above. * Ultimately this is not something we can fix until the migration to live-build is done. ** Debian Live doesn't install with a fallback bootloader enabled *at all* by default, only the Debian-specific path has a bootloader installed to it. ** Ubuntu installs a special "fix the UEFI NVRAM vars" bootloader under \EFI\BOOT\BOOTX64.EFI but that's Ubuntu-specific it appears. ** There is an option in Debian that allows always installing the GRUB bootloader to the fallback bootloader path in addition to the normal installation location (https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path). This option would work great for us, however it requires that grub-efi-amd64 be installed, which requires grub-pc to be uninstalled, which looks like it will probably cause issues on non-UEFI systems. ** At this point we have to choose to have either slightly broken UEFI, or slightly broken BIOS, there is no middle ground until the live-build migration is complete. However, we may be able to tell Calamares to ''not'' install a fallback bootloader of its own anymore since this bootloader doesn't work at all. == ISO - calamares - logo size reduction == * On the first page of calamares installer the Kicksecure logo looks a bit out of place because it is way to large. Please reduce the size a bit. * Done in https://github.com/ArrayBolt3/live-config-dist/commit/15eb4be99fd5d933c3067c982a9a6ad3f4d06d23 == ISO - calamares - encrypt button bug == * See video provided. * Followed up with Calamares developers. There don't appear to be blockers, the devs are just short on time and haven't gotten around to merging the fix yet. * https://github.com/calamares/calamares/pull/2376 * https://github.com/calamares/calamares/issues/2375 * https://github.com/calamares/calamares/issues/2379 == ISO - live-config - dist shellprocess_fixconkeys_part == * Why is this required? Please report, fix this issue upstream in calamares, if possible. Otherwise, please add a comment to the file in live-config-dist so these files can be removed some day. * Reported upstream at https://github.com/calamares/calamares/issues/2383 == research Secure Cloud Hardware == * [[Dev/confidential_computing#Secure_Cloud_Hardware_TODO_Research_List|Secure Cloud Hardware TODO Research List]] * Done, notes added to confidential computing Wiki page. == research AMD Infinity Guard == * https://www.amd.com/en/products/processors/server/epyc/infinity-guard.html * https://www.kicksecure.com/wiki/Dev/confidential_computing#AMD_Infinity_Guard * Added a note to the confidential computing page, this is basically just branding for a number of other technologies, all of which are either not directly relevant or have been previously covered. == tirdad == === tirdad - read history and old discussions === * https://dl.acm.org/citation.cfm?id=1180410 * https://forums.whonix.org/t/tcp-isn-cpu-information-leak-protection-tirdad/8552 * https://phabricator.whonix.org/T543 -> broken link -> nowadays -> https://forums.whonix.org/t/cpu-induced-latency-covert-channel-countermeasures/18875 * https://trac.torproject.org/projects/tor/ticket/16659 -> https://gitlab.torproject.org/legacy/trac/-/issues/16659 * Read through all linked information. === tirdad - functionality review === * please investigate tirdad more closely * https://bitguard.wordpress.com/2019/09/03/an-analysis-of-tcp-secure-sn-generation-in-linux-and-its-privacy-issues/ * check references, theory, implementation * Reviewed, theory makes good sense, implementation could be improved but that's for future tasks === tirdad - backports compatibility === * currently failing to compile using backports kernel * https://forums.whonix.org/t/using-kernels-from-backports/20503/5 * https://github.com/0xsirus/tirdad/issues/24 * please check if https://github.com/0xsirus/tirdad/commit/4720311ff21c3f71cc5e3670caf5dfde2b31c5f8 looks good and test * Verified that this commit does indeed fix the issue. === tirdad - fix code issues === * 1 pull request per issue as found in your security review * Some of the pull requests ended up fixing multiple issues simply by virtue of the fact that fixing some of the issues resulted in problematic code being removed entirely and thus no longer a concern. * Pull requests: ** https://github.com/0xsirus/tirdad/pull/25 ** https://github.com/0xsirus/tirdad/pull/26 ** https://github.com/0xsirus/tirdad/pull/27 === tirdad - upstream to Linux === * please discuss upstream * see if it is possible to send a pull request upstream === tirdad - compile time hardening flags review === * Any compile time hardening flags that could be set? * Setting compile-time flags could be dangerous. Would recommend just sticking with the defaults in the kernel. === tirdad - lwn article review === * https://lwn.net/Articles/455270/ * something important to know there? * Using random 32-bit numbers from the kernel's RNG will avoid any potential security issues like the ones described here. === tirdad - development branch === * Please create a development branch that comes with all your PRs merged. * This has been completed by Aaron in the rewrite branch. == boot issues debugging == * increased priority because the user is still available * https://forums.kicksecure.com/t/boot-issue-after-installking-kicksecure/602 * The user might be no longer available. But for the future, can we have a checklist on how to debug the boot process? * Perhaps even a pre-installed script that can be run from live mode or from inside the broken system (if it is known that it would be no longer bootable after reboot)? * https://packages.debian.org/bookworm/boot-info-script is already installed by default. Helpful? * Please document here: [[Broken Boot]] == research AMD TSME == * https://www.kicksecure.com/wiki/Dev/confidential_computing#AMD_TSME * sounds better than SME * Researched and notes added to confidential computing doc. == investigate locale issue == * https://forums.kicksecure.com/t/locale-layout-installation-error/611 * Issue identified and fixed: https://github.com/ArrayBolt3/live-config-dist/commit/fe3eb5da1a8a2c464026941c572e61de90d3e6e6 == tirdad == === security review tirdad.c === * please review for code safety issues (memory safety) * security review only for now * functionality review at a later point * https://github.com/Kicksecure/tirdad/blob/master/module/tirdad.c * please report issues, if any, upstream: https://github.com/0xsirus/tirdad * https://chatgpt.com/share/67029e9f-8e30-8000-9a22-114ff13c2b93 * Review at https://github.com/0xsirus/tirdad/issues/23 == hardware security features for RamCrypt == * If software-only isn't possible, maybe hardware features such as SGX need to be used. ** SGX itself does not appear to be useful for us. It allows running security-sensitive code in a secure "box" that nothing else on the system can pry into, but that security-sensitive code is limited in capabilities. It does not appear to be possible to run an entire virtual machine in an SGX enclave. ** Intel TXT and TME-MK are much better suited for our purposes. * todo research: Are there still unpatched security issues in SGX or similar features that could be used for that? ** It appears known issues are patched in the latest processors. Microcode updates were used to fix some of the issues. == report GTK touchscreen detection bug == * GTK should not be using hardcoded device names to detect "fake" touchscreens * https://forums.whonix.org/t/weird-magnifier-feature/20502/12 * Reported at https://gitlab.gnome.org/GNOME/gtk/-/issues/7060 == investigate kloak bugs == * https://forums.whonix.org/t/weird-magnifier-feature/20502 ** "marking text in mousepad shows magnifier" (confirmed by Patrick) ** "marking text in thunar shows magnifier" (confirmed by Patrick) ** "mousepad app I can scroll a long text as if I were swiping up and down with a touchscreen device" (not reproducible by Patrick) ** "no highlighting of mouse context menu and no highlight on system wide menu" (not understood) ** Turns out to be because of how GTK handles "fake" touchscreens, see https://forums.whonix.org/t/weird-magnifier-feature/20502/12 ** Fixed in https://github.com/Whonix/kloak/commit/d4e7b4c0428527ea002e1ea61839effc0cb5e88e == research Intel / AMD RAM Encryption == * https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdf * https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.html * https://www.kernel.org/doc/html/next/x86/amd-memory-encryption.html * https://www.trentonsystems.com/en-us/resource-hub/blog/what-is-intel-tme * https://forums.whonix.org/t/enable-secure-memory-encryption-sme-kernel-parameter-mem-encrypt-by-default/10393 * https://en.wikichip.org/wiki/x86/sme * https://en.wikichip.org/wiki/x86/tme * Researched and added to Whonix Dev/cloud page. tl;dr: AMD SEV and SME does not seem suitable. Intel TME-MK appears promising. == pKVM research == * research if pKVM assumes a locked down host and/or remote attestation (Google SafetyNet) * Researched and added to Whonix Dev/cloud page == dracut follow-up == * https://github.com/dracut-ng/dracut-ng/issues/684 * https://github.com/dracut-ng/dracut-ng/pull/609 * Tested commit, followed up at https://github.com/dracut-ng/dracut-ng/issues/684#issuecomment-2394398786, this is done == calamares luks encryption settings ticket == * please reply https://github.com/calamares/calamares/issues/2374 * replied: https://github.com/calamares/calamares/issues/2374#issuecomment-2394028666 == secure cloud research == * move notes from chat to wiki * Revamped Confidential VMs section in wiki == RamCrypt + no-fill cache mode == * Draft an email for the kernel development mailing list asking about the possibility of 100% RAM encryption, mounting CPU cache as RAM for the 3%.
Subject: Investigating practicality of full memory encryption techniques using frozen cache and TRESOR/RamCrypt

I am currently helping with software development for the Kicksecure and Whonix projects, which are heavily focused on privacy and security. One of the goals we'd like to achieve is making it possible to securely run virtual machines on x86_64-architecture cloud servers in a manner resistant to cold-boot attacks, without relying on technology such as Intel SGX and TDX or AMD SEV that requires trusting CPU-vendor-provided code, keys, etc.

The two main technologies we're looking into for this purpose are TRESOR[1] and RamCrypt[2]. TRESOR is a full disk encryption mechanism that stores all disk encryption keys in CPU registers, such that the key is never[3] stored in RAM. If used on the hardware of a VM host, this would prevent a cold-boot attack from finding the disk encryption key. RamCrypt is a full memory encryption mechanism that uses the same technique as TRESOR to hide an encryption key inside the CPU, using it to transparently encrypt and decrypt the memory of running applications using memory paging techniques. Both of them have working proof-of-concept implementations described in the linked papers. Our hope is to eventually get fully functional, production-ready TRESOR and RamCrypt implementations created and upstreamed into the Linux kernel. For the avoidance of doubt, I am not the author of or a contributor to either TRESOR or RamCrypt.

One issue we have with RamCrypt is that it leaves part of a protected process's memory unencrypted in RAM as necessary. By default, up to four 4k pages of RAM are unencrypted at a time, with new pages being decrypted and older ones being encrypted transparently as needed. This has the serious disadvantage of making a cold-boot attack potentially successful, even if it is statistically unlikely to work. The chances of a successful attack against RamCrypt are non-negligible - the RamCrypt paper shows that a RamCrypt-protected nginx instance left a critical encryption key exposed in RAM 3% of the time in their test scenarios. This is worrying to us, and we're wondering if there is a way to prevent this from being a problem.

Our current hope is to use a cache-as-RAM technique (similar to what is described in the Frozen Cache[4] project) to potentially overcome this limitation. The idea, roughly speaking, is to ensure that protected process memory is only ever present in decrypted form in one of the CPU caches, and is prohibited from ever touching system RAM. When a page of memory is accessed that is encrypted, a previously decrypted page will be encrypted, written to system RAM, then an encrypted page will be decrypted into cache and used. Cache should be approximately as hard to access in a cold-boot attack as registers, thus this would allow a protected process to be immune to cold-boot attacks by never storing any sensitive data decrypted in RAM. It appears that no-fill cache mode could potentially be used for this purpose, though doing so without entirely destroying system performance seems like it would be tricky and probably require dedicating one or more CPU cores to running "protected" software with this modified caching mode.

The high-level end goal is to allow KVM-accelerated QEMU processes to be run encrypted via RamCrypt, with no unencrypted VM memory touching system RAM, and with the physical machine running TRESOR to protect the filesystem on which the VM virtual disks are stored. To begin with, though, it would be useful to know whether it's even possible with Linux's architecture to combine RamCrypt and no-fill cache mode to transparently encrypt a process's memory without exposing it decrypted in RAM. Some advice on how to go about implementing something along these lines would also be welcome, so that we can implement it in a way that is most likely to be accepted into the upstream kernel.

Thanks for taking the time to read this, and have a great day!

[1] https://faui1-files.cs.fau.de/filepool/projects/tresor/tresor.pdf
[2] https://faui1-files.cs.fau.de/filepool/projects/ramcrypt/ramcrypt.pdf
[3] Well, almost never - the key is briefly stored in RAM when read from whatever device provides it, but it is immediately expunged from RAM thereafter.
[4] https://frozencache.blogspot.com/
* Parick: minor corrections have been made. Please post. * Posted: https://lore.kernel.org/lkml/20241003194147.2566a393@kf-ir16/T/#u == ISO - Fix encryption checkbox bugs == * https://github.com/calamares/calamares/issues/2375 * https://github.com/calamares/calamares/issues/2379 * PR at https://github.com/calamares/calamares/pull/2376 == ISO - calamares encryption settings == * https://forums.kicksecure.com/t/iso-cryptsetup-full-disk-encryption-fde-set-more-secure-default-encryption-settings/588 * Can we use shell aliases or wrapper to influence cryptsetup default options to set strong encryption settings such as AES512 instead of only AES256? * https://github.com/calamares/calamares/issues/1452 * or add a calamares feature so distro developers or users can configure the cryptsetup command line options in /etc/calamares {{CodeSelect|code= sudo cryptsetup --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat }} * distribution developers should control most if not all of that line * "sudo" - is probably a given since cameras runs as root. * "cryptsetup" - maybe a distribution wants to use a wrapper. * "--verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random" these are certainly options which a distribution should be able to decide. * "luksFormat" - * "" - probably provided by calamares through a variable Based on theoretic considerations only. Since calamares uses a library to use cryptsetup (?) it may not be as simple for a distribution to set these command-line options? * Requires support in libkpmcore first, did research and started discussion at https://discuss.kde.org/t/making-libkpmcores-luks2-settings-more-secure/21764 to get the ball rolling * Received no response for approximately six days, filed an MR: https://invent.kde.org/system/kpmcore/-/merge_requests/54 Patrick: * on https://discuss.kde.org/t/making-libkpmcores-luks2-settings-more-secure/21764 please post a link to https://invent.kde.org/system/kpmcore/-/merge_requests/54 * on https://invent.kde.org/system/kpmcore/-/merge_requests/54 please post a comment such as (adjust as comfortable, after verification): ** No, /dev/random is not the same as /dev/urandom even on modern kernels. [Code Comparison - /dev/random vs. /dev/urandom](https://www.kicksecure.com/wiki/Dev/Entropy#Code_Comparison_-_.2Fdev.2Frandom_vs._.2Fdev.2Furandom) ** "cryptsetup --help" on Debian bookworm: * aes-xts-plain64 seems to be the default indeed. The argument of not hardcoding it to automatically get safer the default in the future makes sense. * Glad if we can get the hash size increase. Aaron: * Left desired notes on merge request: https://invent.kde.org/system/kpmcore/-/merge_requests/54#note_1044980 == org.freedesktop.secrets implementation == * https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582 * Researched and commented: https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/2 == Cloud virtualization - research RAM-less encryption techniques for disk and RAM encryption == See https://www.whonix.org/wiki/Dev/cloud#Confidential_VMs == live-build dracut test == * from a Debian perspective (because Kicksecure will start using it at some point) by building an ISO * please test and notify upstream about your test results * https://salsa.debian.org/live-team/live-build/-/merge_requests/353 * does the ISO have the "ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist" issue? (related to task below) * Trixie and Bullseye both work well, Bookworm fails to boot with a sysroot mount failure. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082891 == ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist == * https://forums.kicksecure.com/t/iso-error-message-during-boot-mount-sysroot-special-device-liveos-rootfs-does-not-exist/418 * fixed in https://github.com/ArrayBolt3/derivative-maker/commit/894d0657b7cd69370d67759709fff166d469cc37 ** Patrick: needs further work as discussed ** Patrick: please no modules in derivative-maker (if needed needs to be in a package) ** Patrick: please track down root cause * Root cause found, reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082891 == unbootable system after installing dracut on a standard Debian installation == * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792 * Caused by a missing dracut dependency, "systemd-cryptsetup", see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792#15 * Bugfix tested, works * Merge request in Debian at https://salsa.debian.org/debian/dracut/-/merge_requests/37 == grub-live with 90overlayfs == * context: [[grub-live]] * https://github.com/Kicksecure/grub-live * https://github.com/Kicksecure/grub-live/blob/master/etc/grub.d/11_linux_live * stop using 90overlay-root * port grub-live to 90overlayfs
## dracut support
## https://www.kicksecure.com/wiki/Grub-live#Developer_Information
##
## using Debian forked upstream module 90overlay-root (tested)
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rootovl"
Comment out.
## using dracut upstream module 90overlayfs (untested)
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.live.overlay.overlayfs=1 rd.live.overlay.readonly=1"
Comment in. Test. Fix if required. Report issues upstream to dracut. If there are bookworm related issues, please test on trixie. No backport required. The rationale of this task if to get away from Debian (fork) specific 90overlay-root to 90overlayfs one day. trixie is early enough since there are no major issues in the current implementation but might be in trixie if we don't port. This works on Trixie - generate an initrd with the overlayfs module added, then boot with rd.live.overlay.overlayfs=1 on the kernel command line. '''The rd.live.overlay.readonly=1 parameter is unnecessary''' and should be removed - it's for systems where you have an immutable base filesystem and a persistent overlay, and you want to make the overlay read-only, putting another overlay on top of it. This does '''not''' work on Bookworm - the overlayfs module script is simply not run despite being present. It's possible to drop to a rescue shell using rd.break=mount on the kernel command line, then run the script manually - this works, but is obviously not practical. comment: [https://github.com/dracutdevs/dracut/issues/1565#issuecomment-2378133277 Boot Existing, Usual Linux Installation from Hard Disk in Live Mode / read-only mode with dracut #1565] == dracut - test dracut without systemd == * as discussed earlier * as it might fix the issue below * Works, implemented as https://github.com/ArrayBolt3/derivative-maker/commit/894d0657b7cd69370d67759709fff166d469cc37 ** Patrick: not going for this solution (as we would be the odd distribution out not using systemd in dracut, to avoid bugs as a result of that) ** Patrick: instead merged with task [[Dev/todo#ISO_-_error_message_during_boot:_mount:_.2Fsysroot:_special_device_LiveOS_rootfs_does_not_exist|ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist]] == kloak - memory leaks == * chatgpt suggests... ** struct entry in main loop might not be freed ** n1 = malloc(sizeof(struct entry)); ** please check for other variables (specifically in main loop) which might not be freed * Double-checked just in case, this had been previously checked in my own ChatGPT code review and doesn't appear to be a problem. Entry items are created and stored temporarily in *n1, then queued. Those items are later assigned to the np variable and then freed in the event release loop (free(np)). The only edge case where I can see this going wrong is if kloak gets stuck and stops delivering events, which would also freeze the keyboard and make the user very likely to immediately termiante kloak. * The other variable which ChatGPT warned me of is pfds, which is very clearly freed when the loop exits, needed throughout the loop's entire lifetime, and which will be automatically freed if the loop is terminated since terminating the loop terminates the whole program. == kloak - Qubes support - read and comment in Qubes kloak in dom0 ticket == * https://github.com/QubesOS/qubes-issues/issues/8541 * please read * please consider related to previous Qubes kloak work, communicate with Qubes * consider future wayland support * note: kloak doesn't necessarily need to run in dom0. Even if it "only" runs in a VM is a big win. Final decision is up to Qubes. This is yet to be discussed, decided. * Added comment at https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699 == ISO - must choose encrypt vs not encrypt. Empty default setting == * https://forums.kicksecure.com/t/iso-no-default-for-encryption-on-off-user-should-choose-explicitly/567 * Done via https://github.com/ArrayBolt3/live-config-dist/commit/410c62e664e7d1387e7c013867242838ff2cb912 * Also discovered and offered a fix for https://github.com/calamares/calamares/issues/2375 while working on this == kloak - update readme == * Please make sure compilation instructions are OK. * Please check/fix readme. * https://github.com/ArrayBolt3/kloak/commit/4bbdf38cc6c6f9162348d9b23deef3169f8465b8 == kloak - fix debug symbols == === W: kloak-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/3a/ae8c705abefbd590d2206221eea4c2abd90cf4.debug] ===
N: 
N:   The binary is installed as a detached "debug symbols" ELF file, but it
N:   does not appear to have debug information associated with it.
N:   
N:   A common cause is not passing -g to GCC when compiling.
N:   
N:   Implementation detail: Lintian checks for the ".debug_line" and the
N:   ".debug_str" sections. If either of these are present, the binary is
N:   assumed to contain debug information.
N: 
N:   Please refer to Bug#668437 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: binaries/debug-symbols/detached
N: 
N:
* ISO build giving warning about missing debug symbols, advises adding -g flag to gcc commands * Should be resolved by https://github.com/ArrayBolt3/kloak/commit/29477f98d1192ced4fb0e630c07dbd8b97942d22 == read Dev bash wiki page == * https://www.kicksecure.com/wiki/Dev/bash * might be already known, just in case * checked it, bookmarked it, some of the issues mentioned there were things I hadn't thought of before (like echo '-e' failing or security risks from failing to use -- to signal end of options) == haveged test suite passes even if only 1s are produced? == * please try to reproduce * comment on the ticket * https://github.com/jirka-h/haveged/issues/81 * Doesn't appear to be an issue, tweaking the generator to output only 1s results in test failures, see https://github.com/jirka-h/haveged/issues/81#issuecomment-2372664967 == oomd == * please comment in case you have any useful input. otherwise nvm. * https://forums.kicksecure.com/t/consider-installing-systemd-oomd-by-default/223 * Left comments at https://forums.kicksecure.com/t/consider-installing-systemd-oomd-by-default/223/4 == ISO - Install to system desktop icon: maximize window == * https://forums.kicksecure.com/t/install-to-system-desktop-icon-maximize-window/419 * Fixed with https://github.com/ArrayBolt3/live-config-dist/commit/ab8a7e1829f7050882385488a67e9a316a9270fd == gpg sign all your future git commits == * similar to https://github.com/onionshare/onionshare/issues/221 * arraybolt3: enabled permanently in Git settings == add gpg key to your github == * Currently in github commit history your keys still show up as unverified. * https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account * This is a personal decision for each developer. Some don't want to do it as it might cause a false sense of security letting github verify the gpg key. In case you don't wish to do that, this is OK too. * arraybolt3: Added to Github, doesn't pose any particular problem for me. == Add python3 dependency to mediawiki-shell package == * Lintian error during build of Kicksecure ISO from derivative-maker commit 8fa4ba76: "E: mediawiki-shell: python3-script-but-no-python3-dep /usr/bin/python3 (does not satisfy python3:any | python3-minimal:any) [usr/bin/mw-urlencode]" == seccomp debugging documentation == copy notes on seecmop debugging from https://github.com/Whonix/kloak/pull/1 to https://www.kicksecure.com/wiki/Seccomp (so in the future when this is happening, we can link to the documentation so users get an idea how to debug and fix this) just briefly similar to the pull request == autostart systemd user unit xdg-desktop-portal == * [[Dev/audio#mod.rt:_Can.27t_find_org.freedesktop.portal.Desktop._Is_xdg-desktop-portal_running.3F|mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?]] * https://github.com/Kicksecure/desktop-config-dist * note: is a systemd user (not system) unit * using systemd preset == kloak - add configuration option to disable rescue key == * user reported that some hotkeys aren't functional due to kloak rescue key. * suggested solution, feature request: allow rescue key to be disabled thorough configuration * a command line option + systemd unit drop-in configuration file? * example systemd unit drop-in configuration: https://github.com/vmonaco/kloak/issues/75#issuecomment-2196543109 == kloak - testing == * test kloak * improve documentation on testing https://www.whonix.org/wiki/Keystroke_Deanonymization#Defense_Testing * maybe try to find additional tests (if needed) using perplexity.ai == kloak - document rescue key == * https://www.whonix.org/wiki/Keystroke_Deanonymization#Kloak * document: rescue key * document: disable rescue key == kloak - makefile fix == * Makefile should check if pkg-config exist because otherwise it fails with libevdev error? == kloak - verbose log sharing == Documentation is currently stating:
Warning: Privacy implications of log sharing are unknown!
Might verbose log reveal the typing fingerprint of the user? == kloak - mouse click obfuscation == * please confirm https://github.com/vmonaco/kloak/issues/51 == kloak - xrdp support == * is xrdp support conceivable? * user reports: when using xrdp, only /dev/input/event0 is there, which does not contain real keystroke. * This does not seem possible. xrdp is its own X server, logging keystrokes at the X server level is doable but intercepting them does not appear to be doable, see https://www.kicksecure.com/wiki/Progress_Reports?shownotice=1#Investigate_xrdp_support. == kloak development == * instead of this list, does it make more sense to review pull requests, issues and rewrite in python? (Works just fine in C, rewrite not planned at this time) * strong compile time hardening flags (done) * goal: perfect string parsing and error handling in case of corner issues, to not break input devices (keyboard, mice) (doesn't appear that much string parsing is done, currently not considered an issue) * check pull requests, merge if sensible ** Add a header file to make future development easier - https://github.com/vmonaco/kloak/pull/61 (done) ** Chatgpt3 https://github.com/vmonaco/kloak/pull/65 (done) ** update readme - https://github.com/vmonaco/kloak/pull/70 (specific to vmonaco's version of Kloak, not Whonix's) ** add support for new devices attached after kloak starts (needs cleanup) - https://github.com/vmonaco/kloak/pull/67 (done) * code review with ChatGPT, claude.ai (done) * use AddressSanitizer (aka ASan) if doable with reasonable effort and considered useful (done) * port to C++ if considered useful (rewrite not planned at this time) * other improvements to increase stability ** strncpy - https://github.com/vmonaco/kloak/issues/66 (done) * fix compile time warnings if reasonable (probably already resolved by above) https://github.com/vmonaco/kloak/issues/35 (done) * ARM support, only if doable with reasonable effort - https://github.com/vmonaco/kloak/issues/25 (done) * fix time related keyboard stops working bug (done) ** https://github.com/vmonaco/kloak/issues/31 ** Root cause analysis and potential fixes: https://github.com/vmonaco/kloak/issues/31#issuecomment-2368666686 ** https://forums.whonix.org/t/sdwdate-can-cause-system-time-to-jump-backwards-causing-issue-with-kloak/20433 * All relevant issues should be solved by https://github.com/Whonix/kloak/pull/1 = backlog - one day = == power9 RAM encryption research == * todo == auto-detect, prompt for potential root devices in case the root= device is misconfigured or missing == * https://github.com/dracutdevs/dracut/issues/2589 * if doable with reasonable effort please send a pull request to dracut-'''ng''' * Pull request: https://github.com/dracut-ng/dracut-ng/pull/694 * update: as discussed, low priority if effort is too high == dracut add support for undeclared CDLABEL == as discussed = Footnotes = {{Footer}}