Topic: SMF 2.0.9 / 1.1.20 Security Patches Released

[Antechinus]

That doesn't fix security problems.

[amiralib]

does this patch fix the no UTF8 websites problems with PHP 5.4 or not?

[Kindred]

Did you read the changeLog?

And antechinus...
We will continue to provide support in the support boards... However, we will not be patching 1.1.x any further.  From now on, The recommended solution to security issues in 1.1.x is to upgrade to 2.0.x....

[NekoJonez]

Quick question: Which of the files are extremely important to update? Since some get for me: "Test failed (ignore errors)".

What do these parts of the update do exactly...? Is it really wise to ignore them?

[Kindred]

Your questions has alreayd been answered, above in this same thread...

[gisfreak]

congrats, updating now

[medicMe]

 

Thanks for all the hard work!

[HDB]

2.0.9 Patch installed on two forums and all is working great! Thanks!

[Chalky]

Nice work guys, thank you!

[Antechinus]

Did you read the changeLog?

And antechinus...
We will continue to provide support in the support boards... However, we will not be patching 1.1.x any further.  From now on, The recommended solution to security issues in 1.1.x is to upgrade to 2.0.x....

Ok, so let's be clear on this. The no-BS version is that in terms of security, 1.1.x is unsupported as of now. This is a change of policy over what has consistenly been claimed for years; that 1.1.x would be patched until 2.1 was stable.

That means that if an exploit for 1.1.x turns up before 2.1 is stable, which is quite possible given the pace of SMF dev, the admin of any 1.1.x site will have to turn their site upside down with a major upgrade to 2.0.x. Then, when 2.1 is stable, they will have to do it all over again if they want something up to date. 2.0.x isn't all that impressive by today's standards, and IMO has little real advantage over a well-customised 1.1.x, so this is going to be annoying. It'd be much better to just be able to go straight to 2.1, and only turn the site upside down once.

Do note that there are already other forum apps, some forked from SMF and some not,  that are stable now, and have very good features, and very good migration tools. If I was still adminning a 1.1.x site, I would not be taking this announcement as an incentive to upgrade to 2.0.x, because frankly there are better options available. I would be looking at those options instead. OTOH, if I could be sure of having 1.1x patched until 2.1 is stable, I would probably be more inclined to wait for 2.1.

Bottom line is you may be shooting yourselves in the foot with this change of policy. My 2c.

[Antes]

Did you read the changeLog?

And antechinus...
We will continue to provide support in the support boards... However, we will not be patching 1.1.x any further.  From now on, The recommended solution to security issues in 1.1.x is to upgrade to 2.0.x....

Ok, so let's be clear on this. The no-BS version is that in terms of security, 1.1.x is unsupported as of now. This is a change of policy over what has consistenly been claimed for years; that 1.1.x would be patched until 2.1 was stable.

That means that if an exploit for 1.1.x turns up before 2.1 is stable, which is quite possible given the pace of SMF dev, the admin of any 1.1.x site will have to turn their site upside down with a major upgrade to 2.0.x. Then, when 2.1 is stable, they will have to do it all over again if they want something up to date. 2.0.x isn't all that impressive by today's standards, and IMO has little real advantage over a well-customised 1.1.x, so this is going to be annoying. It'd be much better to just be able to go straight to 2.1, and only turn the site upside down once.

Do note that there are already other forum apps, some forked from SMF and some not,  that are stable now, and have very good features, and very good migration tools. If I was still adminning a 1.1.x site, I would not be taking this announcement as an incentive to upgrade to 2.0.x, because frankly there are better options available. I would be looking at those options instead. OTOH, if I could be sure of having 1.1x patched until 2.1 is stable, I would probably be more inclined to wait for 2.1.

Bottom line is you may be shooting yourselves in the foot with this change of policy. My 2c.

if some admins rather to stay on 1.1.x (which you need to downgrade your php/mysql for complete compatibility) they already "be shooting themselves in the foot"... But I agree, comparing 2.1 vs 2.0 - there is a big difference and yet its worth to wait for it, rather than going another software. To me I actually asked team to kill SMF 1.1 nearly 1 year ago, but we'll see things after first two beta releases of SMF 2.1.

@antechinus


I totally agree with you. I will stick to 2.0.9 until 2.1 will have the 110+ mods that I want updated, and since this is not likely to happen in at least 10 years time I think I will upgrade directly to 3, in said time, when mods etc etc... I think you got that.

Illogical
I wasn't going to reply to this topic but I don't have permission to split it so, admins will split this topic soon. This topic is not for discussing other softwares/new version or problems.

[Antechinus]

