Packages and Dependency Trust

By the end of this lesson, you will be able to...

• explain which trust relationships and machine changes enter through one package transaction;

• investigate a proposed installation before approving it, using package metadata and a small trust ledger;

• distinguish package provenance and integrity from the separate questions of suitability, dependencies, and upgrade risk.

Idea in one sentence: Installing a package is a controlled import of code and policy into your machine, so the useful question is not only “does this package exist?” but “what evidence says what will change, and who am I trusting for that change?”

Core Insight

Nora wants a diagram viewer for a project. A colleague sends a short answer:

sudo pacman -S diagram-viewer

It looks small. The obvious model is also small: a package manager downloads one program, and the program appears in the application menu.

That model works for a toy program with no dependencies, no installation actions, and no later updates. A real transaction can choose a repository record, fetch package archives, check the configured signature policy, resolve dependencies and conflicts, run package scriptlets or local hooks, place files, and record package state. pacman explicitly supports dependency handling, install and uninstall scripts, and synchronizing a machine with remote repositories; its transaction options also make clear that bypassing dependency checks or scriptlets changes the safety model. Pacman manual

The stronger model is:

A package transaction is an evidence chain. It imports software, but also a source of updates, a dependency graph, installation behavior, and a record you must be able to inspect later.

This does not mean every installation needs a security ceremony. It means the amount of inspection should match the consequence. A font viewer used in an unimportant account needs less scrutiny than a package that receives network traffic, starts as a service, changes authentication, or becomes part of the machine you must rebuild.

What a Signature Answers—and What It Does Not

The word trusted easily becomes too vague. Separate three questions.

In plain English, a signature helps establish integrity and a link to the keys your package manager is configured to trust. In this scenario, it tells Nora that an archive matches a trusted signing path; it does not turn the archive into a proof of safety or usefulness. The technical name is package and database signature verification. Arch's SigLevel policy can require, allow, or skip signatures for packages and databases; choosing Never means no signature checking occurs. pacman.conf manual

Arch's signing documentation describes this as an OpenPGP web of trust: master keys certify developer and maintainer keys, which in turn sign official packages. That is a specific provenance mechanism, not a promise that maintainers cannot make mistakes or that a dependency contains no vulnerability. Arch package-signing documentation

The Package Trust Ledger

Before running Nora's command, make the intended change visible. On an Arch-based machine, this read-only query asks the synchronized repository database for information about the candidate:

pacman -Si diagram-viewer

The exact fields vary by package and distribution state. The following is a synthetic reading guide, not output from a real package:

Repository      : extra
Name            : diagram-viewer
Version         : 4.2.0-1
Depends On      : gtk4  libadwaita  librsvg
Optional Deps   : graphviz: render graph files
Conflicts With  : diagram-viewer-git
Download Size   : 18 MiB
Installed Size  : 61 MiB

Turn it into a short ledger instead of treating the fields as decorative metadata:

The ledger is a teaching model, not a feature built into pacman. Its job is to join evidence that otherwise sits in separate screens. It also makes a useful distinction: an explicit package is the item Nora chose, while a dependency is present because another package needs it. Pacman tracks those installation reasons and offers query filters for explicit packages and dependencies. Pacman manual

Investigation Path: From Candidate to Recorded State

Start with the package's role, not its name. “I need to open diagrams offline” is a testable purpose. “Someone said to install this” is not. If Nora only needs an SVG preview once, a temporary viewer or an existing application may be a better fit; this is a situated preference based on reducing long-term machine state, not a universal ban on packages.

Next, inspect the candidate. Read the repository, version, dependencies, optional dependencies, conflicts, download size, and installed size. If the package will expose a network listener, install a service, modify authentication, or add a kernel-facing component, raise the review bar: inspect its documentation, the exact configuration it introduces, and how it will be disabled or removed. Do not infer those effects from a package's friendly description.

Then inspect the transaction before accepting it. pacman can print transaction targets instead of applying them:

pacman -S --print diagram-viewer

This is a prediction aid, not a complete sandbox. It makes the selected target list visible, but it cannot prove that every installed program will behave well at runtime. Keep the dependency checks enabled: the manual says that the ordinary transaction verifies dependency fields and conflicts, while --nodeps bypasses those checks. A copied command containing --nodeps, --noscriptlet, or a signature-policy change deserves an explanation before it earns execution. Pacman manual

Only after the prediction matches the purpose should Nora run the actual transaction. The important intermediate states are visible:

intent
  -> repository metadata and signature policy select a candidate
  -> dependency and conflict checks form a transaction
  -> archives are verified and installed under the policy
  -> scriptlets/hooks may make declared installation-time changes
  -> local package database records the resulting machine state

