Problem
A verified RPM downloaded by the desktop app can fail when the default GUI local-package handler submits the upgrade through its long-running package transaction service. The same package is accepted by a fresh native package transaction, so users can be left with an opaque Id is out of bitmap range error despite a valid update.
Scope
- Prefer a fresh system-authorized PackageKit transaction for verified RPM and DEB updates.
- Keep the existing release-channel, architecture, size, and SHA-256 verification gates.
- Pass a normalized absolute package path as a distinct process argument without shell parsing.
- Retain the desktop file-handler fallback where the supported native package service is unavailable.
Acceptance criteria
- A verified local Linux package is handed to PackageKit through the operating system authorization flow.
- The package service runs noninteractively only after the user selected Install and approved system authentication.
- The handoff does not opt into package downgrades.
- No
sudo, direct privileged package-manager launch, shell command construction, signature bypass, or unverified package path is introduced.
- Command selection and argument boundaries have deterministic desktop tests.
- Existing Windows and unsupported-Linux installer handoffs remain unchanged.
Parent
Problem
A verified RPM downloaded by the desktop app can fail when the default GUI local-package handler submits the upgrade through its long-running package transaction service. The same package is accepted by a fresh native package transaction, so users can be left with an opaque
Id is out of bitmap rangeerror despite a valid update.Scope
Acceptance criteria
sudo, direct privileged package-manager launch, shell command construction, signature bypass, or unverified package path is introduced.Parent