greptimeteam/greptimedb: technical due diligence, read from its repository

1 of 8 `FROM` lines in product Dockerfiles name an image without a version, or with `latest`. Each build pulls whatever the registry serves that day, so the image that ships can change without a commit, and last month's build cannot be reproduced. Pin a version, or a digest.

No 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.

52 of 1,447 locked dependencies match 78 published advisories in OSV, 7 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version. This lockfile pins development tools alongside what ships and does not say which is which, so some of these may never reach a user.

Nothing 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.

src/common/greptimedb-telemetry/src/lib.rs sends to telemetry.greptimestats.com, and config/datanode.example.toml leaves reporting on as shipped. Every installation reports to the vendor unless its operator turns this off. For a buyer running it inside their own product, that is an outbound data flow to a third party: ask what is sent, how often, and whether the buyer's customers were told.