Only looked at the Cargo.toml files.

• (pet peeve) Considering there is (presumably) no compatibility concerns, why not use an efficient binary format instead of JSON?
• Not checking in Cargo.lock files, and using = dependency versions for Phoenix_Desktop, is a bit odd!

People stopped taking Brian seriously when he helped create Go. That was pre-Rust.

Even the “talking points” here seem to be re-used from “Go vs. X” ones. Also, his experience speaks of someone who only tried Rust pre-v1.0.

Anyone who actually knows Rust, anti- or pro-, knows that what he said (partially in jest) is factually wrong.

Feel free to prove otherwise, especially the part about the performance of Rust programs. Don’t be surprised if he simply didn’t pass --release to cargo build, a common pitfall for someone in the “hello world” stage of trying Rust.

And this is why appeal to authority was never more fallacious, considering we live in a world where Dunning-Kruger is a universal reality.

What’s wrong with it

• It’s a random crate no one uses.
• You’re not even really “using” it. You are just importing a re-export of reqwest, which is what I expected you to immediately notice after I brought it into attention. You can obviously just remove it and use reqwest directly.
• Still, trusting a re-export is not a trivial matter. The random author of the no-name crate could replace the original reqwest with something malicious, or bad in some other way, in a v0.1.1 release. That (theoretical) release will be picked up after a cargo update call, or when Cargo.lock is not checked, which is the case by default with libraries.

How did you find that crate?
Why do you think you need it?

Can you explain the rust-fetch dependency?

Why Peter Thiel though?

It was a (failed) joke about your user-name.

How much “vibe coding” is involved?

And are you Peter Thiel by any chance 😉

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.

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

Can Flatpak itself be sunset with some bullying?