• 0 Posts
  • 10 Comments
Joined 3 months ago
Cake day: June 6th, 2025
  • ISO@lemmy.ziptoLinux@programming.dev•Arch Linux remains under attack as DDoS enters week 2 - here's a workaround
    10·
    4 days ago

    reflector uses https://archlinux.org/mirrors/status/json/ to get mirror status info, and caches it under ~/.cache/Reflector/. So as long as that end-point works, reflector should work.

    I just grabbed a copy and pasted it at http://0x0.st/Ki3Y.json.

    Anyone can grab that JSON data and use file:// URLs so they are never out. e.g.

    curl -L https://archlinux.org/mirrors/status/json/ > /tmp/mirror_status.json
# or if down, use pasted json
curl -L http://0x0.st/Ki3Y.json > /tmp/mirror_status.json
# and then
reflector --url file:///tmp/mirror_status.json ...

    But, as you noted, this has been mostly a nothing-burger from a user perspective anyway. Other than the homepage being unavailable on occasion, everything else has been mostly available just fine as you can see from https://status.archlinux.org/.

    I didn’t notice https://gitlab.archlinux.org/ going down either.

    BTW, and as a general rule of thumb, NEVER take specific technical advice from these editors. They don’t actually know much, and this is me trying to be nice.

    Take for example:

    For AUR disruptions, it’s a bit of a pain if you’re not a regular git user, but you cloned packages directly from the GitHub Arch Linux mirror. To do this, use the command:

    See that link ;) At least he got the command below it correctly, somehow.

  • ISO@lemmy.ziptoLinux@lemmy.ml•Any way to change h264 flatpak update source?
    34·
    13 days ago

    You are in a thread where a user is having a problem because of the push for flatpaks, and because of some distros like Fedora crippling their packages and providing objectively worse alternatives on purpose (because they don’t want to risk RH IBM getting sued). If the user was using some sane community distro like Arch, the user would have never come to realize that such unnecessary issues even exist.

    As for flatpak hate specifically, see my ramblings here.

  • ISO@lemmy.ziptoOpensource@programming.dev•Linux dev quits after "personal attacks" from user over Kapitano antivirus tool
    2·
    14 days ago

    This is such a excellent unexpected original comeback, I will give you a chance to do another one.

    How to extract the content of a flatpak

    Which is something you presumably want to do because you don’t want to use flatpak/ostree.

    The first step of course, is to install ostree. 🤨

    Then, via this very official method:

    ostree init --repo=repo --mode=bare-user
ostree static-delta apply-offline --repo=repo some.flatpak
ostree checkout --repo=repo -U $(basename $(echo repo/objects/*/*.commit | cut -d/ -f3- --output-delimiter= ) .commit) outdir

    This official solution looks very reliable.

    The impenetrable building blocks

    Searching vulnerability databases will obviously prove futile. Like the below sample entries (search limited to CVSS>=9.0 and Age<90d)

    [CVE-2025-7458] Critical - SQLite - Integer Overflow
  ↳ Priority: MEDIUM | No exploits | Vuln Age: 15d (RECENT)
  ↳ CVSS: 9.1 | EPSS: 0.0003 | KEV: ✘
  ↳ Exposure: 12 | Vendors: sqlite | Products: sqlite
  ↳ Patch: ✔ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘
─────────────────────────────────────────────────────────────────────────
  
[CVE-2025-6965] Critical - SQLite - Buffer Overflow
  ↳ Priority: HIGH | EXPLOITS AVAILABLE | Vuln Age: 29d (RECENT)
  ↳ CVSS: 9.8 | EPSS: 0.0005 | KEV: ✘
  ↳ Exposure: 13 | Vendors: sqlite | Products: sqlite
  ↳ Patch: ✔ | POCs: 1 | Nuclei Template: ✘ | HackerOne: ✘
─────────────────────────────────────────────────────────────────────────

  
[CVE-2025-49796] Critical - libxml2 - Denial of Service
  ↳ Priority: MEDIUM | No exploits | Vuln Age: 57d
  ↳ CVSS: 9.1 | EPSS: 0.0013 | KEV: ✘
  ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘
─────────────────────────────────────────────────────────────────────────

[CVE-2025-49794] Critical - libxml2 - Use After Free
  ↳ Priority: MEDIUM | No exploits | Vuln Age: 57d
  ↳ CVSS: 9.1 | EPSS: 0.0013 | KEV: ✘
  ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘
─────────────────────────────────────────────────────────────────────────

[CVE-2025-4517] Critical - Python tarfile - Path Traversal
  ↳ Priority: MEDIUM | No exploits | Vuln Age: 71d
  ↳ CVSS: 9.4 | EPSS: 0.0015 | KEV: ✘
  ↳ Patch: ✘ | POCs: ✘ | Nuclei Template: ✘ | HackerOne: ✘

─────────────────────────────────────────────────────────────────────────

    libxml2 and sqlite are in the dependency tree of ostree itself of course. But really, nothing to see here.

  • ISO@lemmy.ziptoOpensource@programming.dev•Linux dev quits after "personal attacks" from user over Kapitano antivirus tool
    25·
    14 days ago

    Just the common “hate” talking points.

    Because it’s more inconvenience than help for users who are average or above, and have no interest in using that technology.

    If app developers start distributing binaries as flatpaks exclusively (examples of this already exist), then just extracting those binary packages alone is a chore (involving obscure(ish) steps starting with creating an empty ostree). It’s the kind of knowledge that is so useless you immediately erase it from your memory, which is what I did.

    Also, one look at the dependency tree of flatpak, or even just ostree, and you quickly realize how much of a joke the “security” claims are with all that attack surface (think the xz in systemd drama and multiply it by a 100).