edb91c4749be12607b53a46c4202ffe8931c86fd
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 HarmenandClaude Opus 5
|
edb91c4749 |
Het ontwerp van de limiter en de pagina, en de limiter is klein
createRelay uit @evolu/nodejs neemt twee terugroepfuncties, isOwnerAllowed en isOwnerWithinQuota, en Trezor doet in createEvoluRelay.ts zelf niets anders. Hun hele quota-manager met Postgres bestaat alleen om de tabel te vullen die die twee raadplegen. Wij vullen ze met eigen logica en bouwen niets na. Weg 1 uit Bereikbaarheid 4b is daarmee veel goedkoper dan daar aangenomen, en dat is wat de keuze van de gebruiker mogelijk maakt. De logica zoals hij hem formuleerde: de eerste eigenaar die zich meldt wint, een schakelaar bepaalt of er nog nieuwe bij mogen, en data is per eigenaar te wissen. Dat laatste doet het relay-proces zelf, aangestuurd met een vlagbestand vanaf de pagina; geen tweede container die langszij in de SQLite schrijft en geen Docker-socket. Twee feiten uit de broncode van Evolu die het ontwerp sturen en die in de naslag staan met bron. De gepubliceerde image zet isOwnerWithinQuota op 1 MB per eigenaar en laat isOwnerAllowed weg, dus een kale relay is niet volledig ongelimiteerd, maar dat plafond geldt ook voor de echte gebruiker. En de relay-URL van de client bevat een pad dat letterlijk wordt overgenomen, wat een goedkope proxy-controle mogelijk maakt; die is bewust niet genomen nu de allowlist er komt. De poorten gaan om: pagina achter app_proxy met de inlog aan, relay op een eigen gepubliceerde poort waar Zoraxy met TLS naartoe wijst. Dat lost open punt 2 op zonder het bezwaar dat daar stond, en het volgt het patroon dat Electrum Gate in deze repo al gebruikt. De pagina volgt hetzelfde ontwerpsysteem, zonder de Google Fonts-verwijzing eruit. Open punt 8 en 2 zijn beslist, fase 5 staat als takenlijst. De gebruiker heeft de oude installatie van de Umbrel gehaald; er wordt niet geupdatet maar opnieuw gebouwd. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
9d53612db8 |
De backendwissel is geen aanname meer: Fulcrum werkt zonder aanpassing
Fulcrum is uitgesynct en de gebruiker heeft omgeschakeld. De app hoefde niets
te weten van de wissel, want hij leest ${APP_ELECTRS_NODE_IP} en Fulcrum aliast
zichzelf naar die naam. Bevestigd langs alle drie de wegen: een wallet van
buiten over TLS op 50022, een wallet binnen het netwerk, en het dashboard met
een antwoordende server.
Daarmee is hoofdstuk 4 van de appstore-spec waargenomen gedrag in plaats van
een afleiding uit andermans broncode, en is de poortbotsing op 50002 ook in de
praktijk weg. Fase 3 van Appstore is af.
Gratis meegekomen: umbrelOS herstartte de app zelf bij de wissel en hij kwam
terug met dezelfde certificaatkeuze. Dat is de vervangende start/stop-controle,
maar nadrukkelijk geen antwoord op de volgordevraag, want Zoraxy draaide al.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
c80d587100 |
Wat een relay ziet, en waarom het risico niet vertrouwelijkheid is
De gebruiker vroeg of iemand met kennis van de API zijn labels kan opvragen zodra de relay op een domein staat. Nee, en de reden is scherper dan "het is versleuteld". Uit een OwnerSecret worden met SLIP-21 drie onafhankelijke waarden afgeleid: een publieke OwnerId, een encryptiesleutel en een rotatable write key. Alleen de eerste gaat naar de relay. Het aardige is dat de OwnerId expres niet geheim is. De beveiliging leunt er niet op dat je adres onbekend blijft, en dat is het tegenovergestelde van een systeem waar een onraadbare URL de grens vormt. Daarom kan deze relay bij een onbekende partij staan. Twee dingen expres niet gladgestreken. Of iemand die een OwnerId kent de versleutelde blobs kan ophalen staat nergens gedocumenteerd; kan het, dan lekt dat bestaan, activiteit en bij benadering omvang, niet inhoud. En onraadbaarheid van de OwnerId beschermt tegen het aflopen van een relay, niet tegen lezen. Dat verschuift waar Bereikbaarheid over gaat. Het risico van een open eindpunt is misbruik als gratis versleutelde opslag: een kale relay kent geen accounts en kan per definitie niet weten van wie de data is. Dat is met terugwerkende kracht de tweede functie van Trezor's quota-manager, naast facturering, en die haalden wij eruit. Het voorstel van de gebruiker voor een eigen quota-manager met een allowlist van OwnerId's staat erin, met drie uitvoeringen en hun prijs. De netste is createRelay uit @evolu/nodejs, dat auth expliciet als reden noemt om die API te gebruiken, maar dan bouw je weer een eigen image en verlies je de winst van de gepubliceerde. Met een detail dat het lastiger maakt dan het klinkt: je moet je eigen OwnerId kennen om hem te vlaggen, en Suite toont die waarschijnlijk nergens. Uitweg is niet laten typen maar laten leren: de eerste eigenaar die verbindt wordt toegelaten. Meegenomen uit de vorige bevinding: open punt 2 is beantwoord, Suite eist geen TLS. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
dc0bb9f0dc |
De client zegt het zelf: bij een eigen relay wordt de quota-manager genegeerd
De gebruiker wees erop dat de broncode van Trezor Suite lokaal staat, in het project Trezor onder Repos/trezor-suite. Dat beantwoordde in een half uur wat uit de serverkant alleen niet te halen was, en het draait de vraag van vanavond om. Uit een commentaarregel van Trezor zelf, in suite-common/suite-sync-quota-manager/src/createSuiteSyncQuotaManagerCompositionRoot.ts: "We only want to use QM for our own relay servers. In case custom URL has been set, QM is ignored, unless enforceQuotaManager is set (used for e2e tests)." Die vlag staat standaard op false. Daarmee is het pakket dat nu draait niet alleen zwaar maar waarschijnlijk kapot bij ontwerp. Met een eigen relay-URL registreert de cliënt geen eigenaar, en de relay van Trezor weigert iedereen zonder rij in de limietentabel. Die rij komt er dus nooit: het enige dat hem zou maken wordt door de cliënt overgeslagen. Niet de kale Evolu-relay was de gok, maar deze. Twee dingen die er gratis bij kwamen en die vragen van eerder beantwoorden. Suite neemt http:// (de e2e-test gebruikt http://10.0.2.2:4000 en :4001), dus TLS is geen eis en dat raakt het masterplan Bereikbaarheid. En de instellingen staan onder dev-utils, met twee losse velden voor relay en quota-manager, plus een bevestiging op het apparaat bij het aanzetten. Wat er nog echt open is, is geen redenering maar een proef: Suite gebruikt @evolu/web@3.0.0-next.1 met een eigen patch in .yarn/patches, en de gepubliceerde relay-image hoeft daar niet bij te passen. Dat is met docker run in minuten te weerleggen en staat als eerste taak. De vindplaats zelf is als naslag opgeschreven, met de vijf bestanden die iets opleverden en twee waarschuwingen: het meeste komt uit suite-native, dus de mobiele app, en het is een kloon op een moment in de tijd. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
836bc58bd6 |
Er zijn twee relays, en we pakketteerden de zware
De gebruiker droeg evolu.dev/docs/relay aan met de vraag of dat de server is waarop deze app gebaseerd is. Niet dezelfde, wel de bovenstroom, en dat verschil is groot genoeg om het pakket ter discussie te stellen. trezor/trezor-suite-sync is niet Evolu maar Trezor's inzet ervan, met een Postgres en een quota-manager voor hun gehoste dienst. Het project eronder, evoluhq/evolu, heeft een eigen relay: een container, een gepubliceerde image docker.io/evoluhq/relay:latest, een datavolume in plaats van een database, en niets gedocumenteerd over toegangscontrole. De documentatie noemt die relay stateless en geschikt voor serverless. Praat Trezor Suite daarmee, dan vervalt vrijwel alles wat dit pakket ingewikkeld maakt: de bouwstap, het eigen register, de onderhoudsplicht op een image, de Postgres met zijn wachtwoord, en de eigenaarsregistratie die nu de blokkade is. Drie containers worden er een. Niet aangenomen en niet gemeten, dus het staat als open punt 6 met de proef erbij: docker run, Suite ernaartoe wijzen, label maken. Dat kost minuten en het antwoord bepaalt of er nog iets aan de huidige vorm verbeterd moet worden. Daarom staat het ook als eerste in "Volgende stap", vóór het nakijken van het databaseschema: dat laatste is weggegooid werk als de kale relay volstaat. Dat het huidige pakket deze laag heeft, is geen fout maar het gevolg van de volgorde waarin het gevonden is. Dat staat er ook zo bij, want anders leest dit over een maand als een verkeerde beslissing in plaats van als een ontdekking. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
fd62f48309 |
De Tor hidden service is de tweede weg naar binnen, en die staat nergens
De gebruiker vroeg of Evolu Relay kwaad kan op zijn Umbrel. Het eerlijke antwoord was nee met twee kanttekeningen, en de tweede stond in geen enkel bestand: umbrelOS maakt per app een Tor hidden service en die stond gewoon aan. Samen met PROXY_AUTH_ADD: "false" betekent dat de relay bereikbaar vanaf het internet, alleen beschermd doordat het .onion-adres onraadbaar is. De gebruiker zet hem uit. Wat dit lastig maakt om te zien: het staat niet in de compose van de app. Je kunt dat bestand volledig lezen en concluderen dat alleen je LAN erbij kan. Vandaar dat het nu op drie plekken staat: in de compose bij de instelling waar de afweging gemaakt wordt, in het plan bij de statuspagina-vraag, en in de naslag. De naslag is de belangrijkste van die drie, want het mechanisme is een eigenschap van umbrelOS en geldt voor elke app. Het gevolg niet: bij Electrum Gate legt dezelfde hidden service alleen de inlogpagina bloot, want daar staat de proxy-inlog aan en loopt de TLS-poort niet via de proxy. Die vergelijking staat er als tabel bij, want de instelling alleen zegt niets; het is de combinatie. Opgemerkt door de gebruiker dat het ook voor Electrum Gate zou gelden. Deels terecht, en dat is precies waarom het in de gedeelde naslag hoort en niet in het plan van één app. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
96565085a5 |
umbreld pullt buiten compose om, dus pull_policy kon nooit werken
De installatie faalde, en de foutmelding was voorspelbaar maar de oorzaak niet:
pull access denied for whatsnext/evolu-relay
at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17
Die stacktrace is het punt. De pull komt uit docker-modem, de Docker-client van
umbreld zelf, dus rechtstreeks op de Docker Engine API. Compose komt er niet aan
te pas en de compose wordt alleen gelezen om te zien welke images erin staan.
pull_policy is een sleutel van de Compose-specificatie en wordt dus nooit
bekeken. Mijn reparatie van de vorige commit kon per definitie niet werken; hij
is eruit, want een sleutel die niets doet met een commentaar dat beweert van wel
is erger dan geen sleutel.
Waar die fout vandaan kwam: ik las in app-script dat install een
`compose "${app}" pull` doet en nam aan dat dat het pad was. Dat bestand is de
legacy-compat-laag en niet wat umbrelOS 1.x loopt bij een installatie vanuit de
interface. Dat staat nu als waarschuwing in de naslag, want het is precies het
soort bron dat overtuigend leest en het verkeerde antwoord geeft.
De echte regel, nu op het apparaat vastgesteld in plaats van uit code afgeleid:
elke image in de compose van een app moet anoniem uit een register te halen zijn.
Een lokaal gebouwde tag werkt niet, hoe goed docker compose up er ook mee overweg
zou kunnen.
Het image-veld staat er nog en wijst nog steeds naar de lokale tag. Dat is
bewust: het commentaar erboven zegt nu dat het zo niet werkt en wat er moet
komen. Weghalen zou de app-map stiller maar niet beter maken, en de keuze voor
een register is aan de gebruiker.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
8004acfae9 |
pull_policy: never, anders faalt de installatie op een image die nergens staat
De image is gebouwd op de Umbrel en staat alleen in de lokale Docker-opslag: er
is geen register. Dat leek te werken omdat `docker compose up` niets ophaalt zolang
de image lokaal bestaat. Bij het nakijken van app-script in umbreld bleek dat niet
het pad dat een installatie loopt.
umbreld draait `compose "${app}" pull` bij install, bij update en bij
post-patch-update. Die zou whatsnext/evolu-relay:c03a204 op Docker Hub zoeken,
waar hij niet bestaat, en dan faalt de installatie voordat er iets gestart is. Met
pull_policy: never slaat compose die twee services over bij het ophalen. Postgres
houdt de standaard, want die komt wél uit een register.
Bijkomend voordeel dat het houdt zodra er ooit een register is: ontbreekt de image,
dan is de fout "niet gevonden" en die wijst naar de overgeslagen bouwstap, in plaats
van een mislukte netwerkpoging die naar het register wijst.
Uit hetzelfde bestand meegenomen naar de naslag: starten gaat met
`up --detach --build`, dus umbreld zou een build:-blok wél uitvoeren. Toch blijft
bouwen-in-de-app een slecht idee, en nu met een tweede reden naast de whitelist: de
installatie hangt dan tijdens het bouwen. Op deze machine duurde dat 50 seconden.
Geen versieverhoging: deze app is nog nooit geïnstalleerd, dus er is geen manifest
op een apparaat om tegen te vergelijken.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
1a87a45685 |
De bovenstroomse repo gelezen, en twee aannames sneuvelden
De gebruiker wil de Evolu Relay-app meteen pakketteren. Daarvoor moest fase 1 van Proefopstelling eerst af, want een compose schrijven op aannames is precies wat dat plan moet voorkomen. Upstream-evolu-relay.md gaat daarmee van vooronderzoek naar nagetrokken, met een bron-URL per feit. De quota-manager is in de praktijk verplicht, en om een andere reden dan gedacht. Niet omdat de relay hem aanroept: er is geen HTTP-koppeling en geen URL in de configuratie, ze delen alleen de Postgres. Maar isOwnerAllowed() eist een rij in de limietentabel en de quota-manager maakt die rijen. Zonder hem is de relay dus niet open maar dicht voor iedereen. Dat maakt de tweede weg interessant, want een rij is ook met de hand te zetten; de prijs daarvan is schrijven in andermans schema. Er is geen publieke image. Trezor bouwt er wel een maar duwt hem naar een eigen Amazon ECR, en op Docker Hub staat niets. Zelf bouwen en publiceren, of geen app, en dat is een doorlopende verplichting. Bijvangst die een risico wegneemt: datzelfde werkproces bouwt amd64 en arm64, dus de Dockerfile is bovenstrooms bewezen op een Pi. Nieuw risico dat ervoor terugkomt: LICENSE.md is door GitHub geclassificeerd als "other", en zodra je een image publiceert distribueer je hun software. Twee kleinere correcties. De compose van Trezor draait de relay niet, er staan alleen Postgres en Prometheus in; het is een ontwikkelopstelling en wat zij uitrollen staat in .k8s/. En alle processen komen uit één image met per service een ander command, dus het worden geen drie images. Eén tegenspraak blijft staan en is expres niet weggeschreven als feit: .env.sample zegt dat SERVER_ENV=prod authenticatie aanzet, maar in de code die ik las bepaalt die vlag alleen het logniveau en staan de controles onvoorwaardelijk aan. Eén van de twee is achterhaald. Dat is met één keer starten te meten en het staat als taak in fase 2. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
67ed9b603b |
Eén app store, twee apps
umbrelOS leest per store één repo, dus twee apps in twee repo's kan niet. Deze repo is de store en bevat vanaf nu Electrum Gate en het werk aan Evolu Relay. Opgezet als verse repo op verzoek van de gebruiker: de historie van ElectrumTLS en van EvoluRelay komt niet mee. Dat heeft één gevolg dat verder gaat dan opruimen. In de historie van ElectrumTLS staat het domein van de gebruiker en het certificaatpad, van vóór de opschoning van 19-08. Die komt hier niet in. Zolang die repo op de Git-server blijft staan verandert dat niets, dus het weghalen ervan is het laatste stuk van open punt 3 van het plan Appstore, en geen bijzaak. De store zelf hoefde niet te veranderen: store-id whatsnext, en dus blijft het app-id whatsnext-electrum-gate. Dat hangt aan het store-id en niet aan de URL, dus voor umbrelOS is dit dezelfde app in een andere store. Dat de store op 19-08 naar de maker genoemd werd in plaats van naar deze ene app, betaalt zich hier uit. Wat de documentatie betreft is dit één wortel voor beide apps, en dat was de reden om samen te voegen en niet de prijs ervan: de appstore-spec, het pinnen van images en de werkwijze golden al voor allebei en stonden in twee repo's naast elkaar. De kruisverwijzing die daarvoor nodig was (Referenties/Umbrel-appstore.md in de oude EvoluRelay-repo) is verdwenen; wat daarin stond over de plekken waar de relay een ander geval is, staat nu als ontwerp in het masterplan Umbrelapp §4. Botsende namen kregen een achtervoegsel met de app, en alleen die: Publicatie werd Publicatie-Gate en Publicatie-Relay, CHANGELOG.md werd CHANGELOG-electrum-gate.md. Proefopstelling kreeg 007, tussen de twee bestaande nummers, zodat de bovenkant van de reeks op tier-orde blijft staan. CONTINUE_HERE.md heeft een kolom App, maar de tiers lopen over beide apps heen: er is één volgorde van werken. Electrum Gate gaat naar 0.0.15, want website, repo, support, submission en icon wijzen nu naar UmbrelApps en zonder versieverhoging rolt dat niet uit. De release notes leggen aan de gebruiker uit dat hij de store opnieuw moet toevoegen. Of een geïnstalleerde app een wisseling van store-URL overleeft is nog steeds niet uitgezocht; dat blijkt bij het omzetten. Twee dingen in de plannen van Electrum Gate waren door deze verhuizing niet meer waar en zijn bijgewerkt: de taak "de repo hernoemen" in fase 7 is afgevinkt, en de repo-vorm in PLAN.md §4a toonde nog de store-id electrumtls, die al sinds fase 7 achterhaald was. Tests: 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |