Repository navigation
SimpleRisk 20260917-001 Release - #144
Closed
WolfangAukang wants to merge 12 commits into
Closed
WolfangAukang wants to merge 12 commits into
WolfangAukang wants to merge 12 commits into
Conversation
…undle 20260709-001 and 20260811-001 were release candidates folded into the 20260820-001 GA -- simplerisk/code has no release for either, and 20260820-001 is the combined GA record for all three. They stayed in this feed describing bundles bundles-test no longer serves (that channel keeps exactly one bundle, which publish-testing asserts), and merging this feed into prod is how they reached the production manifests with checksums and upgrade hops for bundles that 403 there. Produced by scripts/xml_manipulation/retract_unpromoted_rcs.py (code-development #2164), which is what will do this automatically at each RC cut from now on. Their <release> and extra_compatibility entries are removed; their upgrade hops are KEPT and repointed at 20260820-001, deliberately -- an instance running a retracted RC still has to learn where to go, or next_version() finds nothing, reports it as current, and it silently stops receiving patches. Also clears bundle_sha256 on 20260519-001. Its bundle was pruned from bundles-test when the next RC superseded it, so the checksum described nothing; the feed now claims exactly one bundle, the one the channel actually serves. bundle_md5 is left alone on every entry -- 111 historical entries carry one and prod does too, so stripping them here would invent a divergence rather than fix one. Verified with scripts/validate_feed.py against the test channel: 1 problem before, PASSED (9 checks) after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
carried testing-channel truth into the production manifests. The VM hashes in that merge are correct and are KEPT -- this reverts only the parts that describe the prod channel. What was wrong, and how each value was confirmed: - 20260820-001 bundle_md5/bundle_sha256 pointed at the TESTING bundle (61c78cca...). The testing bundle for this version was rebuilt at 15:04 on 2026-08-21 by the CHERRYPICK-ga-notes-testing merge, so it is different bytes from the GA bundle promoted at 14:41. Restored to 3e279416..., verified by downloading BOTH the prod S3 object and the simplerisk/code release asset -- two independent artifacts that agree with each other. - 20260519-001 bundle_md5/bundle_sha256 likewise. Restored to 7d7fb242..., verified by downloading the served prod S3 bundle. - 20260519-001 next_release, and upgrade_path.xml, routed upgrades through 20260709-001 and 20260811-001. Those are testing RCs that never shipped GA -- simplerisk/code has no release for either, and 20260820-001 is the combined GA record for all three. Their bundles 403 on the prod channel, so a customer on 20260519-001 would have been sent to a bundle that is not there. Restored to the direct 20260519-001 -> 20260820-001 hop. - The 20260811-001 / 20260709-001 release and extra_compatibility entries are removed for the same reason: they are not prod releases. Caught by simplerisk/docker's image build, which verifies the bundle against this feed and fails closed. Every docker master PR has been blocked since 20:49. The prod feed has a single writer -- sync_code_repo.yml's update_feeds.sh, which writes the real GA asset hashes. Merging the testing branch into it bypasses that writer and silently replaces GA truth with RC truth. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The feed is a set of claims about published artifacts and nothing checked them.
On 2026-08-21 a merge of the updates-test branch into this one replaced the GA
bundle checksums with the testing channel's and added upgrade hops through
releases that never shipped. Nothing here went red. The break surfaced hours
later in simplerisk/docker, whose image build verifies the bundle against this
feed and fails closed -- blocking every PR in that repo.
Asserts the claims against reality:
- every manifest parses, and carries no DTD (these are generated files; a
DOCTYPE would only ever be an entity-expansion attack on the runner)
- Current_Version names a release that exists and publishes a checksum
- every release publishing a bundle_sha256 has a bundle actually fetchable on
this channel, hashing to exactly that value
- upgrade_path routes only to releases that exist, and agrees with each
release's next_release
The checked set is deliberately "entries making a claim", not "all entries".
A historical release carries no checksum and its bundle is long gone from the
channel -- that is correct and unremarkable. Publishing a checksum is what makes
a claim checkable, so that is the trigger. Only 2 of 111 entries qualify today,
so this downloads two bundles.
Verified against both states: FAILS on a657849 with exactly the 4 real defects
and no false positives, PASSES on the #141 fix.
Worth making a required status check on both feed branches. Unlike a branch
restriction it catches a bad write however it arrives -- branch merge, hand
edit, or a broken generator run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
|
Closing in favor of #145, which has merged. It landed the VM digests for 20260917-001 (the four Promoting the whole
The prod feed has a single writer ( Still to do: reconcile |
jsokol
added a commit
that referenced
this pull request
Sep 30, 2026
The two feed branches differ on purpose and prod has a single writer, so merging updates-test into updates.simplerisk.com overwrites GA bundle checksums and adds hops for RCs that never shipped (#140, attempted again in #144). Add a check that fails a same-repo PR from updates-test into prod, and a README documenting the topic-branch path for one-off prod changes (#139, #145). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
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
2 participants
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.
Promotes the testing feed to the GA channel, carrying the VM artifact digests for
SimpleRisk 20260917-001.
Both appliances are published and publicly fetchable:
simplerisk-20260917-001-virtualbox.zipe11345d04d767d3a80af39345f81a64csimplerisk-20260917-001-vmware.zip577f957461e2b6b2d175dd7f776bd69bservices.simplerisk.com?type=ovf&release=20260917-001resolves302to the vmware zip,and an anonymous range read returns
206on both.Warning
Do not merge until the
20260820-001bundle checksum is resolved. This branchcarries the testing channel's value, and merging it would overwrite the GA value that
#141 restored — the same break as 2026-08-21, which fails
simplerisk/dockerclosed.Running
scripts/validate_feed.py prodagainst this branch's content, which is what therequired check does on this PR:
Two releases differ between the branches, and neither difference belongs to this release:
updates.simplerisk.comupdates-test.simplerisk.com20260820-0013e279416…(matches served bytes)61c78cca…(testing channel)20260519-0017d7fb242…falseThis is exactly the defect class #142 was built to catch, and the check is doing its job.
The VM digests this PR exists to deliver are unaffected — a control run against the
untouched branch reproduces the same pre-existing errors.
Options: correct the two
bundle_sha256values onupdates-test.simplerisk.comso thebranches genuinely converge, or land the VM digests via a topic branch off
updates.simplerisk.com(as #139 did) and leave this promotion for when the channels arereconciled.
🤖 Generated with Claude Code