Confusion regarding Mattermost version number

Hi,

I upgraded my Mattermost from 5.27.0 to 5.27.2 after the security announcement, following all the usual steps from Redirect

However, running bin/mattermost version shows the version number is still 5.27.0 (although the build hash and the date have changed)

Version: 5.27.0
Build Number: ee_onprem_003fb092761115ea1bcfae56482d67f59395b8d0_b76e2800149b382e117c8d17d1d6031a55926115_429
Build Date: Fri Dec  4 00:20:47 UTC 2020
Build Hash: 003fb092761115ea1bcfae56482d67f59395b8d0
Build Enterprise Ready: true
DB Version: 5.27.0

The previous version said this:

Version: 5.27.0
Build Number: 5.27.0
Build Date: Mon Sep 14 12:42:44 UTC 2020
Build Hash: bd6149b00455ed615c0552e7f709d33920885ef3
Build Enterprise Ready: true
DB Version: 5.27.0

This is more than a little bit confusing. The ‘Build Number’ is completely different format from the last version, and all other version numbers still show 5.27.0.

How can I be sure my Mattermost version has correctly updated?

Hi @mig5, welcome to the Mattermost Community.

You could check the version of Mattermost by navigating to About Mattermost while logged in.

Could you perform the upgrade again using the instructions in the post below and let us know the outcome.

Hi @andrew.bimba

Those are basically the same steps I ran, since they match your upgrade docs. The only difference is I chose 5.27.2 as the new version to fetch, as the security announcement implied it contained the required fix, for, in my case, an installation of 5.27.0.

The ‘About Mattermost’ section of my site shows the same info as I pasted above.

Mattermost Version: ee_onprem_003fb092761115ea1bcfae56482d67f59395b8d0_b76e2800149b382e117c8d17d1d6031a55926115_429
Database Schema Version: 5.27.0
Database: mysql

That build version number is really weird. And I have reproduced it on two separate Mattermost installations now, both trying to upgrade to 5.27.2.

Are you saying that in fact, users need to upgrade from 5.27 to 5.29 to obtain the security fix? I’m not really inclined to re-run the upgrade per the link you provided, which would upgrade me to 5.29, unless you’re saying that’s the only way to fix it (but in which case, what was the 5.27.2 release for?)

Are you saying that in fact, users need to upgrade from 5.27 to 5.29 to obtain the security fix?

No, that was just a sample with 5.29. You can follow the same steps with 5.27.2.

Thanks, well yep, that’s what I did, on two separate servers already.

Maybe my original post isn’t making sense to you. I wanted to point out that despite having upgraded to 5.27.2, all version numbers still show either ‘5.27.0’, or that crazy build number (which seems to be an anomaly compared to the previous release where that build number shared the same version number as the other fields).

I am going to assume I upgraded ok (that is - I’ll assume that the 5.27.2 tarball gave me the correct release despite what its internals tell me), but I recommend to the upstream devs to look at adjusting the version numbers properly when releasing a critical vulnerability, as it’s pretty confusing to those of us paying attention :slight_smile: There’s a bit of extra cognitive load to worrying about the version numbers when it’s a critical vuln you’re trying to fix. The peace of mind would be nice

Cheers

Can I ask if you fully restarted your Mattermost Instance upon upgrade completion, and before you checked the version?

This could impact the output of a version check, as you wouldn’t have reloaded the new program and server files to memory yet, if you haven’t restarted the instance.

Yes I did.

From the bash history itself:

cd /home/mattermost/mattermost
./bin/mattermost version
cd /tmp/
wget https://releases.mattermost.com/5.27.2/mattermost-5.27.2-linux-amd64.tar.gz
tar -xf mattermost*.gz --transform='s,^[^/]\+,\0-upgrade,'
sudo systemctl stop mattermost
cd /home/mattermost/
sudo cp -ra mattermost/ mattermost-back-$(date +'%F-%H-%M')/
sudo find mattermost/ mattermost/client/ -mindepth 1 -maxdepth 1 \! \( -type d \( -path mattermost/client -o -path mattermost/client/plugins -o -path mattermost/config -o -path mattermost/logs -o -path mattermost/plugins -o -path mattermost/data \) -prune \) | sort | sudo xargs rm -r
sudo chown -hR mattermost:mattermost /tmp/mattermost-upgrade/
sudo cp -an /tmp/mattermost-upgrade/. mattermost/
sudo rm -r /tmp/mattermost-upgrade/
sudo systemctl start mattermost

After starting it back up, checking the version it reports:

Version: 5.27.0
Build Number: ee_onprem_003fb092761115ea1bcfae56482d67f59395b8d0_b76e2800149b382e117c8d17d1d6031a55926115_429
Build Date: Fri Dec  4 00:20:47 UTC 2020
Build Hash: 003fb092761115ea1bcfae56482d67f59395b8d0
Build Enterprise Ready: true
DB Version: 5.27.0

The ‘version’ check before I commenced downloading the new version:

Version: 5.27.0
Build Number: 5.27.0
Build Date: Mon Sep 14 12:42:44 UTC 2020
Build Hash: bd6149b00455ed615c0552e7f709d33920885ef3
Build Enterprise Ready: true
DB Version: 5.27.0

I don’t understand why the devs can’t just install 5.27.0, then upgrade 5.27.2, and confirm for themselves that what I am seeing is to be expected? It’s not very complicated, there are only two scenarios:

  1. Something I did is weird, and I have not actually upgraded to the correct version

  2. It is just the version numbers in the new release that are weird and unnecessarily confusing (crazy build number, and other version numbers still showing 5.27.0), and is the same for everyone else that has upgraded to 5.72.2 - in which case, it’s just that I’m the only one who bothered to a) check b) ask about it , and it’s nothing to worry about

I’m checking with our devops team whether this was an intentional change or not.

Hi @mig5!

Thank you for bringing this to my attention.
ee_onprem_003fb092761115ea1bcfae56482d67f59395b8d0_b76e2800149b382e117c8d17d1d6031a55926115_429

is the correct version for 5.27.2. I am sorry this is causing confusion.
We will address this issue for upcoming releases soon.

3 Likes

Is this version info coming from mmctl and not the About screen?