Statically Compiled Binaries

raison d'être

• ℹ️ As of 2024-11-05, this repo is a part of PkgForge.
• PkgForge was created to fix the disparate status of Linux Package Formats.
• Other than Static Binaries, we now also provide prebuilts & build recipes for formats like AppBundle, AppImage, FlatImage, GameImage, RunImage & More
  
• We also have our own Package-Manager built in blazingly fast 🦀 rust called Soar
• Repo Migration was Attempted but proved unsuccessful.

---

Contents

• 📖 Docs & FAQs 📖

• What? & Why?
• How does it all actually work?
• Request a new PKG/Tool
• 📦 Frontend Package Managers
• Notes On Building
• Typos, Grammatical Errors & Bad Documentation
• Additional Build Targets($ARCH-$OS)
• How To Contribute/Donate
• Why NOT Host On GitHub
• Why RESET ALL GIT Commits
• Where can I find the code for bin.pkgforge.dev?
• UPX Binaries ⏬
• 🏜️ GUI PKGs 📀
• Caching & Rebuilds
• Current Problems & Setbacks
• DMCA & Copyright
• Contact Me

• 🔽 Download 🔽

• 📦Linux x86_64📦
• 📦Linux aarch64📦
• 📦Windows_NT AMD64📦
• 📦Android arm64-v8a📦

• 📦 Status 🔖
• 🚧 Security ⚙️
• Community 💬

• Loonix () Telegram ➼ https://t.me/official_loonix/63949
• Loonix () Matrix ➼ https://matrix.to/#/#loonix:matrix.org ABANDONED & NOT ACTIVE

---

• 📦 Status 🔖

🧰 Architecture 🧰	📦 Total Binaries 📦	🇨🇭 WorkFlows 🇨🇭	🧾Logs
Android arm64-v8a	161		BUILD.log
Linux aarch64 // arm64	2441		BUILD.log
Linux amd // x86_64	2511		BUILD.log
Windows x64 // AMD64	157		BUILD.log

• Raw metadata containing info for sources etc is available as JSON on bin.pkgforge.dev/METADATA.json & also as YAML.
• See: Parse METADATA.json to learn how to parse using jq

---

🔽 Download 🔽

• Package Managers RECOMMENDED

• Soar

• If you want a pkg-manager in Rust 🦀, Choose this. Details ➣ https://github.com/pkgforge/soar

bash <(curl -qfsSL "https://raw.githubusercontent.com/pkgforge/soar/refs/heads/main/install.sh")

• Dbin

• If you want a pkg-manager in Go, Choose this. Details ➣ https://github.com/xplshn/dbin

wget -qO- "https://raw.githubusercontent.com/xplshn/dbin/master/stubdl" | sh -s -- --install "${HOME}/.local/bin/dbin"

---

• CLI

• It's also possible to use "$(uname -m)"

SEE: https://github.com/Azathothas/Toolpacks/blob/main/Docs/METADATA.md#url-redirects

!# curl needs the `-L, --location` flag to Follow redirects
!# wget works without any flags

!# Example
curl -qfsSLO "https://bin.pkgforge.dev/$(uname -m)/$BIN_OR_PATH_TO_BIN"

---

• GUI NOT RECOMMENDED

• Visit bin.pkgforge.dev

Note: If you notice slow loading, it is because it is not a real website.
It is a r2 bucket, and loads all objects upon each request.

---

• 🚧 Security ⚙️

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

• Check these HackerNews Discussions

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

• Reasons to Trust this Repo

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

# Everything is automated via Github Actions & Build Scripts
WorkFlows --> https://github.com/Azathothas/Toolpacks/tree/main/.github/workflows
Build Scripts --> https://github.com/Azathothas/Toolpacks/tree/main/.github/scripts

# Build LOGS (BUILD.log] are generated at Build Time & Pushed both to Github & R2

• Complete RAW Build Logs is made available with the exception of Personal Access Tokens everytime the Workflows are run.
• Both SHA256SUM & BLAKE3SUM are automatically generated right after build script finishes.
• 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.

• Dockerfiles: https://github.com/Azathothas/Toolpacks/tree/main/.github/runners
• Note: Checksums may not be reproduced reliably (See Reason Below)

• Reasons NOT to trust this Repo

• Repos that already publish pre-compiled static binaries, nothing is changed (Other than stripping Debug Symbols & Comments). You can compare checksums.
• However, for repos that don't publish releases or at least not statically linked binaries, there is no way for you to end up with the same binary even when you use the same build scripts. In this case, checksums are meaningless as each build will produce different checksums. Your only option is to trust me bro or:

• Fork this repo : https://github.com/Azathothas/Toolpacks/fork
• Read & Verify everything : Scripts & Workflows
• Read the DOCS & Setup your own Infrastructure.

• You may contact me at: https://ajam.dev/contact if you need help setting up your own.

• Backdoors, Malwares & Viruses

• First, it's important to verify that the alert is NOT a False Positive and truly confirm that indeed the Binary is Malicious
• Second, check the affected Binary's Build Script, the latest BUILD.log & finally CHECKSUMS
• Third, if you find everything is as it should be, create an Issue & attach Verifiable and Reproducible Proof.
• It's important to NOTE that I DO NOT WRITE/OWN the binaries I compile and CAN NOT BE HELD RESPONSIBLE if the Devloper has DELIBERATELY made it Malicious. If that's the case, it's best to Notify Me (Create an Issue OR Contact Me) & also Report To Github the Original Repo like here: https://github.com/orgs/community/discussions/63603
• All of the Build Servers follow Standard Security Hardening to mitigate Supply Chain Attacks, so a single Malicious Binary is more probable than ALL of the binaries being Infected.
• Once again to reiterate, the source code of the packages or tools compiled here is not controlled in anyway.

• The process involves fetching the code and following standard build procedures which are well documented and the scripts available to audit.
• In the case of binaries, whose upstream developers do not provide source code (ngrok, Twingate, etc.) OR themselves provide a pre-compiled static binary (Github Releases), the binary is simply fetched AS-IS (Other than stripping Debug Symbols).
• 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.

---