if some admins rather to stay on 1.1.x (which you need to downgrade your php/mysql for complete compatibility) they already "be shooting themselves in the foot"... But I agree, comparing 2.1 vs 2.0 - there is a big difference and yet its worth to wait for it, rather than going another software. To me I actually asked team to kill SMF 1.1 nearly 1 year ago, but we'll see things after first two beta releases of SMF 2.1.

Nope, because many good hosts run 1.1.x just fine. No problems at all. No downgrade required.

I wasn't going to reply to this topic but I don't have permission to split it so, admins will split this topic soon. This topic is not for discussing other softwares/new version or problems.

Well, split away if you like, but these are valid points to raise IMO, and they are directly related to the content of the OP of this topic. Just don't hide it all if you do split it.

[Arantor]

Wrong on your last point.

Any host that upgrades to PHP 5.4 or beyond - you know, for the *supported* versions of PHP (PHP 5.3 is EOL)... will have problems with SMF 1.1.

Any host that upgrades to PHP 5.5 or beyond - for the 'current' stable version of PHP - will definitely have problems with SMF 1.1.

The changes are sufficient that it is not feasible to patch such things.

And it has been recommended for months and months to upgrade anyway.

[Study Force]

Congrats on the release! Thanks for update to SMF 1.1.x as well

Same.

[Antechinus]

Wrong on your last point.

Any host that upgrades to PHP 5.4 or beyond - you know, for the *supported* versions of PHP (PHP 5.3 is EOL)... will have problems with SMF 1.1.

Any host that upgrades to PHP 5.5 or beyond - for the 'current' stable version of PHP - will definitely have problems with SMF 1.1.

The changes are sufficient that it is not feasible to patch such things.

And it has been recommended for months and months to upgrade anyway.

Ok, so what you are saying is that 1.1.x is effectively EOL right now, and 2.1 has no ETA. So, for anyone still on 1.1.x it comes down to comparing 2.0.x against whatever else is available right now, then deciding which option they prefer.

BTW, it has been recommended to upgrade to 2.0.x since the day it went stable, so you can't really blame people for ignoring more recent exhortations without the above information being given.

[Arantor]

Me? I don't get a say on it, I'm not team I'm merely observing the state of play with 1.1 and current PHP versions.

The fact that the codebase is even more legacy and convoluted in places than 2.0 is, the fact that there are likely more security holes simply never discovered thus far...

Let me put it this way: the original vulnerability fixed in 2.0.9 with the package manager was found by me. Recently, in fact, as in this year. Except it's been there since the start. Who knows how many more are waiting to be found? And worse: how many of them cannot meaningfully be fixed in 1.1 because of technical restrictions?

I am surprised, though, at the outright declaration of 'no more patches'. I thought the plan was to be blunt and say 'here's 2.1 beta; officially hereby be notified that with 2.1 final which is coming soon, 1.1 will no longer be supported'.

The fact 1.1 is now 8 1/2 years old is a minor detail.

[Antechinus]

My understanding was that the policy was always to patch whatever could be patched in 1.1.x, up until the day that 2.1 was stable, at which point 1.1.x would immediately get canned completely.

But 2.1 is not currently relevant, since it has no ETA.

[Arantor]

That was my understanding too - with the caveat that with 2.1 beta 1, there would be some prominent 'yo folks, this is what we're doing, time to get your house in order' warning about 1.1's imminent sunset.

[Kindred]

First...  Yes, that WAS the "policy".  We have since reviewed and revised it given the difficulty in maintaining a code base which is so outdated and can't even support several of the patches to keep up with current versions of server softwares. Additionally, it is time for people to consider upgrading sooner rather than later, because of that, amongst other things.

Second...  2.1 actually does have an ETA. Such a date has just not been released to the public, per our normal policy of not declaring dates.

[Ferny]

Hello!

I think there is something wrong in the upgrade package from 2.0.8 to 2.0.9. It's about the second operation in "$sourcedir/ManageServer.php":

Code: [Select]

<operation>
<search position="before"><![CDATA[
$context['config_vars'][$config_var[1]]['value'] = unserialize($context['config_vars'][$config_var[1]]['value']);
]]></search>
<add><![CDATA[
$context['config_vars'][$config_var[1]]['value'] = !empty($context['config_vars'][$config_var[1]]['value']) ? unserialize($context['config_vars'][$config_var[1]]['value']) : array();
]]></add>
</operation>
It should be position="replace" instead of position="before", right? I saw some errors in the log after upgrading (I can explain the details if necessary), and after manual fixing they are gone.

That file is OK in the install and upgrade full packages for 2.0.9 (just the upgrade package is wrong).

Regards