autonomic-bot
985dc06e47
Two recipes could not see CVEs at all. mattermost-lts has an empty GitHub advisory feed and renders its security bulletins client-side, so a text sweep finds nothing; mumble publishes nothing anywhere the registry points. Both returned '?' - nothing measured - which is honest but useless. NVD is CPE-indexed and carries structured version ranges, so it answers where the vendor does not. Declared per recipe as 'nvd-cpe: <image> = <cpe:2.3:...>'. mattermost-lts 10.5.0 -> 10.12.4 165 CVEs mattermost-lts 10.11.22 -> 10.12.4 0 CVEs (measured, not unknown) mumble 1.3.0 -> 1.6.870 2 CVEs Both NVD range forms are used: versionEndExcluding is a patched version; versionEndIncluding means the fix version is unpublished but the upgrade delivers it whenever it crosses X. That 0 for the actual mattermost upgrade is the interesting one, and it needed a new rule to be correct: a fix on the line you upgrade FROM was already yours. mattermost patches every maintained line at once, so 10.11.22 -> 10.12.4 crosses 10.12.1 while 10.11.22 already had the 10.11.4 backport. Without the rule the scan claimed 12 CVEs the upgrade did not deliver. The rule is skipped for placeholders: '7.4.X' parses to a bare 7.4 and would read as 'already fixed at 7.4', which silently dropped redis CVE-2024-46981 and took discourse 140 -> 139 before I caught it. 79 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 / plausible 6 unchanged. Fleet sweep: 0 recipes with no usable CVE source, down from 2.
7.6 KiB
7.6 KiB
Upstream sources — mattermost-lts
| service | image | source repo | releases / changelog |
|---|---|---|---|
| app | mattermost/mattermost-team-edition | https://github.com/mattermost/mattermost | https://docs.mattermost.com/deploy/mattermost-changelog.html |
| postgres | postgres | https://github.com/postgres/postgres | https://www.postgresql.org/docs/release/ |
Standing notes
- mattermost-lts tracks the 11.7 ESR (Extended Support Release) = Mattermost's LTS line. The "LTS"
concept in Mattermost is ESR; there is NO "10.x LTS line". Release calendar (endoflife.date/mattermost):
- 10.11 = previous ESR, security support ends 2026-08-15 (~7 weeks) — migrated away 2026-06-19
- 11.7 = current ESR, supported through 2027-05-15 (~11 months); latest patch: 11.7.7 (2026-07-17)
- 11.8.x = innovation release (3-month lifecycle, EOL 2026-09-15) — do NOT target
- 10.12 = innovation release, support EXPIRED 2025-12-15 (do NOT target, despite abra listing 10.12.4)
- Check the release lifecycle at https://endoflife.date/mattermost before each upgrade run.
- Next ESR after 11.7 expected ~February 2027 (9-month cadence)
The
release-11.7Docker Hub floating tag always points to the latest 11.7.x patch. IMPORTANT: Do NOT use 11.7.0–11.7.2 — they have a schemeid migration bug in therolestable when upgrading from 10.11.17+; use 11.7.3 or later (current: 11.7.7). - 2026-08-07 re-check (endoflife.date/api/mattermost.json; GitHub releases API; Docker Hub):
Operator (weekly /upgrade-all) directed extending PR #2 to 11.10.0 (newest on the 11.x
innovation line, consistent with PR #2's existing line). 11.10.0 is a PRE-RELEASE — GitHub
prerelease=True, published 2026-08-04 (rc1 2026-07-17, rc2 2026-07-30, rc3+v11.10.0 2026-08-04); Docker Hubmattermost/mattermost-team-edition:11.10.0exists (462 MB, pushed 2026-08-04, actively pulled). No detailed release notes published yet (body = "Mattermost Platform Release 11.10.0"). 11.10 cycle not yet on endoflife.date; monthly cadence → EOL ~2026-11-15. Innovation, NOT ESR. This run bumps 11.9.0 → 11.10.0 per operator instruction and flags the pre-release + ESR-vs-innovation choice prominently in the PR body + report. ESR remains 11.7.8 (stable, EOL 2027-05-15) — the real LTS/ESR alternative if the operator wants LTS. Survey-hint correction (again): the 2026-08-07 survey claimed "alternative ESR = 10.12.4"; that is STILL wrong — 10.12 is an EXPIRED innovation release (EOL 2025-12-15, lts:false on endoflife.date); do NOT switch to 10.12.4. 10.11 ESR EOL 2026-08-15 (8 days); upstream main still pins 10.11.22. postgres 15-alpine HELD (major DB bump out of scope for weekly cron). - 2026-08-04 re-check (endoflife.date/api/mattermost.json; GitHub releases; Docker Hub):
11.7.8 released 2026-07-31 is the newest 11.7.x ESR patch (ESR supported through
2027-05-15). 11.9.0 (innovation, released 2026-07-08, cycle EOL 2026-10-15 ~10 weeks,
NOT ESR) and 11.8.4 (innovation, EOL 2026-09-15) remain innovation releases — the standing
guidance for AUTONOMOUS runs is still "do NOT target innovation; track 11.7 ESR." HOWEVER, the
2026-08-03 weekly /upgrade-all operator task explicitly directed a bump to 11.9.0 (the survey
target), so this run targets 11.9.0 per operator instruction with the EOL/innovation status
flagged in the plan + PR body + report for operator reconsideration. 11.9.0 confirmed real:
GitHub tag
v11.9.0(published 2026-07-08, not prerelease), Docker Hubmattermost/mattermost-team-edition:11.9.0(458 MB, 2026-07-08). Features: Ranked Attributes, ABAC per-action Permission Rules, Program Masking, Azure Blob Storage.abra recipe upgradelists 11.10.0 highest and 11.9.0 next. PR #2 extended 11.7.8 → 11.9.0 (fast-forward). 10.11 ESR security support ENDS 2026-08-15 (~11 days). - 2026-07-24 re-check (endoflife.date/api/mattermost.json; GitHub releases): 11.7.7
released 2026-07-17 is the newest 11.7.x ESR patch — bumped PR #2
11.7.6 → 11.7.7(ESR security patch, "Low to High severity security fixes", no migrations/breaking changes),!testmeGREEN (drone run #1143). 11.7 ESR supported through 2027-05-15; 10.11 ESR security support ENDS 2026-08-15 (~3 weeks) — migrate away. 11.8.4 (innovation, EOL 2026-09-15) and 11.9.x remain innovation releases, NOT ESR — do NOT target. - 2026-07-13 re-check (endoflife.date updated 09 Jul 2026): 11.7.6 is still the latest 11.7.x ESR patch (no newer 11.7.x released since 25 Jun 2026). abra lists 11.9.0 as the highest upgrade, but 11.9 is a brand-new innovation release NOT on endoflife.date yet — NOT ESR, do NOT target. 11.8 innovation latest is 11.8.3 (06 Jul 2026), EOL 15 Sep 2026. 10.11 ESR security support ends 15 Aug 2026 (~5 weeks). PR #2 re-verified GREEN with 11.7.6.
- 2026-06-26 re-check (endoflife.date/mattermost, data 2026-06-27): 11.7.6 released 2026-06-25 (Low–Medium security fixes, no breaking changes / no migrations) is the newest 11.7.x patch — REFRESH target from 11.7.5 → 11.7.6. 10.11 ESR security support ends 2026-08-15 (~7 weeks); 10.12 innovation ENDED 2025-12-15 (do NOT target, despite the survey listing 10.12.4); 11.8 innovation EOL 2026-09-15. GitHub release: https://github.com/mattermost/mattermost/releases/tag/v11.7.6
- Survey-correction log: the 2026-06-26 orchestrator survey claimed "10.x is LTS, target 10.12.4, 11.x is non-LTS". That is incorrect — Mattermost has no "10.x LTS line"; the LTS concept is ESR, the ESR line jumped 10.11 → 11.7 in May 2026, and 10.12 is an EXPIRED innovation release. Both the 2026-06-19 and 2026-06-22 runs correctly identified 11.7 ESR as the LTS target; this run re-confirms it. The survey's recommendation would have regressed the recipe onto an unsupported branch — DO NOT follow it.
- postgres: stay on 15-alpine for now. The upgrade to 16-alpine requires a major-version migration (pg_upgrade or dump/restore with operator involvement) because the stack runs with a persistent postgres_data volume. A 16 container against pg15 PGDATA crashes on startup. Major pg bump is a separate operator-guided step.
- Backup format (as of PR #2 / upcoming 3.0.0+11.7.5 release):
pg_backup.shDocker config on the postgres service. Backup:pg_dump | gzip → backup.sql. Restore: terminate connections, FORCE-drop, recreate DB, reimport dump.DROP DATABASE WITH (FORCE)requires PostgreSQL 13+ — safe on postgres:15-alpine. The previous inline-label approach (no restore hook) was a defect: raw PGDATA restore without a reload was a silent no-op. Fixed in PR #2 (restore fix cherry-picked from PR #1 ci/pg-restore).
NVD CPE fallback
This project publishes nothing machine-readable we can reach — no GitHub advisory feed,
no release-attributable changelog — so its CVE count was ? (nothing measured). NVD is
CPE-indexed and carries structured version ranges, so it can answer where the vendor
cannot. It LAGS the vendor, so it is a fallback, never the primary source.
- nvd-cpe: mattermost-team-edition = cpe:2.3:a:mattermost:mattermost_server::::::::
- nvd-cpe: postgres = cpe:2.3:a:postgresql:postgresql::::::::