fix(release): toets de appimagetool-pin vóór de tag (#2324) #2326

Merged
brenno merged 1 commit from fix/2324-appimagetool-pin-preflight into main 2026-10-06 17:09:27 +00:00
Owner

Sluit #2324.

Kern

v0.6.14 brak pas ná de onomkeerbare tag: upstream had de rollende continuous-asset van appimagetool op 04-10-2026 vervangen. De vastgelegde sha256 faalde terecht fail-closed in de Linux-job (release-run 5479, job 23681) — maar dat was tien minuten en één tag te laat.

Wijziging

  • scripts/release_auto.sh: nieuwe assert_appimagetool_pin in de pre-flight, vóór elke branch/tagmutatie. Leest APPIMAGETOOL_URL/APPIMAGETOOL_SHA256 uit .forgejo/workflows/release.yml (of dezelfde env-override als package_linux.sh), leidt de GitHub release-API af uit de asset-URL, en vergelijkt de pin met het officiële digest-veld.
  • Afwijking → die met vastgelegde én actuele digest plus concreet herstelcommando (API bekijken, pin bijwerken, commit op main).
  • Onleesbare API of ontbrekend digest-veld → onbekend, niet afwezig.
  • Bij --resume mét al-gepushte tag wordt een afwijking een waarschuwing: er is dan geen mutatie meer om vóór te blokkeren en de lopende keten gebruikt de pin van de tag-commit.
  • De pin zelf is bijgewerkt naar 95cbe7cc…d29b6 na herkomstcontrole: de GitHub-API-digest én een zelfstandig gedownloade kopie van de asset geven identiek die hash (klopt met het incidentbewijs uit het issue).
  • packaging/README.md beschrijft de nieuwe pre-flight en de herkomstcontrole bij re-pinnen; commentaar in release.yml wijst ernaar.

Onderzoek: rollende download vervangen?

Gevraagd alternatief — een intern content-addressed exemplaar of appimagetool in het gepinde ocideck-ci-image bakken — is mogelijk (image is al digest-gepind), maar koppelt elke appimagetool-update aan een image-rebuild + manifestwijziging in een andere pipeline. De digest-poort geeft nu al fail-closed gedrag vóór de tag. Een forge-eigen kopie (bijv. als release-asset op de forge zelf) blijft een nette vervolgstap als upstream-churn structureel blijkt; nu niet nodig.

Tests

Nieuw: test/release_auto_appimage_pin_test.dart — hermetisch harnas, geen netwerk:

  • match → groen; mismatch → blokkade vóór de tag mét herstelcommando;
  • onleesbare API en ontbrekend digest-veld → onbekend, niet afwezig;
  • ontbrekend pinbestand → hoorbare fout;
  • --resume met/zonder gepushte tag → waarschuwing resp. blokkade;
  • env-override deelt het contract met package_linux.sh.

Verificatie

  • make check volledig groen.
  • De echte GitHub-API is bevraagd: digest staat op het asset (geverifieerd live), en de bytes zelf zijn gehasht ter herkomstcontrole van de nieuwe pin.
  • Geen volledige release-run gedaan (vereist een echte tag); de hermetische tests dekken match, mismatch, onbekend en resume-gedrag.

Generated with Devin

Sluit #2324. ## Kern v0.6.14 brak pas ná de onomkeerbare tag: upstream had de rollende `continuous`-asset van appimagetool op 04-10-2026 vervangen. De vastgelegde sha256 faalde terecht fail-closed in de Linux-job (release-run 5479, job 23681) — maar dat was tien minuten en één tag te laat. ## Wijziging - `scripts/release_auto.sh`: nieuwe `assert_appimagetool_pin` in de pre-flight, vóór elke branch/tagmutatie. Leest `APPIMAGETOOL_URL`/`APPIMAGETOOL_SHA256` uit `.forgejo/workflows/release.yml` (of dezelfde env-override als `package_linux.sh`), leidt de GitHub release-API af uit de asset-URL, en vergelijkt de pin met het officiële `digest`-veld. - Afwijking → `die` met vastgelegde én actuele digest plus concreet herstelcommando (API bekijken, pin bijwerken, commit op main). - Onleesbare API of ontbrekend `digest`-veld → *onbekend*, niet afwezig. - Bij `--resume` mét al-gepushte tag wordt een afwijking een waarschuwing: er is dan geen mutatie meer om vóór te blokkeren en de lopende keten gebruikt de pin van de tag-commit. - De pin zelf is bijgewerkt naar `95cbe7cc…d29b6` na herkomstcontrole: de GitHub-API-digest én een zelfstandig gedownloade kopie van de asset geven identiek die hash (klopt met het incidentbewijs uit het issue). - `packaging/README.md` beschrijft de nieuwe pre-flight en de herkomstcontrole bij re-pinnen; commentaar in `release.yml` wijst ernaar. ## Onderzoek: rollende download vervangen? Gevraagd alternatief — een intern content-addressed exemplaar of appimagetool in het gepinde `ocideck-ci`-image bakken — is mogelijk (image is al digest-gepind), maar koppelt elke appimagetool-update aan een image-rebuild + manifestwijziging in een andere pipeline. De digest-poort geeft nu al fail-closed gedrag vóór de tag. Een forge-eigen kopie (bijv. als release-asset op de forge zelf) blijft een nette vervolgstap als upstream-churn structureel blijkt; nu niet nodig. ## Tests Nieuw: `test/release_auto_appimage_pin_test.dart` — hermetisch harnas, geen netwerk: - match → groen; mismatch → blokkade vóór de tag mét herstelcommando; - onleesbare API en ontbrekend digest-veld → onbekend, niet afwezig; - ontbrekend pinbestand → hoorbare fout; - --resume met/zonder gepushte tag → waarschuwing resp. blokkade; - env-override deelt het contract met `package_linux.sh`. ## Verificatie - `make check` volledig groen. - De echte GitHub-API is bevraagd: `digest` staat op het asset (geverifieerd live), en de bytes zelf zijn gehasht ter herkomstcontrole van de nieuwe pin. - Geen volledige release-run gedaan (vereist een echte tag); de hermetische tests dekken match, mismatch, onbekend en resume-gedrag. Generated with [Devin](https://devin.ai)
Upstream verving de rollende continuous-asset op 04-10-2026; de pin faalde
terecht, maar pas in de Linux-job ná de onomkeerbare tag (run 5479,
job 23681). De pre-flight vergelijkt de vastgelegde sha256 nu met het
digest-veld uit de GitHub-release-API — een afwijking stopt de keten met
een concreet herstelcommando, een onleesbare API is onbekend (niet
afwezig), en bij --resume mét gepushte tag is het beeld informatief want
er is dan geen mutatie meer om vóór te blokkeren.

De pin is na herkomstcontrole bijgewerkt naar 95cbe7cc… (API-digest én
zelfstandig gedownloade bytes). Onderzocht alternatief — appimagetool in
het gepinde CI-image bakken — is mogelijk maar koppelt elke tool-update
aan een image-rebuild; de digest-poort geeft nu al fail-closed gedrag
vóór de tag, en een forge-eigen content-addressed kopie blijft een optie
als upstream-churn structureel wordt.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
brenno merged commit a9f1c38f24 into main 2026-10-06 17:09:27 +00:00
Sign in to join this conversation.
No description provided.