Kernl 0.2.0: de Docker-stack draait niet langer zonder authenticatie
Loopback is geen vertrouwensgrens tegenover een browser. Deze release haalt de modus zonder authenticatie uit de quick start, zet CORS op deny-by-default, stopt met het uitdelen van licentiesleutels per e-mail, en repareert back-ups die de verkeerde database kopieerden.
Deze Kernl-release gaat vrijwel volledig over beveiliging, en het belangrijkste probleem zat op het pad dat iedereen neemt: de Docker quick start.
Loopback is geen vertrouwensgrens
docker-compose.yml leverde KERNEL_ALLOW_UNAUTH=1 mee, gerechtvaardigd doordat het dashboard op 127.0.0.1 werd gepubliceerd. Die redenering houdt geen stand tegenover een browser.
Gecombineerd met een wildcard Access-Control-Allow-Origin op elke respons kon elke pagina die de gebruiker open had de hele kernel cross-origin lezen — en schrijven, inclusief het MCP-tooloppervlak. Dat een poort lokaal is, weerhoudt de browser van de gebruiker er niet van degene te zijn die het verzoek doet.
De quick start draait nu met het token dat de kernel bij de eerste start genereert.
CORS op weigeren
Access-Control-Allow-Origin wordt alleen verstuurd voor een origin die expliciet in CORS_ALLOWED_ORIGINS staat. Een lege lijst betekent alleen same-origin, en dat is wat het meegeleverde dashboard nodig heeft.
Voorheen betekende een lege lijst *, en kreeg een niet-overeenkomende origin de eerste geconfigureerde origin terug in plaats van een weigering.
Licentieherstel deelde de licentie uit
GET /api/license/lookup gaf de volledige licentie-JWT terug — de downloadcredential voor elke extensie die die klant bezit — aan iedereen die het e-mailadres kende. Als toegift bevestigde de 404 welke adressen van klanten waren en welke niet.
De licentie wordt nu gemaild naar het geregistreerde adres, met in beide gevallen hetzelfde 202-antwoord, of het adres nu van iemand is of niet.
Torrents is daarnaast op runtime afgeschermd. De betaalde extensie werd geleverd zonder licentiecontrole op de MCP-tools of op de /api/torrents/*-routes; het enige beschermde stuk was de download van de bundle.
Tot slot wordt het auth-token van de eerste start aan de browser doorgegeven via het URL-fragment, dat nooit naar de server gaat, in plaats van via een query string.
Back-ups pakten de verkeerde database, en meldden dat opgewekt
backup.sh kopieerde de ./data/kernel.db uit de repo — meestal een verouderd restant — in plaats van de database in het Docker-volume. Het gebruikte cp op een database in WAL-modus die door de kernel geopend was. En het eindigde met code 0 als er niets gevonden werd.
Het maakt nu een snapshot via SQLite (VACUUM INTO), controleert het resultaat voordat het een back-up genoemd wordt, en faalt luid. Ook .kernel-encryption-key wordt meegenomen, zonder welke versleutelde secrets in een teruggezette database onherstelbaar zijn.
Restores hadden het spiegelbeeldige probleem: restore.sh zette de database in de ./data van de repo, ook bij Docker-deployments, sloeg de encryptiesleutel over, en meldde “starting fresh” wanneer het archief helemaal geen database bevatte. Het vereist nu een expliciet doel met --docker of --native en weigert een leeg archief.
Twee dingen die succes meldden zonder iets te doen
- Betaalde licenties werden geweigerd op elke installatie die geen Docker was. De kernel verwachtte issuer
issuer.mtwkernel.comterwijl licenties worden uitgegeven doorissuer.lifekernl.com, en alleendocker-compose.ymlzette de override. Installaties via rpm, deb, dmg en msi konden een geldige sleutel niet activeren. - Code signing draaide nooit, met of zonder certificaten. De ondertekeningsstappen van de release-workflow waren afgeschermd met
if: env.X != '', metXgedefinieerd in hetenv:-blok van diezelfde stap, dat niet in scope is voor de conditie van die stap zelf. Elke release publiceerde onondertekende artefacten en meldde succes.
De kernel bond zich ook aan loopback, zelfs met authenticatie aan: loadConfig() bepaalde de bind voordat de bootstrap het auth-token genereerde, waarmee een expliciete 0.0.0.0 permanent werd overschreven. Die beslissing valt nu op de plek waar het definitieve token bekend is.
En de eerste start van een native installatie liep dood op een inlogscherm dat om een token vroeg dat de gebruiker nooit was getoond. De macOS- en Windows-launchers geven het nu door; de Linux-launcher print waar je het vindt.
Zo werk je bij
curl -fsSL https://lifekernl.com/install.sh | sh
Kom je van 0.1.x met de Docker-stack, controleer dan je CORS_ALLOWED_ORIGINS vóór het bijwerken: een lege lijst betekent niet langer *. De volledige details staan in de CHANGELOG.