• 0 Posts
  • 82 Comments
Joined 4 months ago
cake
Cake day: March 28th, 2026

help-circle








  • while I agree with the sentiment. what if someone just sloppily hand-coded an insecure docker container, should you be able to kick that off too? I fear security isn’t a good baseline to decide if a project should be hosted because security is a gradient and it becomes very subjective to say what constitutes secure. following that, would you give remediation opportunities for hand-coded insecure projects? It’s a can of worms.

    I would argue that they can argue it purely from a capacity perspective.

    They can estimate the scale of handwritten code growing over a period of time, but not the scale of AI written code scaling, meaning their platform cannot anticipate the scale and therefore it is unsustainable. And at that point the scale of security awareness as a whole can be considered, e.g. “how many attack surfaces, e.g. repos, are we hosting?” vs “how many of our repos are insecure?”




  • Their goal? Can’t say. They clearly have a drive to make art, especially mathematical fractal binary minimalist art. Whether they also are actually producing malware or are just trying to piggyback as many services as possible to archive and keep their stuff online is another question. The vast majority of what I saw in my quick recon of their online presence was mostly glitch art/unicode/ascii art, blender stuff, fractals, web based d3 animations, that sort of thing. That being said, as you said, they appear to have gone to great lengths to be anonymous, I’ve only found a couple of raw IPs in there that mirror their stuff.

    That being said, it seems they also clone their backups to anyone who hosts a free forgejo/gitea instance:

    OOOOOOOOOOOOOOOO\ꓨЯO.ꓨЯƎᗺƎᗡOϽ CODEBERG.ORG/OOOOOOOOOOOOOOOO
    OOOO\MOϽ.ᗺUHƧꓨAᗡ DAGSHUB.COM/OOOO
    OOOO\u\MOϽ.ƎᗡOϽƎᗡOHЯ.ƎᗡOϽ CODE.RHODECODE.COM/u/OOOO
    oooo∽\TH.ЯƧ.TIꓨ GIT.SR.HT/~oooo
    OOOO\ꓨЯO.ꓨUᗺATOИ NOTABUG.ORG/OOOO
    O\000Ԑ:მ4.111.78.ਟ81 185.87.111.46:3000/O
    O\HϽƎT.TƎꓨƎᗺ.MUTИƎꓨA.TIꓨ GIT.AGENTUM.BEGET.TECH/O
    O\ᗡI.Oꓨ.ᗺAꞰꓨИAᗡƎMUƧ.TIꓨ GIT.SUMEDANGKAB.GO.ID/O
    OOOO\ƎTIƧ.ƧƎOᒐƧIƧIHT.TIꓨ GIT.THISISJOES.SITE/OOOO
    O\UƎ.ЯƎꓨИIᒧᒧƎ.TIꓨ GIT.ELLINGER.EU/O
    O\HƧ.1ᗡIꟼ.AƎTIꓨ GITEA.PID1.SH/O
    O\ᒧИ.ИƎЯƎOᗺЯƎIVIᒧO.TIꓨ GIT.OLIVIERBOEREN.NL/O
    O\ƎM.YꓨOᒧOИYƧ.ꓨИOƎᒐꞰƎ.AƎTIꓨ GITEA.EKJEONG.SYNOLOGY.ME/O
    O\𑪽Ͻ.ϽƎVOЯOᗺꞰƎИƎᗡ𑪽.TIꓨ GIT.ZDENEKBOROVEC.CZ/O
    O\ꟼᒐ.ƧUᒧꟼTϽƎИИOϽ.TIꓨ GIT.CONNECTPLUS.JP/O
    O\YИAꟼMOϽ.ꞰᗺƎ.AƎTIꓨ GITEA.EBK.COMPANY/O
    O\MOϽ.ƧꟼOVƎᗡUAꞰA.AƎTIꓨ GITEA.AKAUDEVOPS.COM/O
    O\ZYX.VƎᗡƎᒧᗺATЯOꟼ.AƎTIꓨ GITEA.PORTABLEDEV.XYZ/O
    O\MOϽ.ƎꓨAMAIV.AƎTIꓨ GITEA.VIAMAGE.COM/O
    O\TƎИ.OTYЯϽ.TIꓨ GIT.CRYTO.NET/O
    O\VƎᗡ.ƧꟼAMO.TIꓨ GIT.OMAPS.DEV/O
    O\MOϽ.ИƎMMƎH-ИAV.TIꓨ GIT.VAN-HEMMEN.COM/O
    O\UƎ.ИƎVƧƎИ.TIꓨ GIT.NESVEN.EU/O
    O\MOϽ.ᗡAƎЯᗡHTꟻIꟻ.AƎTIꓨ GITEA.FIFTHDREAD.COM/O
    






  • Well considering that the “UEFI Shim’s” role is to sit in between a Microsoft owned certificate signing chain, it is certainly part of it’s primary role.

    With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions.

    The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack – usually GRUB 2 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft.