[Bug 264232] www/mattermost-{server,webapp}: Update to 7.3.0

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264232

Kubilay Kocak <koobs@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ports-secteam@FreeBSD.org
           Keywords|                            |needs-patch, security
           Priority|---                         |Normal

--- Comment #10 from Kubilay Kocak <koobs@FreeBSD.org> ---
6.4.3 is affected by at least the following security vulnerabilities[1]:

    MMSA-2022-00112
    MMSA-2022-00110
    MMSA-2022-00109
    MMSA-2022-00108
    MMSA-2022-00104 (fixed in 6.4.3)
    MMSA-2022-00102
    MMSA-2022-00101

6.3.x (LTS) received fixes for the above, but 6.4.x (non-LTS release) has not
(except MMSA-2022-00104)

There are additional vulnerabilities for 6.5, 6.6, 6.7 [1] that were only fixed
in 7.0, 7.1, 7.2 branches.

There are upgrade compatibility considerations for every major.minor upstream 
release [2], including schema and configuration changes that are required post
upgrade:

    6.4 -> 6.6 comprises configuration only changes
    6.7 has schema changes
    7.1 has schema changes
    7.2 has schema changes

Current mattermost release branches [3] are:

    v7.3 - Feature Release
    v7.2 - Feature Release
    v7.1 - Extended Support Release
    v7.0 - Major Release
    v6.3 - Extended Support Release

Options for upgrade paths given the above are:

    1) Upgrade port to latest (supported) LTS, currently 7.1, OR
    2) Upgrade port to latest version, currently 7.3, OR 
    3) Create new mattermost7 port(s), at the current LTS, allowing people
upgrade at their own pace.

Since Option 1 requires schema changes, Option 2 isn't much more of an issue.

However, Option 2 puts the port in a position (at a non-LTS version) where it
could
end up in the same situation as today, without support and not receiving bug
or security fixes.

Also, quarterly port/package versions are vulnerable, so any option must
satisfy
resolving in quarterly.

Quarterly is not supposed to receive functional / feature changes (all else
equal),
particularly those that may break service/services on upgrade without user
intervention.

This leaves Option 3 as the most viable option, with the addition of:

    3.1) Mark current mattermost ports DEPRECATED and vulnerable (VuXML), with
messaging to upgrade/move
      to the latest port version, with clear UPDATING upgrade instructions.
    3.2) Merge the new mattermost7 port(s), allowing users in quarterly to
upgrade with notice.

A decent mattermost port/package target state would appear to be a mattermostX
port for each major (X) version LTS (minor) version.

In order to progress this issue, the following is necessary, in order:

    1) VuXML patch adding each vulnerability including all vulnerable/fixed
versions correctly.
    2) Patch creating new mattermost7 port(s) for 7.1 LTS version
    3) Patch marking current mattermost port as DEPRECATED with EXPIRATION_DATE
(fairly immediately) and clear messaging of what to do.
    4) Patch to UPDATING adding clear information for what users need to do for
a 6.4.2 to 7.1 (new port)
   upgrade.
    5) Remove current mattermost port in HEAD at some point, potentially with
MOVED (to mattermost7)
   entry (needs-qa).

[1] https://mattermost.com/security-updates/
[2] https://docs.mattermost.com/upgrade/important-upgrade-notes.html
[3] https://docs.mattermost.com/install/self-managed-changelog.html

-- 
You are receiving this mail because:
You are the assignee for the bug.