docs: correct two stale cut-release follow-ups, and record the glib advisory - #315
Merged
Conversation
…ase disproved Both were verified against the workflow and the packaging directory during the 0.9.67 chain, not inferred. - winget: release-artifacts.yml carries a winget job gated on publish-release that submits the version-update PR itself (it opened microsoft/winget-pkgs#413853 for 0.9.67). The skill told the next maintainer to run wingetcreate by hand, which would have produced a duplicate PR. It now says watch, gives the search command, and lists the four conditions under which the job skips cleanly - so a green job is not read as proof a PR exists. - FlatPark: packaging/flatpark has been pinned at 0.9.62 across five releases because FlatPark's bot has owned the pin since that submission merged and rewrites its own copy. The skill listed a post-release metainfo and extra-data re-pin that nobody has done or needs to do. The trap that remains real - bumping half the descriptor fails flatpark-descriptor.test.ts - moves into the Traps table, where the instruction is now to leave the directory alone.
Dependabot alert 1 (GHSA-wrw7-89jp-8q8g) reports unsoundness in glib::VariantStrIter for >= 0.15.0, < 0.20.0. The lock carries glib 0.18.5 and the requirement chain pins it: tauri 2.11.5 -> gtk 0.18.2 -> glib ^0.18. cargo update --precise 0.20.0 fails on that constraint, 2.11.5 is the latest published tauri, and gtk 0.18.2 is the crate's latest release and is published as unmaintained, so the fix cannot arrive on that line at all. Recorded rather than dismissed: the shell touches no glib API of its own (its direct dependencies are tauri, serde_json and libc), which makes the risk low but does not prove the path unreachable. The entry names cargo tree -i glib as the re-check to run on each Tauri upgrade.
cevheri
changed the title
|
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.
The 0.9.67 chain exercised the release runbook end to end and two Phase 7 entries turned out to describe work that is either automated or nobody's job any more. Both corrections are verified against the workflow and the packaging directory, not inferred.
winget - was: run
wingetcreateby handrelease-artifacts.ymlcarries awingetjob (needs: [guard, publish-release, channels]) that submits the version-update PR itself, strictly after publish because the upstream validation pipeline downloadsInstallerUrl. It opened microsoft/winget-pkgs#413853 for 0.9.67 without anyone asking. Following the old instruction would have produced a duplicate PR against a repo that does not deduplicate them.The row now says watch rather than run, gives the search command, and enumerates the four conditions under which the job skips cleanly -
ci_enabledfalse, missingWINGETCREATE_GITHUB_TOKEN, no listing yet, version already upstream - so a green job is not mistaken for proof that a PR was opened.FlatPark - was: post-release metainfo and extra-data re-pin
packaging/flatpark/has read 0.9.62 for five releases.packaging/flatpark/README.mdexplains why: FlatPark's bot has owned the pin since that submission merged, re-runsresolve-update.shafter each of our releases and rewrites its own copy, so the staged directory drifts by design. The follow-up the skill described has not been performed since 0.9.62 and does not need to be.The row is removed from Phase 7. The part that is still true - bumping half the descriptor fails
tests/unit/flatpark-descriptor.test.ts, which requires the metainfo's newest<release>to equal the extra-data pin - moves into the Traps table, reworded as leave the directory alone.Checked and left alone
The OperatorHub row's claim that
operator/bundle/ships norelease-config.yaml, so the second FBC PR must be opened by hand, is still accurate. Documentation only.Dependabot alert 1 (added in the second commit)
GHSA-wrw7-89jp-8q8g, medium: unsoundness in
glib::VariantStrIter'sIteratorandDoubleEndedIteratorimpls, affecting>= 0.15.0, < 0.20.0.desktop/src-tauri/Cargo.lockcarries 0.18.5.There is no upgrade path, verified rather than assumed:
cargo update -p glib@0.18.5 --precise 0.20.0fails:gtk 0.18.2requiresglib ^0.18, andtauri 2.11.5requires that gtk.gtkcrate cannot deliver the fix either: 0.18.2 is its latest release and it is published as UNMAINTAINED, pointing users atgtk4.So the advisory closes only when Tauri's Linux backend moves off the GTK 3 bindings. Nothing in
desktop/src-tauri/uses glib directly (its dependencies aretauri,serde_json,libc; no source file mentionsgliborVariant), which makes the practical risk low without proving the path unreachable.Recorded in
docs/BACKLOG.mdas P1 under a new Dependencies section, withcargo tree -i glibas the re-check to run on each Tauri upgrade. The alert is deliberately left open rather than dismissed — dismissing it would need a reachability claim this evidence does not support. Say the word if you would rather dismiss it as tolerable risk.