cultural reviewer and dabbler in stylistic premonitions

  • 32 Posts
  • 111 Comments
Joined 2 years ago
cake
Cake day: January 17th, 2022

help-circle





  • xzbot from Anthony Weems enables to patch the corrupted liblzma to change the private key used to compare it to the signed ssh certificate, so adding this to your instructions might enable me to demonstrate sshing into the VM :)

    Fun :)

    Btw, instead of installing individual vulnerable debs as those kali instructions I linked to earlier suggest, you could also point debootstrap at the snapshot service so that you get a complete system with everything as it would’ve been in late March and then run that in a VM… or in a container. You can find various instructions for creating containers and VMs using debootstrap (eg, this one which tells you how to run a container with systemd-nspawn; but you could also do it with podman or docker or lxc). When the instructions tell you to run debootstrap, you just want to specify a snapshot URL like https://snapshot.debian.org/archive/debian/20240325T212344Z/ in place of the usual Debian repository url (typically https://deb.debian.org/debian/).


  • A daily ISO of Debian testing or Ubuntu 24.04 (noble) beta from prior to the first week of April would be easiest, but those aren’t archived anywhere that I know of. It didn’t make it in to any stable releases of any Debian-based distros.

    But even when you have a vulnerable system running sshd in a vulnerable configuration, you can’t fully demo the backdoor because it requires the attacker to authenticate with their private key (which has not been revealed).

    But, if you just want to run it and observe the sshd slowness that caused the backdoor to be discovered, here are instructions for installing the vulnerable liblzma deb from snapshot.debian.org.




  • Mattermost isn’t e2ee, but if the server is run by someone competent and they’re allowed to see everything anyway (eg it’s all group chat, and they’re in all the groups) then e2ee isn’t as important as it would be otherwise as it is only protecting against the server being compromised (a scenario which, if you’re using web-based solutions which do have e2ee, also leads to circumvention of it).

    If you’re OK with not having e2ee, I would recommend Zulip over Mattermost. Mattermost is nice too though.

    edit: oops, i see you also want DMs… Mattermost and Zulip both have them, but without e2ee. 😢

    I could write a book about problems with Matrix, but if you want something relatively easy and full featured with (optional, and non-forward-secret) e2ee then it is probably your best bet today.


  • As the image transcript in the post body explains, the image at the bottom is a scene from a well-known 1998 film (which, according to Wikipedia, was in 2014 selected for preservation in the United States National Film Registry by the Library of Congress as being “culturally, historically, or aesthetically significant”).

    This meme will not make as much sense to people who have not seen the film. You can watch the referenced scene here. The context is that the main character, The Dude (played by Jeff Bridges) has recently had his private residence invaded by a group of nihilists with a pet marmot (actually portrayed by a ferret) and they have threatened to “cut off his Johnson”. In an attempt to express sympathy, The Dude’s friend Walter (played by John Goodman) points out that, in addition to the home invasion and threats, the nihilists’ exotic pet is also illegal. The Dude’s retort “what, are you a fucking park ranger now” is expressing irritation with that observation, because it is insignificant compared with the threat of the removal of his penis.

    This meme attempts to draw a parallel between this humorous scene and XZ developer Lasse Collin’s observation that the XZ backdoor was also a violation of Debian’s software licensing policies.

    Thank you for reading my artist’s statement.







  • Arthur Besse@lemmy.mlMtoLinux@lemmy.mlHow the xz backdoor highlights a major flaw in Nix
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    3 months ago

    As of today, NixOS (like most distros) has reverted to a version slightly prior to the release with the Debian-or-Redhat-specific sshd backdoor which was inserted into xz just two months ago. However, the saboteur had hundreds of commits prior to the insertion of that backdoor, and it is very likely that some of those contain subtle intentional vulnerabilities (aka “bugdoors”) which have not yet been discovered.

    As (retired) Debian developer Joey Hess explains here, the safest course is probably to switch to something based on the last version (5.3.1) released prior to Jia Tan getting push access.

    Unfortunately, as explained in this debian issue, that is not entirely trivial because dependents of many recent pre-backdoor potentially-sabotaged versions require symbol(s) which are not present in older versions and also because those older versions contain at least two known vulnerabilities which were fixed during the multi-year period where the saboteur was contributing.

    After reading Xz format inadequate for long-term archiving (first published eight years ago…) I’m convinced that migrating the many projects which use XZ today (including DPKG, RPM, and Linux itself) to an entirely different compression format is probably the best long-term plan. (Though we’ll always still need tools to read XZ archives for historical purposes…)








  • That installs and or updates roots flatpaks

    Which is what flatpak will always do unless provided with the --user flag.

    By default it operates in system-wide mode, which is different from “root’s”.

    flatpak list and sudo flatpak list will both show you what is installed system wide, and flatpak list --user will show you your user’s, and sudo flatpak list --user will show you the root user’s flatpaks installed in per-user mode (of which there are typically none).