Repository navigation
fix: make installs atomic with their metadata; safer asset matching and launch paths - #32
Merged
Merged
Conversation
…nd launch paths Three audit findings on the install pipeline: - Cancelling a download during verify/extract detached the blocking install task (it runs to completion) while dropping the completion message, so the version/asset records - previously written in the UI handler - were never saved: an installed binary with no version file is silently excluded from every future update check, and a filePattern install became an orphaned binary the app no longer saw as installed. The records are now written inside the blocking step, atomically with the promotion, by download_release_asset itself (the parameters moved into an AssetInstall struct while touching the signature). - find_asset_by_pattern now prefers an exact name match (so 'app-macos' resolves even though 'app-macos-x86' contains it) and ignores non-installable siblings (.sig/.sha256/.yml/...): the day a repo signs its releases the way Colony itself does, every substring pattern would otherwise turn ambiguous and break installs. - installed_app_path now applies the same traversal guard as the install path to the manifest-supplied binary/file name: a hostile manifest could otherwise point the Launch button at an arbitrary executable outside the app's install dir. Two new tests cover the exact-match and signature-sibling cases.
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.
Contexte (audit 2026-07-20, vague B - lot 2)
.colony_version/.colony_asset- écrits jusqu'ici dans le handler UI - ne l'étaient jamais. Résultat : app exclue des checks d'update pour toujours, ou binaire orphelin invisible. Les enregistrements sont maintenant écrits dans l'étape bloquante, atomiquement avec la promotion, pardownload_release_assetlui-même (paramètres regroupés dans une structAssetInstallau passage).find_asset_by_pattern: match exact d'abord + filtrage des jumeaux non-installables (.sig,.sha256,.yml...) - le jour où une app de l'écosystème signe ses releases comme Colony le fait, chaque pattern substring devenait ambigu et cassait les installs. Le match exact règle aussi le recouvrementapp-macos/app-macos-x86.installed_app_pathapplique le même garde anti-traversal que l'install au nom venant du manifest - un manifest hostile pouvait pointer le bouton Launch vers un exécutable arbitraire hors du dossier de l'app.Validation
Build + clippy 0 warning, 90 tests verts (2 nouveaux : exact-match et jumeaux .sig), smoke test de boot OK.