Read 2026-10-23
tinode/chat: technical due diligence, read from its repository
What Borehole read in tinode/chat's code and history at eb90ef8: its licence, security advisories, releases, review practice, tests, dependencies and operations. Every finding cites the file and line it rests on. The full report also covers the team and asks the questions the code cannot answer.
| Dimension | Rating |
|---|---|
| Architecture & Codebase — including AI provenance | strong |
| Engineering Process & SDLC Maturity | strong |
| Product & Engineering Maturity | strong |
| Security & Reliability Posture | adequate |
| Observability & Operations | adequate |
| Fit with the Acquirer | not assessable |
What the repository says
- Releases are cut from another branch than the one surveyed
LICENSE: Relicensed: AGPL-3.0 → GPL-3.0 (2017-11-09)
Architecture & Codebase — including AI provenance
strongserver/topic.go is 4,153 lines, 18× this codebase's median file
adequateThe median source file here is 219 lines. 5 files exceed 2,190 lines, the largest being 4,153. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.
server/topic.go:1 — 4,153 lines (18× median) |
server/db/postgres/adapter.go:1 — 3,719 lines (16× median) |
server/db/mysql/adapter.go:1 — 3,679 lines (16× median) |
server/db/mongodb/adapter.go:1 — 3,160 lines (14× median) |
server/db/rethinkdb/adapter.go:1 — 3,110 lines (14× median) |
Engineering Process & SDLC Maturity
strongAlmost no process scaffolding exists in the repository
adequateOf five ordinary markers — CI workflows, CODEOWNERS, a pull-request template, pre-commit hooks, contribution guidance — 1 is present: contribution guidance. Branch protection itself is a GitHub setting rather than a file, so this is a reading of proxies and not of the rules themselves. What it does establish is that the process is not written down anywhere a new engineer would find it.
| 1 of 5 markers present across 264 tracked files |
Product & Engineering Maturity
strongReleases are cut from another branch than the one surveyed
adequateThe newest pre-release, v0.26.0-alpha2, is not on the branch this survey read; the newest release on it is v0.25.3. The shipped product may differ from what this report describes. Survey the release branch too.
| tag v0.26.0-alpha2 |
Security & Reliability Posture
adequate2 credential-shaped strings committed to the tree
adequateMatches for Google API key appear in tracked files outside test and fixture paths. They stay in the history even after they leave the tree, so what matters is whether each was rotated. The code cannot tell whether any of them is live, and that decides whether this matters: none sits in production configuration, and none is in a format its provider keeps for live keys. Is any of these live? Show that each was rotated after it was committed, and when. Only Google API keys matched. Those are often public by design, in a browser app's Firebase or Maps configuration; the question is whether each is restricted to the app's domains and APIs.
| 2 cited: Google API key pattern matched |
12 dependencies float, and no lockfile is committed
adequateDependency versions are declared as ranges and no lockfile is committed, so a build today does not necessarily produce what a build last month produced. That matters twice over in a transaction: the thing being bought cannot be reproduced exactly, and a compromised upstream release arrives without anyone choosing to take it.
chatbot/python/requirements.txt:1 — >=3.2.0 |
chatbot/python/requirements.txt:2 — >=1.40.0 |
chatbot/python/requirements.txt:3 — >=0.20.0b3 |
chatbot/python/requirements.txt:4 — >=1.0 |
rest-auth/requirements.txt:1 — >=1.1.0 |
3 Dockerfiles run the application as root
adequateNo USER instruction switches away from root, so the process runs with full privileges inside the container. It is a one-line fix and an ordinary expectation, which is why its absence is worth asking about: it usually says more about whether anyone has reviewed the deployment than about this container specifically.
docker/chatbot/Dockerfile — runs as root |
docker/exporter/Dockerfile — runs as root |
docker/tinode/Dockerfile — runs as root |
25 SQL statements built from strings
adequate25 places in product code build SQL by formatting or joining strings rather than passing parameters, and in 19 of them a value, not a table or column name, goes into the string. Where any of those values comes from a request, it is an injection point. Each site needs a look; the fix, parameters, is small.
server/db/mysql/adapter.go:997 — SQL built from a string |
server/db/mysql/adapter.go:1336 — SQL built from a string |
server/db/mysql/adapter.go:2193 — SQL built from a string |
Observability & Operations
adequateOne request cannot be followed through the logs
adequateNothing in the service carries a request or correlation id, and there is no tracing. When a customer reports a failure, the log lines that belong to their request cannot be picked out from everyone else's.
| no request id, correlation id or tracing found |
No error reporter is wired in
adequateNothing in the service initialises an error reporter (Sentry, Rollbar, Bugsnag, Honeybadger or an APM agent). An exception in production reaches a person only if someone is reading the logs, which usually means a customer reports it first.
| no error reporter initialised |
Fit with the Acquirer
not assessableNot rated: structurally not assessable from a repository.
Read more, or read your own
The full report on tinode/chat: every dimension, the questions for the room, and the audit log.
Survey a repository: free on public repositories. Private code is read on your own machine by a collector whose source you can read first.