-
Website
http://brian.teeman.net/ -
Original page
http://brian.teeman.net/extensions/can-you-trust-your-joomla-extensions.html -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
However, this is both a pretty comprehensive list of reported vulnerabilities from the last 3 months and a good indicator that more needs to be done.
http://docs.joomla.org/Vulnerable_Extensions_Li...
Hosting on GForge is also bad in this respect as the md5sum is generated and not manual inputted, so if I change the file the md5 is automatically updated!
The correct way is to SIGN your files using a GPG Detached signature, the same way that linux package maintainers do :-) GPG is more secure than md5sum by a long long way...
I specificaly stated that the md5sum was stored on a second site.
The reason I did not suggest the linux way of GPG signing is because
that method of verification may not be available on all servers (as
you know only too well yourself) whilst md5 verification can be
written into the installer itself.
I have another wish for future handling of extensions: Let the developers push update info to the Joomla installation directly. This way, you will get notified whenever an installed extension is updated. And, even better, be able to update it on-the-fly.
You should go ahead and post it in the group.
I would love to see more security on Joomla! (among other few things).
That way extensions that are not listed on JED for various known reasons or are private extensions can still use the installer.
All the core [code] has to do is provide an event for a plugin to latch on to (I think they are actually in 1.6 - need to dbl check). The only obstacle then is the willingness for someone to run with the concept (or find someone that has already done - surely there is). I don't see this is something the "project" has to drive because of the broader applications.
You see it as a revenue generating idea and a service for the extension developer.
I see it as a service for the joomla user and as such it IS a role for the "project".
My point was that the project does not have to hold this up if, and they are at liberty to, disagree that it's a core function they have to provide. I was merely giving you an option that frees you from the shackles of waiting for the project to decide whether they considered it a good idea or not.
Whilst Joomla cannot be responsible for a users site being hacked, assuming the follow best practice, it still suffers from the backlash when the site is hacked. For that reason the "project" should be doing as much as is is feasible to mitigate the exposure of its users.
The onus is still on the user and the developer to write secure code and follow best practice but this is one small step the project can take to help.
If you don't think the two publshed cases I referred to in the original post are a big deal and effected only a few users, then think again. I've personally dealt with almost a hundred effected and infected sites as a result of just one of them.
If other projects wanted to adopt something similar they could of course, it's gpl ;)
If I could I would of course submit this concept as a white paper for central discussion
Also, if I didn't think it was a big deal, I wouldn't have said anything.
1) The JED needs to store all info on all versions released of all extensions. Which it should in the first case in my opinion, so that it can alert people when extensions need upgrades. Which brings me on to a related topic: The installer in J1.6 A2 seems to contain stuff that suggests someone have thought of this already?
2) Everyone needs to be able to use the JED, not just GPL extensions. It's either that or letting 3rd party directories handle the security checks as well, which kind of defies the point of it all.
A load of components out there aren't on the Extension directory (none of mine are, and I can't add them because they aren't GPL), so that will not work for those components :)
At the end of the day, no scheme put into play would ever be perfect, all we can do is look at ways to minimise the risk.
Automatically generated real-time (note: not cached) check sums (or other metadata) are actually a good thing because a service can monitor those and alert the developer the instance something changes (could be easily incorporated into any of the popular heart-beat monitoring services). Preventative action should be first on the list. Checks at download/install time should be the last line of defense.
I dont agree that its too late if this happens as until the extension is unzipped and installed nothing is executed. Hence the checks I propose take place before the archive is unzipped.
Preventiative action should be first on the list, no argument there, but right now they dont exist. Perhaps my solution is a band-aid but I believe it would work.
I think the basic suggestion is excellent, in spite of practical complications. It seems to me that all comments point out relevant aspects. Putting these all together one could (should!?) assume the JED to be a well protected and frequently backed up website which could be trusted as a trusted source for extensions listed in the JED. The core functionality as suggested could allow an additional third party source to be specified. This could be used by non-GPL extensions not listed in the JED, and perhaps someone feels like providing the third party service to non-GPL extension developers.
Someone could develop a service checking download checksums at the extension developer's download server, and perhaps someone will. But, amateur developers of free stuff, like me, will often not be prepared to pay for that service. In any case, I do not see why Joomla should wait for that, aside from practical issues such as time and priorities.
I wish the core would have some more tools like this to make security checks. It is a pity that Adam's work remains outside the JED, but it is a great pity that his Diagnostics has not become part of the core. JTS does a lot of good, but surely more can be done. Wouldn't it be a good idea to have the core check after each installation if an extension has all the index.html files in place and jexec do or die lines in php files? If fun things like Squeezebox can be put into libraries, why not some open source third party code checking for file changes? I presume none of the commenters here use a standard .htaccess file, so if the knowledge is there, why shouldn't the one in the installation package be a bit more nifty?
Perhaps in the past, it was valid to think that Joomla is the core on which good developers can build to make good websites with the help of good third party extensions. But now Joomla is successful in good part because it has reached the masses who use their mouse instead of code editors to set up websites. Large numbers means common denominators means user-friendliness if not idiot-proofing.
That is why I just wanted to stop by and say that the suggestion in this article is excellent.
PS: love the site Brian, by the way.