Sentinel v0.8.0

Build-pipeline maintenance: smaller binaries, faster CI

A maintenance release focused entirely on the build pipeline. No
behaviour or config changes for end users — existing
/etc/security/sentinel.conf and /etc/pam.d/polkit-1 keep working
unchanged.

What changed

Fat LTO across the workspace

[profile.release] switched from lto = "thin" to "fat". Measured
against the v0.7.0 baseline:

binary	v0.7.0	v0.8.0	delta
pam_sentinel.so	756 KB	720 KB	−4.8%
sentinel-polkit-agent	3.13 MB	2.94 MB	−6.1%
sentinel-helper	13.99 MB	12.68 MB	−9.3%
total (workspace)	17.84 MB	16.31 MB	−8.6%

Adds roughly 5 minutes to release-build wall time (consumed by CI on
tag push). codegen-units stays at 1 so fat LTO has the full graph
to work with.

AUR baseline: x86-64-v3

The Arch package now compiles with -C target-cpu=x86-64-v3
(Haswell / Zen 1+ — AVX2, BMI1/2, FMA, F16C). Aligns with how
ALHP / CachyOS distribute microarch-tuned binaries. Size impact is
roughly neutral (the helper grows ~1.4% from wider SIMD lanes; the
smaller bins shrink ~1%); the lever here is potential runtime perf
on AVX2 paths in fluent-bundle / clap / zbus parsing.

The portable .deb / .rpm / source-tarball builds are unchanged —
they still target the x86-64 baseline. Pre-Haswell users (~2013
CPUs) would SIGILL on the AUR package; in 2026 that's a vanishing
slice of users running a modern Wayland compositor. If you're
affected, install from .deb / .rpm or build from source.

CI: mold linker

Both ci.yml and release.yml install mold and use it via
RUSTFLAGS=-C link-arg=-fuse-ld=mold at the workflow level. Doesn't
affect the produced binary beyond build-id; trims wall-clock off the
link step. First CI run after this lands will redo the
Swatinem/rust-cache@v2 cache (RUSTFLAGS change invalidates cache
keys); subsequent runs cache normally.

Honest tokio cleanup

crates/sentinel-polkit-agent/Cargo.toml no longer declares the
rt-multi-thread tokio feature: main.rs builds the runtime via
Builder::new_current_thread(), so the multi-thread scheduler was
dead code in the agent's own dependency graph.

Workspace feature unification (libcosmic via the helper still pulls
in rt-multi-thread) means the shipped binary doesn't shrink today
in --workspace builds — but the agent's manifest now expresses
exactly what the binary needs. Becomes a free size win the day
libcosmic's tokio surface changes.

Verify

# Compare binary sizes against v0.7.0:
gh release download v0.7.0 -p '*x86_64-linux.tar.gz' -D /tmp/v07
gh release download v0.8.0 -p '*x86_64-linux.tar.gz' -D /tmp/v08
ls -l /tmp/v0{7,8}/sentinel-*/usr/lib/sentinel-*

# Verify a v0.8.0 attestation:
gh attestation verify sentinel_0.8.0-1_amd64.deb \
    --repo atayozcan/sentinel

Skipped from the optimisation sweep (with rationale)

• PGO / BOLT: sentinel-helper runs for ~10 seconds per
  invocation; instrumentation overhead exceeds steady-state gains
  for that lifetime.
• opt-level = "z"/"s" on the helper: would trade startup
  latency for size; the helper is an interactive auth dialog where
  startup matters more than disk footprint.
• sccache in CI: pairing it with Swatinem/rust-cache@v2
  doubles the caching layer for marginal gain, and cargo install sccache adds ~3 minutes per cold CI run, eating the speedup.
  sccache is recommended as a local-dev tool instead.
• x86-64-v4 (AVX-512): the project does no SIMD-heavy work,
  and the helper's bottleneck is GPU-side rendering via wgpu — v4
  would shrink hardware compatibility (Zen 3 has no AVX-512)
  without measurable perf benefit.

Docs

https://atayozcan.github.io/sentinel/