July 2008
Working Group Spotlight: Joomla! Bug Squad
The Bug Squad is a great way to get involved with Joomla!
Written by Anthony Ferrara
The Bug Squad was started in December 2007 by Wilco Jansen in an attempt to help solidify and stabilize the 1.5 branch of Joomla!. We started with about 8 people (of which only 2 were members of the development work group). The team quickly proved its worth in the drive to 1.5.0 stable. By the time Joomla! 1.5 went stable, the team had grown to about 20 people of varying involvement.
Creating the Bug Squad involved a fundamental shift in development and maintenance. One of the key principles that the Bug Squad relies upon is that no change enters the code base without a series of tests. This test based development practice has really increased the quality and stability of the 1.5 branch.
This test based maintenance involves a series of stages. When a bug is reported, the first stage it enters is “open”. Open items need testing to either confirm that it is actually a problem, or determine if fixing the problem is in the scope of 1.5. Once an open item is confirmed to actually be a defect, the status is changed to “confirmed”.
Confirmed items are artifacts that are known defects, that need developer attention to fix. Developers who wish to fix items only need to look up the current confirmed items, and pick one to fix. Once they have fixed the problem in the code, the developers create a patch, and attach it to the artifact. The developer also changes the status to “pending”.
Pending items contain proposed fixes to issues. In this stage, members apply the proposed fix, and test that it not only fixes the intended problem, but also doesn't cause other problems. This stage can vary in length depending on the severity of the bug/impact of the fix. For very simple items, normally only 1 other person (aside from the developer who created the patch) needs to test it. However, for large or complicated items, the number of testers can easily reach 20 testers. Once a patch is tested adequately, the status is changed to “ready to commit” where a developer actually commits the code.
The real benefit of this “status” based system, is that people only need to give the time that they want. If someone wants to help out for 5 minutes per day, all they need to do is login, pick an item, and work on it for those 5 minutes. Because all necessary conversation is done on the tracker (Joomlacode.org), the need for large time commitments, or complex work flows is gone.
2008-10-16 21:44:55
2008-10-16 23:53:17
A question I posed in the forums here, and have asked around the server-admin communities, is should we be running suhosin (what many feel is a php security enhancement) when it conflicts with the flash uploader for J? Some have suggested that turning off session encryption is an answer, but in Brad's fervent call for better security on hosts, I am interested in what the community feels here... Is suhosin a viable security enhancement, and given that it conflicts with the Flash uploader, should we 'make it work' anyway?
2008-10-17 00:08:27
2008-10-17 01:39:13
2008-10-17 05:07:30
We are proud to state that we fulfill all the points stated above. All of our servers are equipped with PHP4&5, suPHP/suEXEC, Offsite Daily Backups, etc.
The only thing that we do not currently do is to update our client's Joomla site automatically as this may break some extensions deployed by their site. We only help them upgrade when requested.
2008-10-17 05:29:39
2008-10-17 08:27:03
2008-10-17 08:47:08
I can't see it in my configuration.
2008-10-17 14:20:08
2008-10-17 17:58:17
I know my hosting company (www.cartika.com) has disabled the flash uploader because they consider it a security vulnerability. It's really a pain, especially cause my clients don't know how to use an FTP client. However, if it keeps the site from being hacked, I don't mind.
2008-10-17 23:25:13
2008-10-18 13:51:28
If these installers are not keeping up to date then newcomers will be getting hacked while doing the installation. That isn't a great way to begin your Joomla experience.
2008-10-18 19:20:19
As for the others.. why don't you email them this blog post
2008-10-20 16:07:43
In spite of a "one-click" upgrade available to all our customers who used our "one-click" installer, far too many of our customers just don't do it. Like James, above, we don't *force* their upgrades (due to potential extensions/components issues, etc.), so there are always those running versions with know security issues.
I don't know how to get the message across to these users. Any suggestions are most welcome.
2008-10-20 16:43:04
2008-10-20 20:11:16
Developers and designers should keep this in mind when finding a host to put their clients site on. Don't just find them a cheap host, setup Joomla, and walk away. Remember, if they could manage updates and stuff, they would not have needed you to begin with.
Instead, try to find a reliable host that can take care of that client for you when you are done.
2008-10-20 20:13:22
For those Joomla users that don't keep up with updates (most of them), I do it for them with the explanation that there is a risk of extensions breaking and in that case there may be a charge if the fix takes a lot of time. (one reason why I try to keep number of extensions to a minimum on a site.) KISS.
Patching is mandatory, or should be, for all scripts, not just Joomla. Users need to know that one insecure site on a server has the potential to disrupt all on the server.
Security makes all of our jobs appear harder, but in the long run it is saving us from the horror of hacking and greater calamities.
2008-10-20 21:55:12
2008-10-21 05:41:11
Thanks for the laugh
2008-10-21 09:32:33
Even though we have all measures you mentioned in place on our environment, it is still hard to keep Joomla up to date manually. When you host e.g. over 20 Joomla (which is just a little bit), there is no automatic way to remotely check if all the installs on your server are up-to-date compared to latest J releases.
2008-10-22 09:40:00
There are still tons of software out there that was built on PHP4 should we kill all those web sites and tell them sorry you are out of luck? No it would not be good for them nor would it make any sense.
As far as the rest of his rant. PHPglobals on is not insecure. It is only insecure if you have a programmer that is too lazy to code his product correctly and sanitize his input. Which it seems the Joomla project is one of the worst at. It only matters if the programmer is too stupid or too lazy to write his code in the correct way so he depends on the server admin to secure his script for him, and if that is the case chances are he took short cuts in other places and will get hacked some other way. There are tons, pages after pages on the web on how to properly write code that sanitizes inputs. But it is easier to write one simple line than 3 lines that do it properly.
2008-10-28 16:18:30
Ever client from us, has the possibility to update his joomla version trough our update software for joomla. One Click and the lastest joomla version will be automatically installed!
Whatever, till today, there was never a joomla site hacked on our servers.
2008-10-29 04:55:14
So I dont think a simple call to action to hosting companies will have much effect if they need the same amount of pushing to fix security issues. I must say alot has changed and things are 1000% better in terms of the way the Joomla teams treats security which is excellent.
2008-10-29 04:55:58
1. Why does Joomla not allow you to change/set the "admin" username during install.
2. Why does Joomla still hardwire the administration side into a folder called administrator that cannot be easily shifted/renamed.
These 2 things wave a redflag for hackers (they now know where to try and hack into the backend and what the administrators username. All they need to do is hack around the authentication.
There is a well known fact in parking lots, when you park your car do not leave your valuables in view otherwise there is a chance the car will get broken into.
These 2 flaws are part of Joomla's valuables.
2009-02-05 16:10:32
I had many websites hosted with them and just to let you know, one of them had the tags removed as the domain was not renewed, only 5 days after renewing I set about having the name servers point again to the website. THEY LOST IT?!?! and refused any compensation. This was a £8000 website.
After asking them to back up another site I have with them just to see if this is what the problem is I discovered they actually do not run any backups at all, at any time. NEVER. This is however stated upon buying. So if you lose your stuff - It's gone. This is also illegal as there would be no tracking possible for any court case for say a pedophile and illegal images. A case is currently being perused.
The company was sold to them by a great team of people with real customer care. Those people were Duncard Pollard and Sarah Milsom. They have done nothing but use their names all over the website. I had been with Duncan Pollard and Sarah Misom when the company was theirs for 9 years. In just 1 year, they have just torn it apart.
In another example my main website went down completely for 1.5 weeks just because they did not KNOW how to successfully integrate from Microsoft 2000 to a Microsoft 2003 server...
You should go for another hosting company without fail. I hope you hear this information, so you do not feel the frustration, anger I have felt. They are incompetent, the service is terrible; they have a guy called John working there who really does sound like he is as slow as a tortoise in every sense and a guy called Rupert who seems to only be able to switch computers on and off every now and then.
If you have any questions please don’t hesitate to contact me: calvin@wackywindows.com
2009-03-03 21:11:14
www.hardwebcafe.net
cheap, excellent service and Joomla friendly.
2009-05-05 13:15:25
They are running MySQL 4.1.x on shared hosting. When I asked for an upgrade, it never happened.
Im trying to get a refund now, wish me luck. I will never use hosting based outside the USA ever again.
Joomla community, help by screening who gets listed or even mentioned when it comes to hosting. Siteground.com hosting is unsafe. Siteground joomla hosting is unsafe. Siteground web hosting runs MySQL 4.1.x as of May 5, 2009