“May” matters in the fourth line. Pacman packages support install and uninstall scripts, and --noscriptlet exists precisely because scriptlets are normally part of the operation. Local hooks are another configured part of a package-management environment. The correct response is neither panic nor blind acceptance: check whether the package's role makes such actions plausible, and make sure you know where the transaction record and relevant logs are on your machine. The next lesson will use that habit when a package-installed service behaves differently at boot.

Afterward, query the local database rather than relying on memory:

pacman -Qi diagram-viewer
pacman -Qet

The first command inspects the installed record. The second lists explicitly installed packages that are no longer required by another package, which is useful when reviewing what you intentionally own. Do not run removal commands merely because a package appears in a list: first connect it back to the ledger, current projects, and any configuration or data you intend to keep.

A Small Failure: “The Upgrade Broke My Viewer”

Two months later, diagram-viewer no longer opens a project file after a system upgrade. The tempting response is to blame the newest visible package and immediately install an older archive from a random link.

The better first move is to create a narrow evidence trail:

1. Record the symptom: which file fails, the exact error, and whether a different file works.
2. Query the installed package version and installation date with pacman -Qi diagram-viewer.
3. Check the transaction history and the package's documented changes or known issues.
4. Identify whether the failure is in the viewer, a new library dependency, the file itself, or a changed configuration.
5. Choose a recovery that preserves evidence: a supported update, a documented workaround, or—where the machine model supports it—a planned rollback with a verification step.

The package manager owns package files and package records. It does not automatically own Nora's project data, settings in every location, or the reason a particular version mattered. That is why the ledger includes recovery and why backups remain separate from package provenance.

So far, we have turned “install an app” into a traceable decision. This matters because the same reasoning scales to an editor, a compiler, a service, or a full workstation rebuild: distinguish the chosen purpose, the supply path, the dependency graph, the recorded result, and the recovery boundary.

Trade-offs, Boundaries, and Signals

Package managers save large amounts of work. They coordinate versions, dependencies, file ownership, and updates better than copying binaries into arbitrary directories. That benefit costs attention: each configured repository and installed dependency extends the code and update path your machine relies on.

This method helps when you need a machine that can be explained and repaired. It costs a few minutes of inspection and a small written record for consequential changes. It does not protect you from every compromised maintainer, undiscovered defect, malicious behavior after installation, or incompatibility created by a later update.

The signal that the boundary is near is not “a package has dependencies.” Almost every useful package does. The stronger signals are an unexplained repository, a disabled signature check, a request to bypass dependency checks, a transaction whose added packages do not match the stated purpose, a new privileged or network-facing service, or no recovery plan for a consequential upgrade.

Check Your Understanding

Check: A package archive verifies successfully under the configured signing policy. What have you learned, and what remains unknown?

Think first, then reveal.

Answer: You have evidence that the archive passed the configured integrity and provenance path. You still need to judge whether the repository and keys are appropriate for your machine, what dependencies and installation actions the transaction includes, and whether the software is suitable and supportable for the intended job.

Check: A colleague says, “Use --nodeps; it fixes the conflict.” What is the next discriminating question?

Think first, then reveal.

Answer: Ask which dependency or conflict is blocking the ordinary transaction and why it is safe to violate that constraint. Without that explanation, the flag removes evidence rather than repairing the underlying version or ownership problem.

Practice: Review a Proposed Tool

You need a command-line converter for files in a project directory. Write a five-line trust ledger before installing it:

1. purpose and the smallest capability required;
2. repository and signature-policy path you will accept;
3. explicit package, dependencies, and any optional pieces you will enable;
4. expected files, services, or configuration effects;
5. evidence and recovery action you will record after the transaction.

A good answer names a purpose more specific than “useful tool,” separates a verified source from a claim of absolute safety, and gives a recovery step that does not delete project data by accident. If the package would run as a service or handle secrets, it should name the extra inspection that raises the bar.

Resources

• [DOC] pacman(8) — Focus: read the operations, transaction options, query modes, scriptlets, and dependency checks as the contract behind an Arch package transaction.
• [DOC] pacman.conf(5) — Focus: inspect how SigLevel defines package and database signature requirements.
• [DOC] Pacman package signing — Focus: trace the OpenPGP trust path used for official Arch packages and its limits.

Key Takeaways

• A package transaction imports a source of updates, a dependency graph, installation behavior, and a recorded state—not only one executable.
• A successful signature check supports integrity and configured provenance; it does not prove safety, suitability, or future compatibility.
• A package trust ledger ties purpose, source, dependencies, expected effects, and recovery to one inspectable decision.
• Do not bypass signatures, dependency checks, or scriptlets merely to make a command succeed; first identify the constraint those controls expose.
• Your package manager can record package state, but it cannot replace backups, project-data ownership, or a recovery note.