Library, framework, package, binary, container image, source code, firmware โ open source comes in many forms. Each type is different, used differently, and verified differently. This guide explains them ALL โ including how SHA checksums protect you from tampered files.
In software, an "artifact" is any file or package that a project creates and distributes. When a developer writes code and shares it, the things they publish โ the compiled program, the library file, the Docker image, the source code archive โ are all artifacts.
Different artifacts serve different purposes, are installed differently, and need to be verified differently. Understanding the types is essential because: you wouldn't install a library the same way you install an operating system, and you wouldn't verify a container image the same way you verify source code.
Kitchen Analogy: Think of a restaurant kitchen. The recipe (source code) tells you HOW to cook. The ingredients (libraries/dependencies) are the raw materials. The prepared meal (binary/package) is the ready-to-eat result. The meal kit (container image) is everything pre-measured in a box โ just heat and serve. The cookbook (documentation) explains all the recipes. Different artifacts, different uses.
Source code is the original text written by developers in a programming language (Python, C, Java, JavaScript, etc.). It's what you see on GitHub. It's human-readable โ you can open it in a text editor and understand what it does. ALL other artifacts are created FROM source code.
How you get it: Clone a Git repository, download a .tar.gz or .zip archive from GitHub/GitLab, or extract it from a source package.
Analogy: The recipe written on paper. You can read it, modify it, and cook from it โ but you need a kitchen (compiler/interpreter) to turn it into a meal.
Source code is the MOST transparent artifact โ you can read every line and verify there's nothing malicious. This is why open source is more trustworthy: anyone can audit the source code. Always prefer reviewing source when security is critical.
A library is a collection of pre-written functions that developers use inside their own programs. You don't run a library directly โ you import it into your code and call its functions. Libraries save developers from reinventing the wheel.
For example, instead of writing your own code to parse JSON, you use a JSON library. Instead of writing your own encryption, you use OpenSSL (a library). Libraries are the LEGO bricks of software.
Analogy: LEGO bricks. You don't play with a single brick โ you combine many bricks to build something. Each library is a specialized brick (one for colors, one for shapes, one for sounds).
Linux: .so (shared object), .a (static archive) โ e.g., libssl.so
Windows: .dll (dynamic link library) โ e.g., openssl.dll
macOS: .dylib (dynamic library)
Python: .py files or compiled .whl (wheel)
Java: .jar (Java archive)
A framework is like a library, but with a key difference: a library is called BY your code; a framework CALLS your code. The framework provides the structure (routing, database, authentication) and you fill in the specific parts (your business logic, your pages, your data).
Analogy: A house frame (walls, roof, plumbing already built). You don't build the foundation โ you fill in the furniture, paint, and decorations. The framework decides WHERE the doors go; you decide what color they are.
Library: "You call us." Your code decides when to use the library. Framework: "Don't call us, we'll call you." The framework runs the show and calls YOUR code at the right moments. This is called the "Inversion of Control" โ the framework is in charge, not you.
A package is a bundled, installable unit โ it contains the code (source or compiled), metadata (name, version, author, license), and a list of dependencies (other packages it needs). Package managers install, update, and remove packages automatically.
Analogy: A mail-order package โ labeled with sender, contents list, and delivery instructions. The package manager is the postal service that delivers and installs it for you.
.deb โ Debian/Ubuntu/Mint (installed by apt/dpkg)
.rpm โ Fedora/RHEL/SUSE (installed by dnf/yum/zypper)
.whl โ Python wheel (installed by pip)
.gem โ Ruby (installed by gem)
.jar / .war โ Java (installed by Maven/Gradle)
.snap โ Universal Linux (installed by snap)
.flatpak โ Universal Linux (installed by flatpak)
.AppImage โ Portable Linux app (just download and run!)
PyPI (pypi.org) โ Python ยท npm (npmjs.com) โ JavaScript ยท crates.io โ Rust ยท Maven Central โ Java ยท RubyGems โ Ruby ยท NuGet โ .NET ยท APT repos โ Debian/Ubuntu ยท Flathub โ Flatpak ยท Snap Store โ Snap. Each language has its own registry.
A binary is compiled machine code โ the CPU runs it directly. When source code (C, C++, Rust, Go) is compiled, the result is a binary. You can't read it (it's 1s and 0s) โ but it's FAST because the CPU doesn't need to translate anything.
Important distinction: Binaries are platform-specific! A Linux binary won't run on Windows, and an ARM binary won't run on x86. That's why projects publish binaries for EACH platform: linux-amd64, linux-arm64, windows-x64, macos-arm64, etc.
Analogy: The cooked meal โ ready to eat immediately. You can't see the recipe by looking at it (decompilation is hard and imperfect), and it only fits certain plates (platforms).
Binaries are OPAQUE โ you can't easily verify what's inside. A binary COULD contain malware you can't see. This is why SHA checksums and GPG signatures are critical for binaries. ALWAYS verify the hash of downloaded binaries before running them. More on this below.
A container image is a complete, self-contained package that includes: the application binary, all its libraries, configuration files, and even a minimal OS layer. It runs identically on ANY machine with Docker/Podman installed โ no "works on my machine" problem.
Analogy: A meal kit box โ contains the meal, plates, utensils, and even a mini-oven. You don't need anything except a table (Docker engine). Everything is pre-packaged to work perfectly together.
Container images have digests (SHA256 hashes of each layer). Use docker pull nginx@sha256:abc123... to pull by exact digest โ guaranteeing you get the EXACT image, not a tampered version. Also check for Cosign signatures (modern image signing).
Firmware is software that lives inside hardware devices โ your router, your Arduino, your printer, your TV, your car's computer, your BIOS/UEFI. It's usually a binary image that gets "flashed" (written) to the device's memory chip. Open-source firmware gives you control over your hardware.
Flashing wrong firmware can "brick" your device (make it completely non-functional). ALWAYS verify the SHA checksum of firmware files before flashing. ALWAYS follow the exact instructions for your specific hardware model.
An ISO image is a complete disk image โ usually a full operating system installer. You download it, write it to a USB drive (using Etcher), and boot from it to install an OS. Named after the ISO 9660 file system standard for CD-ROMs.
OS ISOs are the #1 target for supply chain attacks โ if an attacker modifies an ISO, they can insert a backdoor into your entire operating system. EVERY Linux distro publishes SHA256 checksums alongside their ISOs. ALWAYS verify before installing.
Documentation is often overlooked but is a crucial artifact: READMEs, API references, tutorials, man pages, translation files, design files (icons, logos), and configuration examples. Good documentation is what separates usable software from abandoned experiments.
A new category of artifact: AI model weights (the trained parameters of a neural network, often GBโTB in size) and datasets (the data used to train them). These are distributed via Hugging Face, Ollama, and model registries.
The most important security skill you'll learn today.
SHA is a mathematical function that takes ANY file โ no matter how big โ and produces a fixed-length "fingerprint" (called a hash or checksum). This fingerprint has incredible properties:
โข Unique: Even changing ONE bit in the file produces a COMPLETELY different hash
โข Fixed size: Whether the file is 1 KB or 100 GB, the hash is always the same length
โข One-way: You can't reverse-engineer the file from the hash
โข Deterministic: The same file ALWAYS produces the same hash
SHA256:
SHA256:
SHA256:
See? Changing ONE character produces a completely different hash. If someone modifies a single byte in a 4 GB ISO file, the entire SHA256 hash changes. This is how you detect tampering.
Use SHA-256 for everything. It's the industry standard, supported everywhere, and has no known weaknesses. Only use SHA-512 or SHA-3 if you have specific high-security requirements. NEVER use MD5 or SHA-1 for security purposes.
When you download a Linux ISO, firmware, or any important file โ here's how to verify it hasn't been tampered with:
SHA tells you the file hasn't changed. But what if an attacker hacked the website and replaced BOTH the file AND the checksum? Then the SHA would match a tampered file!
GPG signatures solve this: the developer digitally signs the checksum file with their private key. You verify the signature with their public key. Even if the website is hacked, the attacker can't forge the developer's signature without their private key.
Developer writes code โ compiles binary โ calculates SHA256 hash โ signs the hash with GPG key โ publishes file + hash + signature. You download all three โ verify GPG signature (proves authenticity) โ verify SHA256 (proves integrity). If both pass, you can trust the file.
Git commit hashes (SHA-1 โ moving to SHA-256), signed tags (git tag -v), GitHub verified badges
Repos are GPG-signed. apt/dnf verify signatures automatically. apt-key manages trusted keys
PyPI has hash pinning (pip install pkg==1.0 --hash sha256:abc...). npm uses SHA-512 in lockfiles
SHA256 checksum files + GPG signatures. Always verify BOTH before running
Image digests (sha256:abc...), Cosign signatures, Docker Content Trust (Notary)
SHA256 checksum files + GPG signatures. CRITICAL to verify โ the #1 supply chain target
SHA256 checksums from manufacturer. Some use Secure Boot (signed firmware only)
SHA256 on Hugging Face model cards. GGUF files have embedded checksums. Ollama verifies automatically
Tabayyanoo โ Verify! The Quran commands us to verify information before acting on it. SHA checksums are the digital form of this command. When you download a file from the internet, you don't blindly trust it โ you VERIFY its integrity. This is Tabayyanoo in the digital age.
Now you understand every type of open-source artifact โ from raw source code to compiled binaries, from Docker images to AI models. And you know how to VERIFY them with SHA checksums and GPG signatures. Never blindly trust a downloaded file again. Tabayyanoo โ verify!
ยซููุฃููููููุง ูููู ุงููุญูุฏููุฏูยป
Every artifact is a piece of softened iron โ powerful and useful. But just as a blacksmith tests the quality of iron before forging, you must verify every artifact before trusting it. โจ