Email or username:

Password:

Forgot your password?
All posts Michael's posts Post Back to profile
Michael Stanclift

Based on the latest version data from fedidb.org/software/mastodon/v I've summarized the current state of Mastodon version deployments.

- 61% of instances are now on the latest branch or main (4.2/4.3) πŸ™Œ
- 2% of instances are running versions which are no longer supported (Before 3.5) πŸ§Ÿβ€β™‚οΈ
- 8% of instances are running versions which will be end of life at the end of October (4.0) πŸ‘€

#MastoAdmin who aren't keeping current, especially if you're still on a release that has EOL dates, what is holding you back?
17 Oct 2023 at 16:00 | Open on vmst.io
13 comments
stuart

@vmstan

Have you got a number for instances running insecure versions (< 4.1.8 and other branches)?

17 Oct 2023 at 16:17 | Open on social.brainsys.com
My Actual Brain

@vmstan It might be worth ranking them by number of users instead. I could see a small amount of people deploying their own server and then neglecting it. I have been guilty of that with other services.

17 Oct 2023 at 16:19 | Open on fosstodon.org
Michael Stanclift

There have been two sets of CVEs that were released for Mastodon this year. One set on July 6, and one set on September 19.

The July 6 set was particularly serious, and there was a big push to get folks to upgrade off 4.1.2 and other vulnerable branches.

According to FediDB data, 16.2% of instances are remaining on versions still exposed by the July 6 CVEs or an unknown end of life versions that wasn't evaluated but may contain those same issues.

33.0% are impacted by the September 19 CVEs.

#MastoAdmin

There have been two sets of CVEs that were released for Mastodon this year. One set on July 6, and one set on September 19.

The July 6 set was particularly serious, and there was a big push to get folks to upgrade off 4.1.2 and other vulnerable branches.

According to FediDB data, 16.2% of instances are remaining on versions still exposed by the July 6 CVEs or an unknown end of life versions that wasn't evaluated but may contain those same issues.

17 Oct 2023 at 16:19 | Open on vmst.io
JL Johnson :veri_mast:

@vmstan I wonder if bad actors could use outdated instances to attack the up-to-date ones? Is there some setting somewhere to "break up" with instances that are X days/versions out of date?

17 Oct 2023 at 16:21 | Open on vmst.io
Michael Stanclift

I'm not a statistician, but there are a few things to consider in all this.

FediDB is a really good source of truth, but there is no single source of who runs what versions.

There is a possibility that folks individually patched their instances with the relevant CVE fixes but otherwise remained on older versions.

There are a number of dead instances in FediDB, where they may have been polled when their version was the latest and greatest, and then disappeared from the Fediverse.

17 Oct 2023 at 16:24 | Open on vmst.io
Michael Stanclift

Something else to consider, but that I've not figured out a great way to poll yet, is the user representation of those on out-dated installs.

The largest instances in the network tend to have administrators who are aware of updates, and apply them regularly (especially when it's security related) either because they care, because their users ask them to, or because they're on managed providers that handle it for them.

Sorted by monthly active users:
10 of 10
19 of 20
46 of 50
92 of 100

Are all patched.

Something else to consider, but that I've not figured out a great way to poll yet, is the user representation of those on out-dated installs.

The largest instances in the network tend to have administrators who are aware of updates, and apply them regularly (especially when it's security related) either because they care, because their users ask them to, or because they're on managed providers that handle it for them.

17 Oct 2023 at 16:36 | Open on vmst.io
stuart

@vmstan

A useful feature would be for Admins to automatically block instances below a security version level. Might encourage recalcitrant Admins to catch up.

Paging @Gargron

17 Oct 2023 at 17:17 | Open on social.brainsys.com
Emelia πŸ‘ΈπŸ»

@stuart @vmstan @Gargron mastodon currently doesn't collect nor store information on the instances it's federating with, afaik, so this would be hard to do, without a change to collect that data.

17 Oct 2023 at 17:52 | Open on hachyderm.io
stuart

@thisismissem @vmstan @Gargron

The information is there in the api which known instances could be sampled daily. Only it might get complicated with instances not using Mastodon. Perhaps introducing a unique version code like mstdn.4.x.x or kbin.x.x.x might help.

Vulnerabilities occur elsewhere. Might be useful if a gihub account of another distribution gets compromised and they need to be locked out until proven safe.

Just a suggestion going forward if other distributions would co-operate.

17 Oct 2023 at 18:31 | Open on social.brainsys.com
Emelia πŸ‘ΈπŸ»

@stuart @vmstan yes, the information may be in the API & available via say nodeinfo, but Mastodon doesn't actually store data about instances, just the known accounts & domain blocks.

tbh, this would possibly be better done via an advisory list.

17 Oct 2023 at 18:34 | Open on hachyderm.io
Eelco Maljaars πŸ‡³πŸ‡± πŸ‡ͺπŸ‡Ί

@vmstan When deploying mastodon using helm on kubernetes, most of the work is done for you. But if you run it on plain virtual machines, there is actual work to do for every upgrade. Checking dependencies, running upgrade tasks, etc. So that makes upgrades diffficult or at least 'more interesting'. That could hold people back #mastoadmin

17 Oct 2023 at 16:47 | Open on mastodon.nl
Go Up