Compare commits
4
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 archipelagoandClaude Opus 5
|
4e455167e9 | ||
|
archipelago
|
cd58242935 | ||
|
archipelagoandClaude Opus 5
|
9d225473b1 | ||
|
archipelagoandClaude Opus 5
|
e20d7a14fb |
@@ -443,6 +443,70 @@ below is dead on every path. Pre-existing; spotted in the v1.7.120 build warning
|
||||
|
||||
---
|
||||
|
||||
## STATUS 2026-08-04 — what shipped in 1.7.121 and what did not
|
||||
|
||||
### Shipped (committed + pushed)
|
||||
|
||||
| Item | Commit | Verified |
|
||||
|---|---|---|
|
||||
| 3. Federation trust escalation | `c0cfc72a` | 42/42 federation tests |
|
||||
| 3b. Trusted requires node password | `24ce8b39` | 44/44 + 79/79 + vue-tsc |
|
||||
| 4. lnd-ui OTA pin + host networking | `5088aef5` | — |
|
||||
| 1b. Manifest `auth:` declarations | `0c4826f8` | 73/73, all 56 manifests parse |
|
||||
| 1c. App gate (engine + audit) | `0de67ca6` | 23/23 appgate |
|
||||
| Dashboard backdrop-filter seam | `63d0183d` | 3/3, **live on archi-dev-box** |
|
||||
| 7. Release refuses unsigned manifest | `cc9e1958` | dry-run: signed/stripped/wrong-signer |
|
||||
| Gate safety model (`Option<PortAuth>`) | `ab2c8b6e` | 75/75 incl. LND wallet-port case |
|
||||
| Companion rebuild-loop | `719446c0` | podman behaviour proven first |
|
||||
| 5. Federated peers messageable | `edc9a172` | predicate pinned across device types |
|
||||
|
||||
### The two gate incidents — read before touching the gate again
|
||||
|
||||
Both were ONE mistake: a safety decision read an ABSENT manifest field as a
|
||||
value. A node's installed manifests always lag the binary, so "absent" is the
|
||||
normal state, and the daemon acted on instructions no manifest ever gave.
|
||||
|
||||
1. Gating any `session` port regardless of `bind` **published Bitcoin's
|
||||
loopback-only RPC 8332 on the LAN/Tailscale/IPv6** within seconds of deploy.
|
||||
2. The `bind`-keyed replacement looked safe (it protected `bind: 127.0.0.1`)
|
||||
but LND's gRPC 10009 / REST 18080 carry an EMPTY bind — one container
|
||||
recreate from pinning them to loopback and **breaking Zeus and every remote
|
||||
wallet**.
|
||||
|
||||
Now structural: `auth_policy()` classifies (undeclared → reported as
|
||||
unprotected, always safe), `auth_is_declared()` gates action (undeclared →
|
||||
never acted on). **Silence is not consent.**
|
||||
|
||||
### Proven on the node, empirically, not by reasoning
|
||||
|
||||
- Gate challenge → login → proxy works end to end over LAN and Tailscale.
|
||||
- **Daemon-side publish rewriting was removed.** Publishes are built in several
|
||||
places (`podman_client`, `package::install`, `stacks`); patching one covered
|
||||
one — the strfry recreate went through another and the pin never fired.
|
||||
- **Disk manifest edits do not apply to catalog-covered apps.** Even
|
||||
`bind: 127.0.0.1` written into the node's strfry manifest was overridden by
|
||||
the signed catalog. The catalog re-sign is REQUIRED; there is no shortcut.
|
||||
- A loopback-bound host port is **unreachable** from a pasta container, so
|
||||
loopback-pinning the Wyoming ports would break Home Assistant voice.
|
||||
|
||||
### Open for 1.7.122
|
||||
|
||||
1. **Catalog re-sign** — `bind: 127.0.0.1` + `auth: session` on the ~39 gated
|
||||
UI ports. This is what turns the gate from auditing into enforcing. Nothing
|
||||
in code can substitute for it.
|
||||
2. **Release-root rotation** — branch `rotate-release-root`, key
|
||||
`did:key:z6Mkfu5LT…DLWT` / `1578adcc…4418`, validated as a real curve point.
|
||||
**Sign the rotation release with the OLD key**; only the release after it
|
||||
uses the new one. Re-sign the catalog too.
|
||||
3. **Wyoming voice ports** (10200/10300/10400) — unauthenticated, and by the
|
||||
operator's policy they should not be. Correct fix is co-locating Home
|
||||
Assistant with the pine services on one container network so nothing is
|
||||
published; needs a node running both.
|
||||
4. **Item 2** filebrowser default login. **Items 6/6b** app updates +
|
||||
multiversion (`versions[]` already exists, populated for 2 of 66 apps).
|
||||
5. **`cargo-test-weekly` times out** at its 1500s cap on a loaded box — raise
|
||||
the cap or split the stage; it is not a code failure.
|
||||
|
||||
## RESUME HERE — next session
|
||||
|
||||
**Landed this session (both pushed):**
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[package]
|
||||
name = "archipelago"
|
||||
version = "1.7.120-alpha"
|
||||
version = "1.7.121-alpha"
|
||||
edition = "2021"
|
||||
description = "Archipelago Bitcoin Node OS - Native backend"
|
||||
authors = ["Archipelago Team"]
|
||||
|
||||
Generated
+2
-2
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "neode-ui",
|
||||
"version": "1.7.120-alpha",
|
||||
"version": "1.7.121-alpha",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "neode-ui",
|
||||
"version": "1.7.120-alpha",
|
||||
"version": "1.7.121-alpha",
|
||||
"dependencies": {
|
||||
"@scure/bip39": "^2.2.0",
|
||||
"@types/dompurify": "^3.0.5",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "neode-ui",
|
||||
"private": true,
|
||||
"version": "1.7.120-alpha",
|
||||
"version": "1.7.121-alpha",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"start": "./start-dev.sh",
|
||||
|
||||
@@ -362,6 +362,23 @@ init()
|
||||
</button>
|
||||
</div>
|
||||
<div class="overflow-y-auto flex-1 min-h-0 space-y-6 pr-1">
|
||||
<!-- v1.7.121-alpha -->
|
||||
<div>
|
||||
<div class="flex items-center gap-2 mb-3">
|
||||
<span class="text-xs font-mono px-2 py-0.5 rounded bg-orange-500/20 text-orange-300">v1.7.121-alpha</span>
|
||||
<span class="text-xs text-white/40">August 4, 2026</span>
|
||||
</div>
|
||||
<div class="space-y-3 text-sm text-white/80 pl-3 border-l border-white/10">
|
||||
<p>**Making another node "Trusted" now asks for your node password.** Trust was being handed out by machines rather than by you: any node able to reach yours could join and mark itself Trusted, because the check proved only that the caller owned the key it had just presented — never that you had approved it. Trust also spread on its own, since every peer a Trusted node advertised was added as Trusted too, so one grant quietly propagated across the whole federation. Uninvited joins are now capped at Observer, advertised peers arrive as Observers, and raising anyone to Trusted — whether by generating an invite or by changing the dropdown on a node — requires your password. Lowering trust deliberately does not, because the safe action must never be the inconvenient one. Existing peers are left exactly as they are rather than silently demoted, and each one now records how its trust was granted so you can review them.</p>
|
||||
<p>**Nodes you have peered with can be messaged straight away.** Peering was not enough: you also had to be within LoRa radio range of the other node once before chat would work. The node picked how to send a message based on which radio was plugged in, and only one of those paths knew how to reach a peer over the mesh's internet transports — so on a node with a different radio, or no radio at all, messaging a peer you had just federated with simply failed until a radio contact happened to appear. Peered nodes are reachable without radio by definition, so that choice no longer depends on the hardware. Radio is still preferred when the other node is actually in range and the message fits.</p>
|
||||
<p>The dashboard no longer flickers a vertical line across its cards. A rendering seam appeared at random while moving the mouse, because the two large cards used a background-blur effect that this system already disables everywhere else on the dashboard — that browser mis-draws it inside the dashboard's animated container, and these two cards had been missed when the workaround was written. Diagnosed from a single screenshot rather than by trying to reproduce it.</p>
|
||||
<p>The Lightning screen will actually update from now on. Its image was set to "latest", and the container system will not re-fetch a label it already holds, so nodes kept the same Lightning screen forever no matter how many updates shipped. A separate copy of the same setting used only by brand-new installs also described the screen incorrectly, so fresh installs got a screen that never answered.</p>
|
||||
<p>Apps that provide their own screens stop rebuilding themselves in a loop. On this system's own node one of them rebuilt every thirty-five seconds indefinitely, burning processor time and restarting the app each round. The node decided a rebuild was needed by comparing file dates against the image's creation date, but a rebuild that changes nothing reuses the existing image and leaves that date untouched — so the condition that triggered the rebuild was still true afterwards, forever. Nodes taking this update repair themselves the first time they check.</p>
|
||||
<p>Groundwork you can see but that does not change access yet: the node can now tell you which of its app ports answer without a login, and every port that is deliberately open — Bitcoin's peer connections for syncing the chain, Lightning's wallet connections, the Electrum wallet protocol — now has to state in writing why it is safe, so the list of exceptions is something you can read rather than something you have to discover. The login gate that will sit in front of the rest is built and proven working end to end on a real node, but it is not yet closing any ports; that arrives with the signed app catalog that tells each app to hand its address over.</p>
|
||||
<p>Releases can no longer ship an unsigned update file. Signing was skippable, and when it was skipped the release was still committed and tagged — producing an update that every node correctly refuses to install. It had been caught by hand every cycle; now the release simply stops.</p>
|
||||
<p>Known gaps, disclosed rather than buried: the 5x real-node lifecycle gate was not run for this release. App ports other than the deliberate exceptions above are still reachable without a login — the gate reports them, and closing them needs the next signed catalog. Three voice-assistant ports are open without authentication and should not be; the correct fix puts them on a private network with the assistant instead, which needs testing on a node that runs both. Two nodes on the fleet still share SSH host keys (detection shipped, rotation remains a deliberate operator decision).</p>
|
||||
</div>
|
||||
</div>
|
||||
<!-- v1.7.120-alpha -->
|
||||
<div>
|
||||
<div class="flex items-center gap-2 mb-3">
|
||||
|
||||
+22
-24
@@ -1,36 +1,34 @@
|
||||
{
|
||||
"changelog": [
|
||||
"**Security, and the reason to take this update: two ports on your node handed anyone who could reach them complete control of your money, with no password.** The Lightning app's port answered a plain web request with the LND admin macaroon, the TLS certificate and the node's onion address — everything needed to drain the wallet remotely, and the onion meant an attacker kept that ability even after losing access to your network. The Bitcoin app's port reached Bitcoin Core's control interface using credentials the node itself supplied on the caller's behalf, with a wallet loaded. Anything on your home network, your Tailscale network or the mesh could use either one. Both now require you to be logged in. If your node has been reachable by anyone you do not fully trust, treat the Lightning macaroon and the Bitcoin RPC password as known to them.",
|
||||
"The Bitcoin and Lightning app screens can no longer be published as public Tor addresses automatically. They were one app-id away from being handed a worldwide, permanent address as a silent side effect of being installed — which would have re-opened the hole above to the entire internet. Turning Tor on for them deliberately still works; it just never happens on its own.",
|
||||
"**Fixes shipped inside the program now actually reach apps that your system keeps running.** A container the node had been told to uninstall, but that the system service manager kept alive anyway, was quietly skipped by the part of the node that applies configuration — so it never received updates that shipped with the program. This was found the hard way: the Bitcoin control-interface fix above appeared to be installed and silently was not, while the Lightning half applied correctly, which is the most misleading way for a security fix to fail. Both halves are now proven to land on a real node.",
|
||||
"The Lightning and Bitcoin node screens have been rebuilt to match what umbrelOS offers. Lightning gains Overview, Channels, Activity, Insights, Connect and Settings tabs with a sats/BTC switch; Bitcoin gains Insights, Peers, Connect and Sharing. Along the way: every copy button on those screens silently did nothing (the browser blocks clipboard access inside an embedded page) and now works; the channels link led to a dead page; and Node ID showed a bare key instead of the full address someone can actually connect to.",
|
||||
"Updates to the Bitcoin screen show up without a hard refresh. The page was being cached by the browser, so a freshly updated screen kept rendering the previous one.",
|
||||
"The AI sidebar loads again. It was asking for its program files at an address that pointed at the main app's files, where they do not exist, so it silently loaded nothing.",
|
||||
"The navigation above the bottom bar no longer follows you between screens. Back buttons and the mesh tab bar stayed pinned over every other page once you had visited the screen that owns them. Keeping tabs loaded in the background — the change that made switching between them instant — means leaving a screen hides it rather than destroying it, and this floating navigation sits outside the screen it belongs to, so it was never being hidden with it. It is now tied to whether its own screen is on display. The speed is unchanged: the screens are still kept loaded, so returning to one is still instant.",
|
||||
"Wallet: Lightning actions are now offered based on whether you actually have a usable channel rather than just a running node, sending is gated the same way, and an invoice you cannot yet receive offers to install a Lightning node instead of simply failing.",
|
||||
"Onboarding and viewing fixes: the \"I have written down my recovery words\" tickbox is findable on short screens, paid pictures and videos open in the app's own viewer with a visible loading state instead of a blank browser tab, picture-in-picture survives changing tabs, and the FIPS/Tor labels on peer cards stay put instead of wrapping into the card below.",
|
||||
"Key-material hardening across the node: a node that is already set up refuses to have its identity replaced by an unauthenticated request; first-boot secret generation now fails loudly instead of silently continuing with shared keys; the node proves its TLS certificate and key are actually a matching pair; the Bitcoin Core wallet path that kept a second copy of your spending key outside the encrypted store has been removed; and every place the node generates a key, token or nonce now names its source of randomness explicitly, enforced at build time."
|
||||
"**Making another node \"Trusted\" now asks for your node password.** Trust was being handed out by machines rather than by you: any node able to reach yours could join and mark itself Trusted, because the check proved only that the caller owned the key it had just presented — never that you had approved it. Trust also spread on its own, since every peer a Trusted node advertised was added as Trusted too, so one grant quietly propagated across the whole federation. Uninvited joins are now capped at Observer, advertised peers arrive as Observers, and raising anyone to Trusted — whether by generating an invite or by changing the dropdown on a node — requires your password. Lowering trust deliberately does not, because the safe action must never be the inconvenient one. Existing peers are left exactly as they are rather than silently demoted, and each one now records how its trust was granted so you can review them.",
|
||||
"**Nodes you have peered with can be messaged straight away.** Peering was not enough: you also had to be within LoRa radio range of the other node once before chat would work. The node picked how to send a message based on which radio was plugged in, and only one of those paths knew how to reach a peer over the mesh's internet transports — so on a node with a different radio, or no radio at all, messaging a peer you had just federated with simply failed until a radio contact happened to appear. Peered nodes are reachable without radio by definition, so that choice no longer depends on the hardware. Radio is still preferred when the other node is actually in range and the message fits.",
|
||||
"The dashboard no longer flickers a vertical line across its cards. A rendering seam appeared at random while moving the mouse, because the two large cards used a background-blur effect that this system already disables everywhere else on the dashboard — that browser mis-draws it inside the dashboard's animated container, and these two cards had been missed when the workaround was written. Diagnosed from a single screenshot rather than by trying to reproduce it.",
|
||||
"The Lightning screen will actually update from now on. Its image was set to \"latest\", and the container system will not re-fetch a label it already holds, so nodes kept the same Lightning screen forever no matter how many updates shipped. A separate copy of the same setting used only by brand-new installs also described the screen incorrectly, so fresh installs got a screen that never answered.",
|
||||
"Apps that provide their own screens stop rebuilding themselves in a loop. On this system's own node one of them rebuilt every thirty-five seconds indefinitely, burning processor time and restarting the app each round. The node decided a rebuild was needed by comparing file dates against the image's creation date, but a rebuild that changes nothing reuses the existing image and leaves that date untouched — so the condition that triggered the rebuild was still true afterwards, forever. Nodes taking this update repair themselves the first time they check.",
|
||||
"Groundwork you can see but that does not change access yet: the node can now tell you which of its app ports answer without a login, and every port that is deliberately open — Bitcoin's peer connections for syncing the chain, Lightning's wallet connections, the Electrum wallet protocol — now has to state in writing why it is safe, so the list of exceptions is something you can read rather than something you have to discover. The login gate that will sit in front of the rest is built and proven working end to end on a real node, but it is not yet closing any ports; that arrives with the signed app catalog that tells each app to hand its address over.",
|
||||
"Releases can no longer ship an unsigned update file. Signing was skippable, and when it was skipped the release was still committed and tagged — producing an update that every node correctly refuses to install. It had been caught by hand every cycle; now the release simply stops.",
|
||||
"Known gaps, disclosed rather than buried: the 5x real-node lifecycle gate was not run for this release. App ports other than the deliberate exceptions above are still reachable without a login — the gate reports them, and closing them needs the next signed catalog. Three voice-assistant ports are open without authentication and should not be; the correct fix puts them on a private network with the assistant instead, which needs testing on a node that runs both. Two nodes on the fleet still share SSH host keys (detection shipped, rotation remains a deliberate operator decision)."
|
||||
],
|
||||
"components": [
|
||||
{
|
||||
"current_version": "1.7.120-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.120-alpha/archipelago",
|
||||
"current_version": "1.7.121-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.121-alpha/archipelago",
|
||||
"name": "archipelago",
|
||||
"new_version": "1.7.120-alpha",
|
||||
"sha256": "304255655a22bae605d728d44e857ed170a19833b6237861fdf7d852d25d9680",
|
||||
"size_bytes": 54017008
|
||||
"new_version": "1.7.121-alpha",
|
||||
"sha256": "be5ef9fb284f539b06329d4108be53e55ae8cdb06cf1cf4beb90363de364706d",
|
||||
"size_bytes": 54870968
|
||||
},
|
||||
{
|
||||
"current_version": "1.7.120-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.120-alpha/archipelago-frontend-1.7.120-alpha.tar.gz",
|
||||
"name": "archipelago-frontend-1.7.120-alpha.tar.gz",
|
||||
"new_version": "1.7.120-alpha",
|
||||
"sha256": "cb9ea4dfcea3ac93dfb1ce1dca96ea30c74a4e6354471cde4d8f75c0441850a5",
|
||||
"size_bytes": 210519311
|
||||
"current_version": "1.7.121-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.121-alpha/archipelago-frontend-1.7.121-alpha.tar.gz",
|
||||
"name": "archipelago-frontend-1.7.121-alpha.tar.gz",
|
||||
"new_version": "1.7.121-alpha",
|
||||
"sha256": "7898a9c11fa30cadc8f0fcf814bba1e3870d20663472f4c40e8e663b2359958f",
|
||||
"size_bytes": 210526689
|
||||
}
|
||||
],
|
||||
"release_date": "2026-08-03",
|
||||
"signature": "e76e0ca5f249111a0a57df07f790997b1a4facf97da11a2d13fcb7ec9b80aea82925244d6083544504260b776ca4317cf44774e2c37bfaa13afae248e9675601",
|
||||
"release_date": "2026-08-04",
|
||||
"signature": "9d871c946e941b3c13f75fb799d8428841147267f4565920993ddd3aa0cd52d6d1a74481303cbbb26e68e6e5d44e2b711c9b7a22ad7dd73c94b4d3e39a0e2803",
|
||||
"signed_by": "did:key:z6MkkidEnEpo6qHMCNSZoNKWtvQvxq3whnaME9wGgEFhq7ur",
|
||||
"version": "1.7.120-alpha"
|
||||
"version": "1.7.121-alpha"
|
||||
}
|
||||
|
||||
+22
-24
@@ -1,36 +1,34 @@
|
||||
{
|
||||
"changelog": [
|
||||
"**Security, and the reason to take this update: two ports on your node handed anyone who could reach them complete control of your money, with no password.** The Lightning app's port answered a plain web request with the LND admin macaroon, the TLS certificate and the node's onion address — everything needed to drain the wallet remotely, and the onion meant an attacker kept that ability even after losing access to your network. The Bitcoin app's port reached Bitcoin Core's control interface using credentials the node itself supplied on the caller's behalf, with a wallet loaded. Anything on your home network, your Tailscale network or the mesh could use either one. Both now require you to be logged in. If your node has been reachable by anyone you do not fully trust, treat the Lightning macaroon and the Bitcoin RPC password as known to them.",
|
||||
"The Bitcoin and Lightning app screens can no longer be published as public Tor addresses automatically. They were one app-id away from being handed a worldwide, permanent address as a silent side effect of being installed — which would have re-opened the hole above to the entire internet. Turning Tor on for them deliberately still works; it just never happens on its own.",
|
||||
"**Fixes shipped inside the program now actually reach apps that your system keeps running.** A container the node had been told to uninstall, but that the system service manager kept alive anyway, was quietly skipped by the part of the node that applies configuration — so it never received updates that shipped with the program. This was found the hard way: the Bitcoin control-interface fix above appeared to be installed and silently was not, while the Lightning half applied correctly, which is the most misleading way for a security fix to fail. Both halves are now proven to land on a real node.",
|
||||
"The Lightning and Bitcoin node screens have been rebuilt to match what umbrelOS offers. Lightning gains Overview, Channels, Activity, Insights, Connect and Settings tabs with a sats/BTC switch; Bitcoin gains Insights, Peers, Connect and Sharing. Along the way: every copy button on those screens silently did nothing (the browser blocks clipboard access inside an embedded page) and now works; the channels link led to a dead page; and Node ID showed a bare key instead of the full address someone can actually connect to.",
|
||||
"Updates to the Bitcoin screen show up without a hard refresh. The page was being cached by the browser, so a freshly updated screen kept rendering the previous one.",
|
||||
"The AI sidebar loads again. It was asking for its program files at an address that pointed at the main app's files, where they do not exist, so it silently loaded nothing.",
|
||||
"The navigation above the bottom bar no longer follows you between screens. Back buttons and the mesh tab bar stayed pinned over every other page once you had visited the screen that owns them. Keeping tabs loaded in the background — the change that made switching between them instant — means leaving a screen hides it rather than destroying it, and this floating navigation sits outside the screen it belongs to, so it was never being hidden with it. It is now tied to whether its own screen is on display. The speed is unchanged: the screens are still kept loaded, so returning to one is still instant.",
|
||||
"Wallet: Lightning actions are now offered based on whether you actually have a usable channel rather than just a running node, sending is gated the same way, and an invoice you cannot yet receive offers to install a Lightning node instead of simply failing.",
|
||||
"Onboarding and viewing fixes: the \"I have written down my recovery words\" tickbox is findable on short screens, paid pictures and videos open in the app's own viewer with a visible loading state instead of a blank browser tab, picture-in-picture survives changing tabs, and the FIPS/Tor labels on peer cards stay put instead of wrapping into the card below.",
|
||||
"Key-material hardening across the node: a node that is already set up refuses to have its identity replaced by an unauthenticated request; first-boot secret generation now fails loudly instead of silently continuing with shared keys; the node proves its TLS certificate and key are actually a matching pair; the Bitcoin Core wallet path that kept a second copy of your spending key outside the encrypted store has been removed; and every place the node generates a key, token or nonce now names its source of randomness explicitly, enforced at build time."
|
||||
"**Making another node \"Trusted\" now asks for your node password.** Trust was being handed out by machines rather than by you: any node able to reach yours could join and mark itself Trusted, because the check proved only that the caller owned the key it had just presented — never that you had approved it. Trust also spread on its own, since every peer a Trusted node advertised was added as Trusted too, so one grant quietly propagated across the whole federation. Uninvited joins are now capped at Observer, advertised peers arrive as Observers, and raising anyone to Trusted — whether by generating an invite or by changing the dropdown on a node — requires your password. Lowering trust deliberately does not, because the safe action must never be the inconvenient one. Existing peers are left exactly as they are rather than silently demoted, and each one now records how its trust was granted so you can review them.",
|
||||
"**Nodes you have peered with can be messaged straight away.** Peering was not enough: you also had to be within LoRa radio range of the other node once before chat would work. The node picked how to send a message based on which radio was plugged in, and only one of those paths knew how to reach a peer over the mesh's internet transports — so on a node with a different radio, or no radio at all, messaging a peer you had just federated with simply failed until a radio contact happened to appear. Peered nodes are reachable without radio by definition, so that choice no longer depends on the hardware. Radio is still preferred when the other node is actually in range and the message fits.",
|
||||
"The dashboard no longer flickers a vertical line across its cards. A rendering seam appeared at random while moving the mouse, because the two large cards used a background-blur effect that this system already disables everywhere else on the dashboard — that browser mis-draws it inside the dashboard's animated container, and these two cards had been missed when the workaround was written. Diagnosed from a single screenshot rather than by trying to reproduce it.",
|
||||
"The Lightning screen will actually update from now on. Its image was set to \"latest\", and the container system will not re-fetch a label it already holds, so nodes kept the same Lightning screen forever no matter how many updates shipped. A separate copy of the same setting used only by brand-new installs also described the screen incorrectly, so fresh installs got a screen that never answered.",
|
||||
"Apps that provide their own screens stop rebuilding themselves in a loop. On this system's own node one of them rebuilt every thirty-five seconds indefinitely, burning processor time and restarting the app each round. The node decided a rebuild was needed by comparing file dates against the image's creation date, but a rebuild that changes nothing reuses the existing image and leaves that date untouched — so the condition that triggered the rebuild was still true afterwards, forever. Nodes taking this update repair themselves the first time they check.",
|
||||
"Groundwork you can see but that does not change access yet: the node can now tell you which of its app ports answer without a login, and every port that is deliberately open — Bitcoin's peer connections for syncing the chain, Lightning's wallet connections, the Electrum wallet protocol — now has to state in writing why it is safe, so the list of exceptions is something you can read rather than something you have to discover. The login gate that will sit in front of the rest is built and proven working end to end on a real node, but it is not yet closing any ports; that arrives with the signed app catalog that tells each app to hand its address over.",
|
||||
"Releases can no longer ship an unsigned update file. Signing was skippable, and when it was skipped the release was still committed and tagged — producing an update that every node correctly refuses to install. It had been caught by hand every cycle; now the release simply stops.",
|
||||
"Known gaps, disclosed rather than buried: the 5x real-node lifecycle gate was not run for this release. App ports other than the deliberate exceptions above are still reachable without a login — the gate reports them, and closing them needs the next signed catalog. Three voice-assistant ports are open without authentication and should not be; the correct fix puts them on a private network with the assistant instead, which needs testing on a node that runs both. Two nodes on the fleet still share SSH host keys (detection shipped, rotation remains a deliberate operator decision)."
|
||||
],
|
||||
"components": [
|
||||
{
|
||||
"current_version": "1.7.120-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.120-alpha/archipelago",
|
||||
"current_version": "1.7.121-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.121-alpha/archipelago",
|
||||
"name": "archipelago",
|
||||
"new_version": "1.7.120-alpha",
|
||||
"sha256": "304255655a22bae605d728d44e857ed170a19833b6237861fdf7d852d25d9680",
|
||||
"size_bytes": 54017008
|
||||
"new_version": "1.7.121-alpha",
|
||||
"sha256": "be5ef9fb284f539b06329d4108be53e55ae8cdb06cf1cf4beb90363de364706d",
|
||||
"size_bytes": 54870968
|
||||
},
|
||||
{
|
||||
"current_version": "1.7.120-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.120-alpha/archipelago-frontend-1.7.120-alpha.tar.gz",
|
||||
"name": "archipelago-frontend-1.7.120-alpha.tar.gz",
|
||||
"new_version": "1.7.120-alpha",
|
||||
"sha256": "cb9ea4dfcea3ac93dfb1ce1dca96ea30c74a4e6354471cde4d8f75c0441850a5",
|
||||
"size_bytes": 210519311
|
||||
"current_version": "1.7.121-alpha",
|
||||
"download_url": "http://146.59.87.168:3000/lfg2025/archy/releases/download/v1.7.121-alpha/archipelago-frontend-1.7.121-alpha.tar.gz",
|
||||
"name": "archipelago-frontend-1.7.121-alpha.tar.gz",
|
||||
"new_version": "1.7.121-alpha",
|
||||
"sha256": "7898a9c11fa30cadc8f0fcf814bba1e3870d20663472f4c40e8e663b2359958f",
|
||||
"size_bytes": 210526689
|
||||
}
|
||||
],
|
||||
"release_date": "2026-08-03",
|
||||
"signature": "e76e0ca5f249111a0a57df07f790997b1a4facf97da11a2d13fcb7ec9b80aea82925244d6083544504260b776ca4317cf44774e2c37bfaa13afae248e9675601",
|
||||
"release_date": "2026-08-04",
|
||||
"signature": "9d871c946e941b3c13f75fb799d8428841147267f4565920993ddd3aa0cd52d6d1a74481303cbbb26e68e6e5d44e2b711c9b7a22ad7dd73c94b4d3e39a0e2803",
|
||||
"signed_by": "did:key:z6MkkidEnEpo6qHMCNSZoNKWtvQvxq3whnaME9wGgEFhq7ur",
|
||||
"version": "1.7.120-alpha"
|
||||
"version": "1.7.121-alpha"
|
||||
}
|
||||
|
||||
@@ -39,18 +39,25 @@ if [ -x "$PROJECT_ROOT/core/target/release/archipelago" ]; then
|
||||
fi
|
||||
|
||||
remote_url=$(git -C "$PROJECT_ROOT" remote get-url "$REMOTE")
|
||||
# https is accepted as well as http. Requiring http:// meant the only remote
|
||||
# whose credential actually works for git push (the https one) was rejected,
|
||||
# while the http remote it forced you to use had a dead token — so publishing
|
||||
# failed on auth after the manifest had already passed every check
|
||||
# (v1.7.121-alpha, 2026-08-04). The scheme is carried through to the API URL
|
||||
# rather than assumed.
|
||||
case "$remote_url" in
|
||||
http://*@*) ;;
|
||||
*) fail "$REMOTE must be an authenticated http:// Gitea remote URL for API uploads" ;;
|
||||
http://*@*|https://*@*) ;;
|
||||
*) fail "$REMOTE must be an authenticated http(s):// Gitea remote URL for API uploads" ;;
|
||||
esac
|
||||
|
||||
auth=${remote_url#http://}
|
||||
auth=${auth%@*}
|
||||
host_path=${remote_url#http://$auth@}
|
||||
scheme=${remote_url%%://*}
|
||||
rest=${remote_url#*://}
|
||||
auth=${rest%%@*}
|
||||
host_path=${rest#*@}
|
||||
host=${host_path%%/*}
|
||||
repo_path=${host_path#*/}
|
||||
repo_path=${repo_path%.git}
|
||||
api="http://$host/api/v1/repos/$repo_path"
|
||||
api="$scheme://$host/api/v1/repos/$repo_path"
|
||||
release_url="$api/releases/tags/v${VERSION}"
|
||||
|
||||
echo "Pushing main and v${VERSION} to $REMOTE..."
|
||||
|
||||
Reference in New Issue
Block a user