Thread

@artminister - We definitely want to improve a lot when it comes to the upgrade process in terms of the experience it provides, but you’ve had PHP errors for each and every upgrade you’ve performed? I’m not questioning your claim, just agreeing that it’s certainly a problem. I’d be upset too. Mind shooting an email over to .(JavaScript must be enabled to view this email address) so we can discuss some of the particulars?

@Travis - There’s one particular condition that has to be met for this bug to show itself, and that condition was unfortunately not tested by the devs before pushing the release out. We’ve added that condition to our list of automated tests, so it definitely won’t happen again. I should note too that our devs have been building on the automated testing suites that they created last year, and it only gets better as they add more tests to the suites.

@Rob - I haven’t had any trouble upgrading either, and I think it’s safe to say that the vast majority of people aren’t having trouble. That’s not much consolation for those who are having trouble though. If they have an upgrade that breaks, they’re experiencing the problem 100%.

@geekamongus - “EL is not keen about revealing specific security vulnerabilities”. Of course not. You wouldn’t want us announcing to the world how they can hack in to your system, would you? Believe me, you want us to be vague about security vulnerabilities and how we fixed them.

“More thorough bug testing before each release.” Agreed, and we’re doing just that. Like I noted with Travis above, we’re running automated tests in addition to the human-powered kind, and the library of automated tests only becomes more and more thorough as time wears on. We just keep adding more and more tests to it.

@Travis again! - The version numbers we use actually have a meaning, though I’m not sure it’s been officially published anywhere. Any change to the number after the first point (2.X) is a release with new features and will possibly include security patches and general bug fixes as well. Any change to the number after the second point (2.5.X) is a maintenance release that will include, at most, security patches and general bug fixes. Maintenance releases do not include new features. Anytime we do need to release a high priority security release, you’ll know. We’re very vocal about it. I honestly think that’s only happened twice in our entire history.

We likely won’t be going down the route of issuing public betas again, but we do actually have preview releases that go out to some of our third-party developers ahead of time to allow them to test their add-ons against it and provide any other feedback they may have.

@all - We’re speaking in generalities here, but I’d love to be able to address the specific concerns you have. The only way to let me help you is to know the specific issues that are plaguing you! Please email me at .(JavaScript must be enabled to view this email address), so we can talk about it.

Thanks everyone!

@Kevin Smith: “What could I do to delight you here?”

If it wasn’t clear from my earlier posts,  what would make me happy,  is that your team could find a smarter way to roll *known* bug fixes,  found and fixed since the initial point release,  into the downloadable distro.  If after releasing a point release you find one file has a bug known and reported,  that either the whole package is updated immediately,  or you figure out how to release just the update patch files. 

That,  and either do more human testing,  or fix your automated testing,  as they’re missing obvious (and oft reported upgrade) bugs. 

Lastly,  the support forums should not be where support requests go to die.  Ask around and you’ll find many, many EE developers who most often turn to social media for peer support,  due to lack of official support on which we can rely.   

All the best,

Ira @ The Red Eye

@geekamongus - “EL is not keen about revealing specific security vulnerabilities”. Of course not. You wouldn’t want us announcing to the world how they can hack in to your system, would you? Believe me, you want us to be vague about security vulnerabilities and how we fixed them.

Well, see, that’s the attitude that is the nature of the problem here. Security through obscurity is not good security. All you have to do is analyze the code differences between 2.5 and 2.5.1 to see what was changed - a small task for a savvy hacker - and then you’ve got yourself an exploit to go use on those that are waiting to upgrade to 2.5.1 because they fear bugs.

Therefore, it stands to reason that it would actually help to disclose the vulnerability so that users can quickly patch it, then upgrade to the latest version of EE when the bugs are worked out.

To circumvent this problem, adopt a full-disclosure policy, tell users a vulnerability has been found, and give them a way to fix it with a quickly applied patch. It’s the best way to keep your user base secure as soon as vulnerabilities are discovered.

