Release v0.1.9: enforce Photos API boundary and finalize Server migration
This commit is contained in:
渡口浪人
@@ -0,0 +1,19 @@
|
||||
# v0.1.9
|
||||
|
||||
照片来源通过 Synology Photos API 按账号权限读取，共享/个人空间、人物 any/all 筛选和有界 XL 预览缓存可用。生产拒绝文件系统照片来源及 /photos 挂载；本地上传、生成图片和 Server 本地图库继续保留。NAS 原图下载接口曾被拒绝，本版不宣称支持原图下载。
|
||||
|
||||
自动化新增 1～10080 分钟的真实间隔，跨整点与跨天不按 Cron 字段重置，既有 Cron 任务保持原样。显示时长明确为到期恢复期限。统一来源快捷创建任务编辑器，改善登录及来源表单响应式布局、设备显示名与历史记录中英文；诊断详情保留原始标识。
|
||||
|
||||
## 生产部署
|
||||
|
||||
生产已迁至 Ubuntu Server，由 systemd 管理 Docker；业务、Docker 数据和恢复资料位于 T7，并有 UUID 与挂载依赖保护。NAS 旧 Frame 专属资源已清理且独立复核 PASS。CI 保留隔离验证，移除 NAS 自动生产部署任务，不再向 NAS 发布。
|
||||
|
||||
正式发布使用 scripts/server-release.py：仅在既有 Ubuntu Server 环境运行，从已提交源码包构建，校验依赖锁、源码哈希、T7 UUID、容器安全约束和真实写入设置；备份 SQLite、配置及 Compose 后切换镜像，失败恢复旧 Compose，不自动回写旧数据库。它不执行上传、显示、删除或恢复图片等设备操作。成功后记录正式提交号、保存源码包及审计回执，删除本次暂存目录；白名单内的 Frame 旧迁移输入归档到本次 recovery，清除无恢复引用的临时镜像别名，共享 Console 资料不动。旧镜像及历史恢复资料保留供回滚，不执行全局 prune。
|
||||
|
||||
脚本要求由 git archive 生成的源码放在 /srv/pigway/migration-inbox 的独立子目录；目录内同时提供 RELEASE_COMMIT、RELEASE_HASHES.json 和原始 source.tar.gz。哈希清单涵盖源码与源码包，不含自身。执行 sudo python3 <暂存目录>/scripts/server-release.py；成功后读取 /srv/pigway/apps/pigway-frame-flow/release-verification.json 并独立检查线上接口。
|
||||
|
||||
## 验收范围
|
||||
|
||||
完整后端测试、静态检查与桌面/平板/手机的中英文浏览器回归纳入发布检查。线上历史补丁已核验，真实写入保持开启；本轮正式发布不重复真实设备写入测试。隔离浏览器验证与真实设备写入证据分别记录于 docs/verification/2026-10-17-final-audit.md。
|
||||
|
||||
局域网 HTTPS、独立加密备份及恢复演练仍是后续工作；T7 recovery 不属于独立备份。没有执行 USB 断连、服务器重启或压力测试。
|
||||
@@ -0,0 +1,84 @@
|
||||
# KoKonna local-control investigation
|
||||
|
||||
Reviewed 2026-10-06. No frame writes, network changes, or firmware changes.
|
||||
|
||||
## Sources and limits
|
||||
|
||||
- Official FAQ: https://kokonna.art/pages/faq explicitly describes Bluetooth
|
||||
upload and switching. This is a product-level claim, not verified B101 behavior.
|
||||
- Public OpenAPI: https://kokonna.art/pages/openapi documents cloud HTTPS calls.
|
||||
- Existing official Android nightly 1.6.5 APK from the prior download:
|
||||
SHA256 `8f611bf74bbda70e7e7a5d087e4065dc6000849dcd2f12538d5ff5017c91e1c0`.
|
||||
Static inspection of its packaged app-service.js; no vendor code is copied here.
|
||||
- Searches found community API clients, but no verified B101 firmware source or
|
||||
documented bring-your-own-server configuration. Absence from search is not
|
||||
proof that firmware source or another configuration path does not exist.
|
||||
|
||||
## Observed client behavior
|
||||
|
||||
The account client uses `https://robot.galaxyguide.cn/api/rpc`. Its Bluetooth
|
||||
upload flow calls `appFrame.uploadImage` with base64 and `synced: true`, receives
|
||||
an image ID, downloads the resulting image from the vendor server, and sends
|
||||
the bytes to the frame over BLE. Therefore this observed flow still exposes
|
||||
the original image to the vendor cloud.
|
||||
|
||||
BLE service UUID: `4fafc201-1fb5-459e-8fcc-c5c9c331914b`.
|
||||
Characteristic UUID: `beb5483e-36e1-4688-b7f5-ea07361b26a7`.
|
||||
|
||||
Observed JSON commands include `get_info`, `refresh_image`, and `set_image`.
|
||||
Image transfer uses start metadata (ID, rotation, type, size, chunk count),
|
||||
numbered binary chunks, sync acknowledgements/missing-chunk information, and
|
||||
an end command. The client chooses `y4` for firmware starting with B103 and
|
||||
`jpg` otherwise. That makes local JPEG transmission a plausible B101 research
|
||||
path, not a proven implementation: cloud-independent IDs, processing, firmware
|
||||
acceptance, pairing and completion semantics still require validation.
|
||||
|
||||
The observed `set_config` payload contains `slideType`, `slideMinute`, and
|
||||
`nickname`; `set_wifi` contains SSID and password. No server-host setter was
|
||||
found in these paths or common host-setting symbol searches.
|
||||
|
||||
## Host replacement assessment
|
||||
|
||||
Changing Frame Flow's API base URL changes where Frame Flow sends requests,
|
||||
not where the frame connects. Replacing the frame's cloud server requires its
|
||||
device-side protocol and a supported address-setting mechanism or firmware
|
||||
change. DNS redirection alone may fail HTTPS certificate validation and still
|
||||
requires a compatible server implementation. TLS/pinning and actual device
|
||||
polling transport have not been established from this APK.
|
||||
|
||||
Next read-only step: inspect BLE `get_info` and installed firmware compatibility.
|
||||
Any subsequent local image write needs a separate controlled test. No BLE driver
|
||||
is enabled by this investigation.
|
||||
|
||||
## Wi-Fi-only follow-up
|
||||
|
||||
The user excluded Bluetooth and additional gateways. The target is NAS-to-frame
|
||||
Wi-Fi control with the original hardware.
|
||||
|
||||
GitHub's public repository search for `kokonna` returned three repositories:
|
||||
`patrickchen914/kokonna`, `nixihz/kokonna-skill`, and
|
||||
`zhengweiran66-eng/kokonna-product.html`. These provide a Home Assistant cloud
|
||||
integration, an OpenAPI CLI, and a product page, respectively; no verified B101
|
||||
device firmware or Wi-Fi local-server implementation was identified.
|
||||
|
||||
Static APK checks found no hard-coded private IPv4 target, WebSocket URL,
|
||||
custom image-URL setter, or common server-host setter symbols in app-service.js.
|
||||
This does not exclude hidden firmware features or native-library code paths.
|
||||
`app.getFirmwares` is called with `robotId`. Upgrade submission passes a firmware
|
||||
name, locale and distributor ID through `app.setUpgradeFirmware`; the inspected
|
||||
UI does not supply a user-selected firmware download URL. Neither method was
|
||||
called during this investigation. Existing account RPC allowlists remain intact.
|
||||
|
||||
Candidate paths, none yet verified:
|
||||
|
||||
1. A device-local HTTP/TCP service: requires a confirmed frame LAN address and
|
||||
bounded service inspection while the frame is awake.
|
||||
2. A firmware-supported custom server or image URL: requires configuration or
|
||||
firmware evidence, not simply replacing the application's API host.
|
||||
3. A NAS implementation of the device's cloud protocol: requires the actual
|
||||
polling/download protocol and address/TLS behavior. Passive observation at
|
||||
the existing gateway may provide evidence; a normal NAS on a switched LAN
|
||||
cannot assume it sees another device's outbound packets.
|
||||
|
||||
No DNS redirection, router interception, certificate replacement, firmware
|
||||
upgrade, reset, or automatic display change was performed.
|
||||
Reference in New Issue
Block a user