Provide a verified signed Fedora repository - #46
Merged
Merged
Conversation
Record the project-owned provider decision, embedded RPM and repository signature boundaries, Fedora 44 target, rollback policy, public activation gate, and clean-guest evidence required by issue 36. Constraint: This is an intentional stack on PR 45 to reuse publication foundations Rejected: COPR | provider-built output requires separate provenance and promotion evidence Confidence: high Scope-risk: narrow Tested: Plan maps every development task and human activation boundary in issue 36
Authenticate the published Fedora 44 release RPM, sign the staged repository copy and repomd metadata with a dedicated OpenPGP identity, and publish through the reviewed SSH/POSIX revision protocol. Add protected refresh and rollback, a scoped DNF bootstrap, public activation gating, and clean-guest proof. The checked-in channel remains pending until the human production tasks supply and verify its public URL, signing key, origin and workflow environment. Constraint: Fedora 44 x86_64 is the only repository target in this slice Constraint: DNF does not natively enforce the project-signed metadata deadline Rejected: COPR | provider-built packages require separate output and promotion proof Confidence: high Scope-risk: moderate Directive: Preserve global immutable RPM/repodata URLs and publish repomd.xml last Directive: Keep gpgcheck, repo_gpgcheck and sslverify enabled in client configuration Tested: 13 generator, 20 publisher, 7 bootstrap, 6 HTTPS, 3 preflight, 34 proof and 4 channel cases Tested: Real DNF package/metadata signatures, interruption recovery and actual SSH transport Tested: Pending/verified browser fixtures, docs/build, workflow contracts, actionlint and ShellCheck Not-tested: Fresh Fedora KVM lifecycle and full workspace gates follow this reproducible commit Not-tested: Production origin/signing/environment/public activation remain human tasks
RPM 6 requires root ownership for its database lock even when the database is outside the system path. Run only the disposable fixture database operations through sudo while preserving the host RPM database and proof output. Constraint: Signature verification must not import fixture keys into the guest system RPM database Confidence: high Scope-risk: narrow Tested: Guest Bash syntax, ShellCheck, 34 proof-verifier regressions and whitespace Not-tested: Clean Fedora KVM lifecycle rerun follows this commit
Fedora's RPM policy rejects database locks below a user's home even for a root process. Use a unique root-owned /var/tmp database for the two offline signature checks and remove it immediately, without touching the system RPM DB. Constraint: Fedora RPM and SELinux policy controls usable database paths Confidence: high Scope-risk: narrow Directive: Keep fixture key imports isolated from the system RPM database Tested: Guest Bash syntax, ShellCheck, 34 proof mutations and whitespace Not-tested: Clean Fedora KVM lifecycle rerun follows this commit
RPM 6 rejects a manually pre-created database directory under the Fedora guest policy. Import the disposable public key directly through rpmkeys so RPM owns initialization, verify both repository packages, and delete the database. Constraint: RPM 6 owns initialization semantics for alternate database paths Confidence: high Scope-risk: narrow Directive: Never point fixture rpmkeys operations at the system RPM database Tested: Direct Fedora 44 rpmkeys alternate-db import; ShellCheck; 34 proof mutations Not-tested: Clean Fedora KVM lifecycle rerun follows this commit
Lifecycle-stage signature checks reuse the disposable RPM database. Keep it until the guest finishes and delete it from the exit trap together with the HTTPS fixture, including on failures. Constraint: Every install stage rechecks the exact repository RPM signature Confidence: high Scope-risk: narrow Directive: Cleanup must remove the alternate database on every guest exit Tested: Bash syntax, ShellCheck, 34 proof mutations and whitespace Not-tested: Clean Fedora KVM lifecycle rerun follows this commit
Map all nine development requirements to the signed package, publication, clean-guest, workflow and documentation evidence. Keep the five production operations explicitly human-owned before public activation. Constraint: The public release RPM is baseline proof; fixture signing and upgrade are not production material Confidence: high Scope-risk: narrow Tested: Final pnpm check and Fedora KVM lifecycle proof at e73c5bb Not-tested: Production origin and activation remain the issue's human tasks
This was referenced Sep 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fedora 44 users currently need a signed-checksum download flow plus a local RPM signature exception. This adds the complete development surface for a project-owned Fedora repository: exact public-release provenance, embedded RPM and repodata signing, guarded publication, scoped bootstrap, lifecycle proof, protected automation, and gated website integration.
This is an intentional stack on #35 / PR #45 and targets
feature/35-signed-apt. It reuses that PR’s SSH/POSIX publisher, protected-environment, public-activation, and guest-proof foundation. The Fedora work is isolated in its own generator, publisher, workflow, configuration, docs, and tests.packaging/repositories/fedora-channel.jsonremainspending. Existing Fedora installation remains visible until the human operational tasks provision and publicly verify the channel. A reviewed activation record switches only the Fedora panel tosudo dnf install loopwireand links one-time setup separately.resolves #36
Architecture and behavior
gpgcheck=1,repo_gpgcheck=1, andsslverify=1. The RPM and detachedrepomd.xmlsignature are independently pinned to the repository OpenPGP key.repomd.xml; real DNF rejects the brief mixed state and accepts it after recovery.packages-production, a repeat-safe Fedora setup/removal helper, exact HTTPS public verification, and a gated channel record.No audio/backend behavior or application dependencies changed. The checksum-pinned Fedora 44 tool image exercised RPM 6.0.2, createrepo_c 1.2.1, and DNF5 5.4.3.0.
Validation
pnpm checkpassed after the live guest fixes: all project verification, types, 295 workspace tests, 22 Rust tests, APT/Fedora repository suites, native packaging, production builds, and static-site checks.pnpm verify:rpm-repositorypassed: 13 generator, 20 publisher, 7 bootstrap, 6 public HTTPS, 3 workflow preflight, 34 raw proof-verifier, and 4 channel-gate cases.SHA256SUMS.sig,release-assets.json, the public release commit, and tarRELEASE. It installed/reinstalled through DNF, upgraded to the explicitly synthetic fixture, downgraded to the public baseline, removed it, and removed the repository. Independent proof binds repository origin, embedded signatures, source/distributed hashes, installed/usrbytes, providers, backend JSON, GUI linkage, and a real X11 window.Human operations remaining
The issue’s five Human operational tasks remain unchecked: confirm the project-owned provider/owner, provision HTTPS/SSH storage, establish signing/recovery ownership, configure
packages-production, and complete the first public publication plus clean-client verification. No production host, account, key, credential, environment value, DNS/TLS, repository, deployment, or website activation was changed.Loopwire’s verifier enforces its signed metadata deadline; DNF signature checks do not natively prevent replay of older correctly signed metadata. Operations therefore retain HTTPS/origin monitoring and weekly refresh. Power-loss and network filesystems were not exercised; production requires local POSIX flock/fsync/atomic-rename semantics.
Detailed requirement mapping and evidence