Repository Trust, Updates, Pinning, and Patch Workflows

1. Repository trust begins with explicit scope

Package managers use cryptographic signatures and digests to detect unauthorized modification of repository metadata or package archives. This establishes a chain from configured trust material to downloaded artifacts. It does not prove that the publisher is competent, that upstream code is safe, that a signing key was never compromised, or that the package is appropriate for your environment.

flowchart TD
  K["Approved signing key and repository scope"] --> M["Authenticated metadata"]
  M --> C["Candidate versions and advisories"]
  C --> P["Policy: pins, excludes, holds, maintenance rules"]
  P --> S["Staging and transaction simulation"]
  S --> B["Backup, snapshot, and rollback readiness"]
  B --> R["Canary rollout"]
  R --> V["Health, security, and compatibility verification"]
  V --> F["Fleet rollout and evidence"]

Trust keys should be bound to the repository that requires them, not treated as universal authorization for every source. On APT systems, modern source definitions can use Signed-By. RPM repository definitions commonly specify gpgcheck, key locations, and sometimes repository-metadata checks.

2. Inspect repository and key configuration

Before adding a repository, verify its official documentation through an independent channel, understand the supported distributions and suites, record the key fingerprint, and define an owner and removal process. Avoid convenience instructions that disable signature checks or pipe remote scripts directly into a privileged shell.

printf '=== APT source trust declarations ===\n'
grep -RhsE '^[[:space:]]*(deb |Types:|URIs:|Suites:|Components:|Signed-By:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null || true

printf '\n=== repository keyrings ===\n'
find /etc/apt/keyrings /usr/share/keyrings -maxdepth 1 -type f \
  -printf '%p\n' 2>/dev/null | sort || true

printf '\n=== RPM repository trust declarations ===\n'
grep -RhsE '^\[|^name=|^enabled=|^gpgcheck=|^repo_gpgcheck=|^gpgkey=|^baseurl=|^metalink=|^mirrorlist=' \
  /etc/yum.repos.d 2>/dev/null || true

3. Pinning, exclusions, and holds alter candidate selection

APT pinning assigns priorities to versions or repository releases. DNF-family systems support exclusions and version-lock mechanisms whose exact commands depend on version and installed plugins. Holds prevent selected package upgrades. These controls are useful for compatibility incidents, staged migrations, and temporary rollback—but they create security and support debt.

printf '=== Debian-family policy ===\n'
if command -v apt-cache >/dev/null 2>&1; then
  apt-cache policy
  apt-mark showhold 2>/dev/null || true
  find /etc/apt/preferences /etc/apt/preferences.d -maxdepth 1 -type f \
    -print -exec sed -n '1,160p' {} \; 2>/dev/null || true
fi

printf '\n=== RPM-family exclusions and locks ===\n'
grep -RhsE '^[[:space:]]*(exclude|excludepkgs|includepkgs)=' \
  /etc/dnf /etc/yum.repos.d 2>/dev/null || true

if command -v dnf5 >/dev/null 2>&1; then
  dnf5 versionlock list 2>/dev/null || true
elif command -v dnf >/dev/null 2>&1; then
  dnf versionlock list 2>/dev/null || true
fi

Every lock or hold should have a reason, owner, ticket, affected hosts, risk statement, review date, and exit condition. Otherwise temporary exceptions become invisible permanent exposure.

4. A patch is an operational change, not only a package command

Not every security update requires the same speed, and not every reboot can wait. Build service tiers and emergency procedures before the incident.

5. Collect update evidence without applying changes

Read-only or simulation commands support planning. Exact advisory commands vary by distribution and installed plugins, so make automation capability-aware and preserve raw output.

if command -v apt-get >/dev/null 2>&1; then
  printf '=== APT upgrade simulation ===\n'
  apt-get --simulate dist-upgrade
  printf '\n=== APT holds ===\n'
  apt-mark showhold
  printf '\n=== upgradable packages ===\n'
  apt list --upgradable 2>/dev/null || true
elif command -v dnf5 >/dev/null 2>&1; then
  printf '=== DNF5 updates ===\n'
  dnf5 check-upgrade || status=$?
  printf 'status=%s\n' "${status:-0}"
  dnf5 advisory list --available 2>/dev/null || true
elif command -v dnf >/dev/null 2>&1; then
  printf '=== DNF updates ===\n'
  dnf check-update || status=$?
  printf 'status=%s\n' "${status:-0}"
  dnf updateinfo list available 2>/dev/null || true
fi

After patching, verify package versions, service health, listening sockets, logs, application checks, monitoring, and whether deleted-but-open libraries require process restarts. Kernel, libc, cryptographic libraries, and service runtimes often need explicit restart or reboot decisions.

6. Rollback is a prepared capability

Package downgrades are not universally safe. Configuration migrations, database schemas, generated state, kernel interfaces, and application data may move forward irreversibly. A reliable rollback plan can involve snapshots, image replacement, database restore, cached package sets, blue/green deployment, or redeployment from a known artifact.

7. Hands-on lab: build a patch-readiness report

This lab does not refresh metadata or apply updates. It records current source policy, holds or exclusions, installed kernel, reboot hints, and a transaction preview using existing local metadata.

lab="$HOME/devops-academy/linux/chapter09/lesson05"
mkdir -p "$lab"
report="$lab/patch-readiness.txt"

{
  printf 'captured_at=%s\n' "$(date --iso-8601=seconds)"
  printf '\n=== operating system and kernel ===\n'
  cat /etc/os-release
  uname -a

  if command -v apt-get >/dev/null 2>&1; then
    printf '\n=== APT sources and policy ===\n'
    grep -RhsE '^[[:space:]]*(deb |Types:|URIs:|Suites:|Components:|Signed-By:)' \
      /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null || true
    apt-mark showhold
    printf '\n=== APT transaction simulation ===\n'
    apt-get --simulate dist-upgrade
    printf '\n=== reboot hint ===\n'
    [ -e /var/run/reboot-required ] && cat /var/run/reboot-required || printf 'not present\n'
  elif command -v dnf5 >/dev/null 2>&1; then
    printf '\n=== DNF5 repositories ===\n'
    dnf5 repolist
    printf '\n=== available updates ===\n'
    dnf5 check-upgrade || true
    printf '\n=== version locks ===\n'
    dnf5 versionlock list 2>/dev/null || true
  elif command -v dnf >/dev/null 2>&1; then
    printf '\n=== DNF repositories ===\n'
    dnf repolist
    printf '\n=== available updates ===\n'
    dnf check-update || true
    printf '\n=== version locks ===\n'
    dnf versionlock list 2>/dev/null || true
  fi

  printf '\n=== recently installed kernel packages ===\n'
  if command -v dpkg-query >/dev/null 2>&1; then
    dpkg-query -W -f='${binary:Package}\t${Version}\n' 'linux-image*' 2>/dev/null | tail -20 || true
  elif command -v rpm >/dev/null 2>&1; then
    rpm -q kernel --last 2>/dev/null | head -20 || true
  fi
} > "$report"

less "$report"

8. Common mistakes

9. Knowledge check

10. Summary

Trusted package operations combine cryptographic verification, narrow repository scope, candidate policy, transaction review, tested recovery, and measured rollout. Pins, exclusions, and holds are temporary controls—not substitutes for patch governance. Effective patching proves what changed, why it changed, whether services remain healthy, and how residual risk is closed.

11. Further reading

• Debian apt-secure(8), apt_preferences(5), and Debian Reference package-policy guidance.
• DNF5 repository, advisory, and version-lock documentation for the installed release.
• RPM signature and verification documentation, plus the distribution's security advisory portal.