Location:embedded/web/package.json:3 (checked-in 0.20.1-lotus.2, unpublished); /root/code/cinny/package.json:81 pins @lotusguild/element-call-embedded devDependency... (see below) — actually pinned in cinny's own deps block at "@lotusguild/element-call-embedded": "0.20.1-lotus.1"; .gitea/workflows/ci.yml:99-104 (npm version "$TAG" derives the published version solely from GITHUB_REF_NAME, i.e. the pushed git tag)
Problem
The publish workflow makes the git tag the sole source of truth for the published version (comment at ci.yml:12-14 even says so explicitly), but git tag | grep -i lotus on this checkout returns nolotus-scoped tags at all — not v0.20.1-lotus.1 (what cinny currently consumes) nor v0.20.1-lotus.2 (what embedded/web/package.json currently declares as the next version). If the tag that produced the published 0.20.1-lotus.1 artifact was deleted, never pushed to this remote, or only exists on the Gitea mirror, there is no way for anyone auditing this checkout to reconstruct which commit cinny's dependents are actually running. Fork HEAD (lotus @ e36aef8a, "in-call mobile UI fixes wave-2") is 5 commits ahead of the last "prep 0.20.1-lotus.2" commit (d71d8d67), all unpublished per LOTUS_TODO P6-2, so there is also live drift: HEAD has set_deafen, wave-1 EC1-EC6 fixes, and wave-2 mobile fixes that neither the published lotus.1 nor even the staged lotus.2 package.json bump necessarily reflects in a taggable way.
How to trigger
Try to answer "what commit is cinny's 0.20.1-lotus.1 embed built from?" using only this repo's tags — there is nothing to resolve it to.
Suggested fix
Push (and never delete) an annotated vX.Y.Z-lotus.N tag for every version that is actually npm published, and consider stamping the build with the git SHA (not just the tag name) via VITE_APP_VERSION or a separate VITE_APP_COMMIT so the About/DeveloperSettings/rageshake output can disambiguate even if a tag is later moved or lost.
Filed from the September 2026 audit (branch lotus).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `embedded/web/package.json:3` (checked-in `0.20.1-lotus.2`, unpublished); `/root/code/cinny/package.json:81` pins `@lotusguild/element-call-embedded` devDependency... (see below) — actually pinned in cinny's own deps block at `"@lotusguild/element-call-embedded": "0.20.1-lotus.1"`; `.gitea/workflows/ci.yml:99-104` (`npm version "$TAG"` derives the published version solely from `GITHUB_REF_NAME`, i.e. the pushed git tag)
### Problem
The publish workflow makes the git tag the sole source of truth for the published version (comment at `ci.yml:12-14` even says so explicitly), but `git tag | grep -i lotus` on this checkout returns **no** `lotus`-scoped tags at all — not `v0.20.1-lotus.1` (what cinny currently consumes) nor `v0.20.1-lotus.2` (what `embedded/web/package.json` currently declares as the next version). If the tag that produced the published `0.20.1-lotus.1` artifact was deleted, never pushed to this remote, or only exists on the Gitea mirror, there is no way for anyone auditing this checkout to reconstruct which commit cinny's dependents are actually running. Fork HEAD (`lotus` @ `e36aef8a`, "in-call mobile UI fixes wave-2") is 5 commits ahead of the last "prep 0.20.1-lotus.2" commit (`d71d8d67`), all unpublished per LOTUS_TODO P6-2, so there is also live drift: HEAD has `set_deafen`, wave-1 EC1-EC6 fixes, and wave-2 mobile fixes that neither the published `lotus.1` nor even the staged `lotus.2` package.json bump necessarily reflects in a taggable way.
### How to trigger
Try to answer "what commit is cinny's `0.20.1-lotus.1` embed built from?" using only this repo's tags — there is nothing to resolve it to.
### Suggested fix
Push (and never delete) an annotated `vX.Y.Z-lotus.N` tag for every version that is actually `npm publish`ed, and consider stamping the build with the git SHA (not just the tag name) via `VITE_APP_VERSION` or a separate `VITE_APP_COMMIT` so the About/DeveloperSettings/rageshake output can disambiguate even if a tag is later moved or lost.
---
_Filed from the September 2026 audit (branch `lotus`)._
jared
added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:09 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: bug · Confidence: high
Location:
embedded/web/package.json:3(checked-in0.20.1-lotus.2, unpublished);/root/code/cinny/package.json:81pins@lotusguild/element-call-embeddeddevDependency... (see below) — actually pinned in cinny's own deps block at"@lotusguild/element-call-embedded": "0.20.1-lotus.1";.gitea/workflows/ci.yml:99-104(npm version "$TAG"derives the published version solely fromGITHUB_REF_NAME, i.e. the pushed git tag)Problem
The publish workflow makes the git tag the sole source of truth for the published version (comment at
ci.yml:12-14even says so explicitly), butgit tag | grep -i lotuson this checkout returns nolotus-scoped tags at all — notv0.20.1-lotus.1(what cinny currently consumes) norv0.20.1-lotus.2(whatembedded/web/package.jsoncurrently declares as the next version). If the tag that produced the published0.20.1-lotus.1artifact was deleted, never pushed to this remote, or only exists on the Gitea mirror, there is no way for anyone auditing this checkout to reconstruct which commit cinny's dependents are actually running. Fork HEAD (lotus@e36aef8a, "in-call mobile UI fixes wave-2") is 5 commits ahead of the last "prep 0.20.1-lotus.2" commit (d71d8d67), all unpublished per LOTUS_TODO P6-2, so there is also live drift: HEAD hasset_deafen, wave-1 EC1-EC6 fixes, and wave-2 mobile fixes that neither the publishedlotus.1nor even the stagedlotus.2package.json bump necessarily reflects in a taggable way.How to trigger
Try to answer "what commit is cinny's
0.20.1-lotus.1embed built from?" using only this repo's tags — there is nothing to resolve it to.Suggested fix
Push (and never delete) an annotated
vX.Y.Z-lotus.Ntag for every version that is actuallynpm published, and consider stamping the build with the git SHA (not just the tag name) viaVITE_APP_VERSIONor a separateVITE_APP_COMMITso the About/DeveloperSettings/rageshake output can disambiguate even if a tag is later moved or lost.Filed from the September 2026 audit (branch
lotus).Fixed in
872b8772, shipped in0.25.0-lotus.1(published by CI from tag v0.25.0-lotus.1) and consumed by cinny at 9a85a487.