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-Managerbuilt in blazingly fast 🦀 rust called Soar- Repo Migration was Attempted but proved unsuccessful.
What? & Why?How does it all actually work?Request a new PKG/Tool📦 Frontend Package ManagersNotes On BuildingTypos, Grammatical Errors & Bad DocumentationAdditional Build Targets($ARCH-$OS)How To Contribute/DonateWhy NOT Host On GitHubWhy RESET ALL GIT CommitsWhere can I find the code for bin.ajam.dev?UPX Binaries ⏬🏜️ GUI PKGs 📀Caching & RebuildsCurrent Problems & SetbacksDMCA & CopyrightContact Me
Loonix () Telegram
➼https://t.me/official_loonix/63949Loonix (➼https://matrix.to/#/#loonix:matrix.orgABANDONED & NOT ACTIVE
| 🧰 Architecture 🧰 | 📦 Total Binaries 📦 | 🇨🇭 WorkFlows 🇨🇭 | 🧾Logs |
|---|---|---|---|
Android arm64-v8a |
161 |  |
BUILD.log |
Linux aarch64 // arm64 |
2439 |  |
BUILD.log |
Linux amd // x86_64 |
2509 |  |
BUILD.log |
Windows x64 // AMD64 |
157 |  |
BUILD.log |
- Raw
metadatacontaining info for sources etc is available as JSON on bin.ajam.dev/METADATA.json & also as YAML.- See: Parse METADATA.json to learn how to parse using
jq
- 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")
- 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"
- 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.ajam.dev/$(uname -m)/$BIN_OR_PATH_TO_BIN"
- Visit bin.ajam.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.
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 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/toolprovides 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
RAWBuild Logs is made available with the exception ofPersonal Access Tokenseverytime the Workflows are run.- Both
SHA256SUM&BLAKE3SUMare 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,
checksumsare meaningless as each build will produce different checksums. Your only option is totrust me broor:
- 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.
- 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
Devloperhas 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.