cultural reviewer and dabbler in stylistic premonitions

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

help-circle


  • Arthur Besse@lemmy.mlto196@lemmy.blahaj.zonethere is no rule
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    1 month ago

    17 × 59 = 10003

    you’ve got an extra zero in there, and you forgot the 1, but the rest of your divisors match my crude brute-force approach:

    >>> n=31521281
    >>> d = [ x for x in range(1,n//2+1) if not n%x ]
    >>> d
    [1, 11, 17, 59, 187, 649, 1003, 2857, 11033, 31427, 48569, 168563, 534259, 1854193, 2865571]
    >>> yours=list(map(int,"11+17+59+2857+11033+534259+1854193+2865571+168563+48569+10003+31427+649+187".split("+")))
    >>> set(yours) - set(d)
    {10003}
    >>> set(d) - set(yours)
    {1, 1003}
    >>> sum(d)
    5518399
    

    same conclusion though: 5518399 also ≠ 31521281

    bonus nonsense
    >>> isperfect = lambda n: n == sum(x for x in range(1,n//2+1) if not n%x)
    >>> [n for n in range(1, 10000) if isperfect(n)]
    [6, 28, 496, 8128]
    

    (from https://oeis.org/A000396 i see the next perfect number after 8128 is 33550336 which is too big for me to wait for the naive approach above to test…)

    more bonus nonsense
    >>> divisors_if_perfect = lambda n: n == sum(d:=[x for x in range(1,n//2+1) if not n%x]) and d
    >>> print("\n".join(f"{n:>5} == sum{tuple(d)}" for n in range(10000) if (d:=divisors_if_perfect(n))))
        6 == sum(1, 2, 3)
       28 == sum(1, 2, 4, 7, 14)
      496 == sum(1, 2, 4, 8, 16, 31, 62, 124, 248)
     8128 == sum(1, 2, 4, 8, 16, 32, 64, 127, 254, 508, 1016, 2032, 4064)
    




  • 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.







  • 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…)