Security

It is NEVER a good idea to install random binaries from random sources.

Recommended Reading

Check these HackerNews Discussions

• https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ (HN: https://news.ycombinator.com/item?id=26203853)

• A cautionary tale from the decline of SourceForge

• Downloading PuTTY Safely Is Nearly Impossible (2014)

• Post-xz backdoor, how to know when to trust niche-distro binaries?

• A number of FAQs were also answered when Hysp (Frontend PKG Manager) was featured on HN: https://news.ycombinator.com/item?id=38457926

• The XZ Backdoor

• Reproducible Builds

The amount of work and the near impossibility to ensure that every source used, provide reproducibility, is infeasibly impractical. Even if it were practical, not every pkg/tool provides source code, so this is impractical.

---

Trust but Verify

• All the Build Scripts & workflows are completely open-source. You are free to audit & scrutinize everything.

• Check the Package Page & Look for Build Script : https://pkgs.pkgforge.dev/

• Using Soar

!# View Build Script
soar inspect "<PACKAGE>"

• Build Logs

• Check the Package Page & Look for Build Log : https://pkgs.pkgforge.dev/

• Using Soar

!# View Logs
soar log "<PACKAGE>"

If you get a 404 or it errors out, you can get the full logs here: https://meta.pkgforge.dev/bincache/logs/

• Checksums: SHA256SUM & BLAKE3SUM

Since, the builds aren't reproducible, it's unlikely you will end up with the same checksums if you rebuild/rerun the Build Script

• Signed Artifacts

You can use minisign to verify any of our artifacts using the Public Key: https://raw.githubusercontent.com/pkgforge/bincache/refs/heads/main/keys/minisign.pub

• Build Attestations & Provenance

All our CI workflows produce attestations for all of the artifacts: https://github.com/pkgforge/bincache/attestations

• If it still doesn't inspire confidence, there's a Docker Image you can Configure to Run & Reproduce any Binary/Build Script on your own Secure System.

• Devscripts: https://github.com/pkgforge/devscripts

• Dockerfiles: https://github.com/pkgforge/devscripts/tree/main/Github/Runners

---

Don't Trust Us

1. Repos that already publish pre-compiled binaries/packages, . You can compare checksums.

• For Binaries, Debug Symbols, Comments are stripped, this will change the checksum

• For Packages, Icons, Desktops (& even repacking) are edited/fixed & patched, this will change the checksum

1. Fork our repos, read & audit our code, setup all the infrastructure, & run all the scripts & build on your own servers

---

Spooky Things

Follow this guide to analyze a malicious binary/package: https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis

1. First, it's important to verify that the alert is NOT a False Positive and truly confirm that indeed the Binary is Malicious

2. Second, check the affected Binary's Build Script, the latest BUILD.log & finally CHECKSUMS as described in above sections.

3. Third, if you find everything is as it should be, create an Issue & attach Verifiable and Reproducible Proof.

It's important to NOTE that WE DO NOT WRITE/OWN the binaries we compile and CAN NOT BE HELD RESPONSIBLE if the Developer has DELIBERATELY made it Malicious. If that's the case, it's best to Notify Us (Create an Issue OR Contact Us) & also Report To Github the Original Repo like here: https://github.com/orgs/community/discussions/63603

1. All the Build Servers follow Standard Security Hardening to mitigate Supply Chain Attacks, so a single Malicious Binary is more probable than ALL the binaries being infected.

2. Once again, to reiterate, the source code of the packages or tools compiled here is not controlled in any way.

It cannot be guaranteed that the upstream source is entirely safe or legitimate. It's upto you to exercise basic common sense and vigilance when using these binaries/packages.