felhom.eu/documentation/audits/new-apps-2026-10-10/FIT.md

FIT — checklist group 0 for Grocy, LubeLogger and Monica (2026-10-10)

Read and measured 2026-10-10 09:40–11:10 UTC. Sources: the GitHub API, raw upstream source at the pinned tag, the Docker Hub / ghcr registry APIs, and the images themselves started on bench LXC 9401 (demo-hp, Tier 0). [U] upstream code/docs/registry · [M] measured on the bench, this session · [I] our inference. Group 0 plans the later tests; it closes only what it measured.

Raw reads: A/. Bench transcripts: bench/.

Where the test machines actually are — a correction to the brief's reading: both 9202 (demo-hp-scratch) and the bench 9401 (upgrade-harness) live on demo-hp, not on felhom-pve. felhom-pve carries only 9201 (demo-felhom). Measured with pct list on both hosts.

The table

app (project → image, and why that image)	licence (file read)	last release · 2026	tags · arch	phone-home (switch)	internet at runtime	non-HTTP ports	clients / login route	DB + services	memory (rough)	Hungarian UI	first-admin class	verdict
Grocy (grocy/grocy → lscr.io/linuxserver/grocy). There is no image published by grocy itself — grocy/grocy on Docker Hub is 404 [M], and grocy's own README answers "How to run using Docker" with a single link to hub.docker.com/r/linuxserver/grocy [U]. So linuxserver is the upstream-recommended image, and the catalog already pins four others from the same publisher.	MIT — LICENSE.md, API spdx_id: MIT [U]	v4.7.1, 2026-09-04 · 3 in 2026 (v4.6.0 03-06, v4.7.0 08-28, v4.7.1 09-04); 83 releases since 2017	4.7.1, version-v4.7.1, v4.7.1-ls343, latest · amd64 + arm64 [M]. linuxserver rebuilds weekly, so 4.7.1 is re-pushed (ls342 2026-09-27 → ls343 2026-10-04)	none. The only outbound hosts in the whole codebase are world.openfoodfacts.org (the barcode-lookup plugin, on the household's explicit action) and releases.grocy.info (demo-data images, only when MODE ≠ production) [M, repo-wide grep]. No update check, no analytics. Switch: GROCY_STOCK_BARCODE_LOOKUP_PLUGIN=""	no	none (80 in the image; 443 unused)	PWA only — no native app. Third-party phone apps use the REST API with the header GROCY-API-KEY (app.php:102) [M]; the iCal feed uses ?secret=	SQLite, one container (/config/data/grocy.db); nginx + php-fpm 8.5	~30 MiB idle [M]	yes — ~92 %. localization/hu/strings.po holds 734 strings, 62 untranslated (91.6 %); the login page rendered <title>Bejelentkezés | Grocy</title> with GROCY_DEFAULT_LOCALE=hu [M]	class 3 — admin/admin exists on a fresh start and signs in [M]	build
LubeLogger (hargata/lubelog → ghcr.io/hargata/lubelogger; upstream's own docker-compose.yml names exactly this image. hargata/lubelogger on Docker Hub carries the same tags — ghcr chosen because it is the one upstream writes down)	MIT — LICENSE, API spdx_id: MIT [U]	v1.7.3, 2026-09-12 · 17 in 2026 (v1.6.1 02-26 … v1.7.3 09-12)	v1.7.3, v1.7.2 … latest, edge · amd64 + arm64 [M]	none at start. Three outbound fetches, each on a page the household opens: the sponsors list (hargata.github.io), the release check (api.github.com, behind a checkForUpdate request flag), and the language-pack download (hargata.github.io) [M]. Startup makes no request — the first log lines are the banner and Now listening [M]	no	none (8080). A SignalR websocket at /api/ws — websockets pass the tunnel (MeTube measured 101)	PWA; no official native app. API takes HTTP Basic or x-api-key / ?apiKey= on /api, /kiosk, /images, /documents, /temp (GetPathAllowAPIKeyAuth) — Basic measured 200 right / 401 wrong [M]	LiteDB, one container (/App/data/cartracker.db). PostgreSQL is optional (POSTGRES_CONNECTION); upstream's default compose runs LiteDB, so per 1.2 that is what we run	~50–61 MiB idle [M]	yes, after one click — ~72 % coverage. Nothing ships in the image: /App/data/translations/ is empty on a fresh start [M]. hu_HU exists in the project's directory and the household downloads it in Settings; the file holds 403 keys of which 400 are translated (99.3 %), but German's file holds 559 — so hu_HU covers ~72 % of the largest key set and the rest falls back to English [M]	class 1 once we set it — see below	build
Monica (monicahq/monica → monica, a Docker Official Image)	AGPL-3.0 — LICENSE.md, API spdx_id: AGPL-3.0 [U]	none since 2025-04-21; the last stable release is v4.1.2, 2024-05-04 — 29 months [U]	4.1.2, 5.0.0-beta.5, each × -apache/-fpm/-fpm-alpine · 7 arches; the image is re-pushed constantly (2026-10-08) because Docker Official Images rebuild on base-image changes	not reached	not reached	not reached	not reached	MySQL/MariaDB or PostgreSQL + Redis [U]	not measured	not measured	not measured	stop — 0.2. The operator decides.

Monica — the stop, in full, because it is the one decision this run hands back

Checklist 0.2 asks for a release in the last 6 months. Monica has had none in 17 months, and no stable release in 29 months. Four independent reads, all 2026-10-10:

1. Releases. The newest release of any kind is v5.0.0-beta.5, 2025-04-21, and it is a prerelease. The newest stable is v4.1.2, 2024-05-04. The tag list agrees: after v4.1.2 there is nothing but betas.
2. The stable branch is dead. 4.x — the branch the README sends you to for "the stable and current version" — has its newest commit on 2024-05-04.
3. main is the beta, and says so: "This branch is in development. It's our beta version."
4. The commit history has a 13-month hole: 2025-08-30, then nothing until 2026-09-24, when two commits landed. One of them is the telling one — it adds a login-page notice reading "As we are about to deploy a brand new version of Monica, this instance and all its data will be deleted at the end of December 2026" (PR #7978, merged 2026-09-24). The notice is APP_SHOW_DELETION_NOTICE, off by default, so it would never show on a household's box; what it tells us is about the project, not the switch: the author is preparing a rewrite and is winding the hosted service down.

So the brief's third anticipated risk is not only real, it is worse than "releases slowly": nothing has been released for a year and a half, the stable branch has not moved in two and a half years, and upstream has announced a replacement with no date. 790 issues are open.

What the operator decides. Keeping Monica out costs the catalog nothing it has today — no app covers a family address book, and none did yesterday either. Letting it in means publishing an app whose next version is a rewrite with no migration story, on a household's box, with our name on the restore promise. The honest recommendation is keep it out and look again when the rewrite ships; lifecycle: exists precisely so an app can be added later without disturbing anything. Radicale already carries contacts over CardDAV for households that only want the address book itself.

The three risks the brief named, measured

1. Grocy starts with admin / admin — true, and the replacement route is proven

Upstream says it in its own README: "Default login is user admin with password admin, please change the password immediately". Measured on the bench, fresh volume:

• the users table holds exactly one row, id=1 admin, password hashed $argon2id$v=19$m=65536,t=4,p=1;
• POST /login with username=admin&password_base64=YWRtaW4= → 302 to /, and the cookie returns a 200 stock overview. So the default really is admin/admin;
• a stranger with no cookie gets 302 → /login on every page and 401 on /api/system/info. There is no open first-run screen — grocy is first-admin class 3, the bookstack / mealie / calibre-web shape, not a setup_gate app.

How the install replaces it (checklist 3.2). Grocy ships no CLI, no admin env var and no headless setup. It does ship the hashing primitive it uses itself: UsersService calls password_hash($password, PASSWORD_ARGON2ID), and the image's PHP 8.5.6 reports password_algos() = [2y, argon2i, argon2id] with pdo_sqlite present [M]. So the after_install command is a php -r that takes the password as its own argument ($argv[1] — measured: with php -r 'code' a b, $argv[1] is a), hashes it with grocy's own algorithm, writes it with a prepared statement, and then verifies with password_verify before printing its success marker. Proven on the bench:

after the command ran	result
admin / admin	302 → /login?invalid=true (refused)
admin / generated	302 → / (signed in)
admin / a wrong password	302 → /login?invalid=true (refused)

Lock-out (3.6), measured: 25 wrong passwords in a row for admin, then the right one — in at once. Grocy has no lock and no throttle. So the name need not be generated (the calibre-web reason, R-752, does not apply here) and no family member can be locked out by a stranger.

Barcode scanning. Upstream: camera scanning is ZXing, "totally offline / client-side camera stream processing", and "due to browser security restrictions, this only works when serving Grocy via a secure connection (https://)". Every Felhom app is served https:// through the tunnel, so it works — and the scanning itself sends nothing anywhere. The lookup of an unknown barcode is the separate, explicit "External barcode lookup" workflow, and that one does reach world.openfoodfacts.org with the barcode number.

Overlap with Mealie / Tandoor. Grocy has recipes and a meal plan too, so the overlap is real but narrow: Mealie and Tandoor are recipe libraries (import a recipe, scale it, cook from it), grocy is a stock book (what is in the house, what runs out, what to buy, whose turn the chores are). Grocy's recipes exist to subtract ingredients from stock. One line goes in use_cases.

2. LubeLogger may have no login at all — true, and worse than "may"

Middleware/Authen.cs reads bool.Parse(configuration["EnableAuth"] ?? "false"), and appsettings.json ships "EnableAuth": false. When it is false the middleware mints a ticket for every request with ClaimTypes.Name = "admin" and the role IsRootUser. Measured on a default start, as an anonymous stranger:

request	result
GET /	200, <title>Garage - LubeLogger</title>
GET /api/vehicles	200
GET /Home/Settings	200
POST /Vehicle/SaveVehicle	200 {"success":true} — and the vehicle came back from /api/vehicles

So on a default install anyone who finds the subdomain reads and writes the family's car records as root.

The route that turns it on, and it is better than an after_install. The root login is not a database row: AuthenticateRootUser compares the submitted name and password, each SHA-256 hex (StaticHelper.GetHash), against the config keys UserNameHash and UserPasswordHash. ASP.NET's configuration includes environment variables, so all three keys can be set at deploy time — which means auth is on before the app's first byte, with no install window to measure. Measured from the container's creation, polled every second:

t+1s  /api/vehicles=000 (not listening yet)   /=000
t+2s  /api/vehicles=401                       /=302 → /Login/Index
t+3s  /api/vehicles=401                       /=302 → /Login/Index

and then, with auth on:

request	result
stranger GET /, GET /Home/Settings, POST /Vehicle/SaveVehicle	302 → /Login/Index
stranger GET /api/vehicles	401
household's generated login, web form	{"success":true}, and /api/vehicles 200 with the cookie
household's login, wrong password	{"success":false,"message":"Invalid Login Credentials"}
API Basic auth, right / wrong	200 / 401

So the verdict is build, and LubeLogger becomes first-admin class 1 — generated by us at install.

Two more things that had to be checked before trusting the env route, both measured:

• No config file undoes it. Program.cs adds data/config/userConfig.json to the configuration after the environment, so a file holding EnableAuth: false would win. On a fresh start that file is not written (/App/data/config/ was empty). And when it is later written, SaveUserConfig deliberately re-reads those three keys from the merged configuration rather than from the posted form — so the household cannot turn auth off from the UI while the env sets it.
• Sign-up is closed by the app itself. RegisterNewUser refuses without a token minted by the root user: POST /Login/Register answered {"success":false,"message":"Invalid Token"}. Nothing for signup_block to do.

Lock-out (3.6), measured: 25 wrong passwords, then the right one — in at once. No lock, no throttle. Same reading as grocy, and the same conclusion: a stranger cannot lock the family out.

Database (1.2). LiteDB, which is upstream's default compose. One container, no engine, so no MariaDB / PostgreSQL major ever to cross — the whole engine-major rule is n/a for this app by construction.

File uploads (2.2). InitMessage creates data/images, data/documents, data/temp, data/themes, data/translations beside data/cartracker.db. Receipts and documents are household content → the ${USERDATA_PATH} side; the database and the DataProtection keys are appdata.

One thing the image lacks, and it changes the healthcheck. ghcr.io/hargata/lubelogger:v1.7.3 has no curl, no wget, no nc, no python, no node [M] — none of the four healthcheck families in REUSE.md §2 exists in it. It does have bash, and /dev/tcp works there (measured: Connection refused against a dead port, which is the mechanism answering). So LubeLogger needs a fifth family, a bash /dev/tcp probe, and that is a catalog-wide convention — it goes into REUSE.md in the same commit.

3. Monica's release state — see above. The brief said "releases slowly"; the measurement says "stopped".

Claims in this brief that turned out wrong, or need sharpening

1. "Grocy starts with the login admin / admin (as far as we know)" — right, and now measured rather than assumed, on a fresh volume and through the login route.
2. "LubeLogger may have no login at all until someone turns it on in its settings" — right about the default, wrong about "settings": the switch is a configuration key readable from the environment, which is why the fix needs no post-install step and leaves no window. The brief's worry that "a stranger on the internet sees the family's car data" understates it: a stranger also writes it, as root.
3. "Monica releases slowly" — too kind. No release in 17 months, no stable release in 29, the stable branch untouched since 2024-05-04, and an upstream notice that the hosted instance and its data go away at the end of December 2026 ahead of a rewrite.
4. "the test machines" — 9202 and the bench 9401 are both on demo-hp. felhom-pve has only 9201.
5. Grocy's image. The brief asks "upstream recommends which?" — the answer is unambiguous and worth writing down: upstream publishes no image of its own and points at linuxserver.io.
6. A near miss worth recording. My first pass at grocy's Hungarian coverage reported 0 % translated — a broken .po parser that mishandled multi-line msgstr. The German control (which must be ~100 %) read 0 % too, which is what caught it; a second, independent counting method gave German 0 untranslated, French 12, Hungarian 62 of 734 → 91.6 %, with real Hungarian strings in the samples. Without the control this table would have carried a false "no" in its most load-bearing new column.

What group 0 did NOT close

• Memory from birth with swap off (5.1), the 10-minute soak (5.2), backup/restore through the product (2.5), "remove with data" (2.6), the upload read back through the front door (2.8), the cold-start health timing (4.3), the negative health control (4.4), the ladder step (6.2) and the forced-fail undo (6.3) are all Part-B work on the bench and on 9202. Nothing above closes them.
• The forged-X-Forwarded-For test (3.10) through the simulated tunnel is Part B. What is read so far: grocy reads no client address anywhere (repo-wide grep for REMOTE_ADDR / HTTP_X_FORWARDED_FOR / getClientIp — nothing), and LubeLogger reads it in one place only, LoginController ~L521: it takes the real peer from Connection.RemoteIpAddress and then appends the whole X-Forwarded-For string to a LogWarning for a failed login. Measured with a forged header, the log line read Failed Login for … from ::ffff:172.17.0.1, 1.2.3.4, 10.9.9.9 — the real peer first, the forged part visible and deciding nothing. No trusted-proxy list, no ForwardedHeaders middleware, no lock and no rights keyed on the address. So neither app needs the <router>-xff reset; both get a line in their record saying why.