Files
cc-ci-orchestrator/cc-ci-plan/upstream/mattermost-lts.md
T
autonomic-bot 985dc06e47 advisory-scan: NVD by CPE, so mattermost and mumble stop scanning as '?'
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.
2026-08-11 22:16:37 +00:00

87 lines
7.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.7` Docker Hub floating tag always points to the latest 11.7.x patch.
IMPORTANT: Do NOT use 11.7.011.7.2 — they have a schemeid migration bug in the `roles` table
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 Hub `mattermost/mattermost-team-edition:11.10.0` exists (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 Hub
`mattermost/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 upgrade`
lists 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), `!testme` GREEN
(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 (LowMedium 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.sh` Docker 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:*:*:*:*:*:*:*:*