Security through obscurity is not good security… Therefore, it stands to reason that it would actually help to disclose the vulnerability…

We agree; security through obscurity is a security blanket that provides no warmth. And we do publish that there is a cross-site scripting vulnerability, or a privilege escalation issue for sites running Foo, or that a certain tag’s parameter was not being properly sanitized, etc. What Kevin means is that we do not provide step by step instructions, for example the full circumstances and sample input for an attack.

...we do not provide step by step instructions, for example the full circumstances and sample input for an attack.

I’m not looking for how to re-create the hack… I’m looking for (specifically) how to patch it.

At this moment, I have a web site that has an old version of EE running on it:

1.  I am vulnerable to said exploit.
2.  I don’t have time to patch your code in order to install the security fix.

(because there is no easy way to get a concise list of critical bugs for a given release… so I have to sort through the bug tracker and evaluate issues presented in the forums to determine what should be patched)

@ira42 - Thanks for clarifying what you’re looking for from us. I’m sorry we’re not going to be able to make you happy. An immediate release every time a bug is fixed not only isn’t a good idea—and would beget threads of frustration about us releasing too often—it would be impossible to achieve given that you want us to more thoroughly test. Those two goals stand in pretty stark contrast.

But like I said, a huge goal of ours is better testing, and it’s an ongoing effort. That doesn’t mean that mistakes won’t ever happen, but our new testing processes do allow us to be increasingly more thorough with every release. We’ve seen that to be true. The latest releases of EE have been the most stable we’ve ever released. This particular release had a few bugs that created a big problem for a small percentage of our users. I’m not trying to downplay or ignore how that affected those users. Just keeping things in perspective. (And yep, we’re aware of the aforementioned bugs, and we’re working on a solution right now.)

@all - If your experience with EE’s recent releases is something other than what I’ve described, I’m serious, I do want to hear from you about your particular experience. Please email me at .(JavaScript must be enabled to view this email address).

Hey everyone,

It’s not yet been publicly announced (Robin’s working on getting that together), but I just wanted to give you all a heads up that we just released EE 2.5.2, an update with several nice bug fixes including the one that inspired this thread. It’s available in your downloads now!

Thanks guys,  and I’m happy to say that the EE 2.5.1 -> 2.5.2 upgrade completed without errors! 😊

And I can appreciate that you wouldn’t want a new point release for each reported bug.  But when it’s a clear case,  one error in one file,  is there NO way to simply rebuild the Zip distro file with the fix?  Or implement a download section for patches (changed files only)? 

Might not be for everyone,  but often the issues have been identified in the Bug Tracker,  and the changes to a file or two documented in the bug report.  It would be great to have a list of all updated files for a given build in one place, or in a patch file. 

Anyhoo,  thanks for keeping the dialogue open.  And feel free to close this thread as the issue is resolved.  Cheers!

But when it’s a clear case,  one error in one file,  is there NO way to simply rebuild the Zip distro file with the fix?

I’m not sure this would be a good idea since the version number needs to signify that the code contained in the download is frozen at a certain point in the development. If we change the code at all, we change the version number. (That’s a constant you can always rely on.) Can you imagine the frustration it would cause if a given bug may or may not be fixed in your 2.5.1 installation depending on the day you downloaded the 2.5.1 release? I know that would irritate me.

Or implement a download section for patches (changed files only)? 

Might not be for everyone,  but often the issues have been identified in the Bug Tracker,  and the changes to a file or two documented in the bug report.  It would be great to have a list of all updated files for a given build in one place, or in a patch file.

Right, you’re talking about delta releases. So if someone has their installation one version behind, they could just download a release package with only the changes made since the second most recent release. That’s not a bad idea. I’ll make sure the developers know about that request.

Anyhoo,  thanks for keeping the dialogue open.  And feel free to close this thread as the issue is resolved.  Cheers!

No problem, ira42! We’re always glad to help.