Fedora change aims for 99% package reproducibility

Package ecosystems and security models

• Thread contrasts “curated” Linux distros with ecosystems like npm/PyPI/crates.io and VS Code extensions that accept whatever maintainers publish.
• Some argue mobile app stores are heavily vetted with significant automated and human review; others say vetting is mostly superficial, pointing to frequent malware and business‑driven review priorities.
• Windows/macOS are cited as examples where unsigned software triggers scary warnings and certificate revocation is the main control, analogous to Flatpak’s model on Linux.

Security vs convenience and distro philosophies

• Several comments lament that “frictionless” developer experience and language‑specific package managers encouraged sloppier security practices (typosquatting, unvetted dependencies).
• Others frame this as a long‑standing tradeoff: most systems started from convenience, and security has been bolted on later.
• There’s debate whether distros are too slow and conservative (lagging upstream, old versions) or justifiably cautious to avoid breakage.
• Some users circumvent distro packaging entirely with language ecosystems, curl | bash installers, or separate managers (nix, brew, etc.), which others find unmaintainable.

Nix, other distros, and reproducibility

• Nix is frequently raised as a “gold standard” for declarative, reproducible systems, but others note:
  • Its notion of reproducibility (pure derivations, time‑travel builds) differs from bit‑for‑bit RPM/DEB reproducibility.
  • It is complex, hard to adopt for non‑enthusiasts, and culturally contentious; some describe governance and community “culture war” issues.
  • Traditional distros already use sandboxed builds (e.g., mock), so Nix isn’t uniquely preventing unspecified inputs.
• Debian, Arch, and openSUSE are cited as having substantial reproducible‑build efforts; some argue Debian, not Nix, spearheaded the broader movement.

Fedora’s 99% goal and its value

• Some see “99% reproducible packages” as a marketing OKR and argue a principled goal would be “all packages, except where impossible (e.g., embedded signatures).”
• Others note the long tail of obscure packages and the practical difficulty of hitting 100%; focusing on widely used or installation‑media packages is suggested.
• Reproducible builds are framed as:
  • A defense against build‑infrastructure and supply‑chain attacks (though not against compromised upstream code like the xz incident).
  • A way to enable independent verification and multi‑build‑farm cross‑checking.
  • A quality signal that flushes out nondeterministic toolchain/build bugs (timestamps, unordered maps, racey parallel builds).

Sandboxing, PGO, and other tradeoffs

• Some argue sandboxing/desktop app isolation (Flatpak, Qubes‑style compartmentalization) would yield more concrete security benefits than reproducible builds; others say both are needed and draw attention to community vs corporate resource tradeoffs.
• Concerns raised that strict reproducibility may conflict with profile‑guided optimization or ASLR‑style entropy, though others respond that PGO can be made reproducible by treating profiles as versioned inputs.
• There’s a minor side debate on static vs dynamic linking and bundling: some users want more single‑binary or fully bundled apps (especially for Python), while others push back on code duplication and memory overhead.