It’s great to see that the habari guys are committed to security as well as functionality and are providing security updates for there pre-1.0 software. It is a pity to see that they don’t disclose much in there security announcements.
For me, responsible open security practises should mean that as well as providing a quick response to security issues you provide enough detail about the issue to your users to allow them to make a judgement call about how important the upgrade is to them. Do they need to do the upgrade immediately because the issue is easy to exploit or can it wait till the weekend when they have more time to ensure they have a backup and a plan for when the upgrade goes wrong.
The WordPress project tries to provide this information and we provide clear security release announcements on the development blog which is syndicated into everyones dashboard. The habari project however seems to be happy with a release announcement which basically says – “Hey, you blog is vulnerable to some critical security issue but we fixed it for you upgrade now!“.
For example in the WordPress 2.6.2 announcement we have:
Stefan Esser recently warned developers of the dangers of SQL Column Truncation and the weakness of mt_rand(). With his help we worked around these problems and are now releasing WordPress 2.6.2. If you allow open registration on your blog, you should definitely upgrade. With open registration enabled, it is possible in WordPress versions 2.6.1 and earlier to craft a username such that it will allow resetting another user’s password to a randomly generated password. The randomly generated password is not disclosed to the attacker, so this problem by itself is annoying but not a security exploit. However, this attack coupled with a weakness in the random number seeding in mt_rand() could be used to predict the randomly generated password. Stefan Esser will release details of the complete attack shortly. The attack is difficult to accomplish, but its mere possibility means we recommend upgrading to 2.6.2.
Comparing this to the recent habari annoucement:
The Habari Community announces the release of version 0.5.2. This version is a critical security update; all users of any version prior to 0.5.2 should upgrade at once. Additionally users of HEAD should also update to the latest revision.
Thanks are due to the entire community for identifying and patching this bug in a timely manner.
This isn’t very detailed and leaves me wondering – What was the issue? How serious was it? Is the issue such a bad example of security aware development that they don’t want to highlight how wrong they got things?
Don’t get me wrong, I am please that security matters for the habari project and I know the difficulties involved in developing secure software, I just feel that you need to be open with your issues to build trust with your users.
Update: There is now a much clearer release announcement for habari v0.5.2.
I understand your point about letting users decide by themselves whether they want to upgrade or not. However, I think you’d agree with me that by exposing the details of the vulnerability, we would be risking to put blogs running the upgraded version of Habari “in harms’s way”.
Giving the nature of opensource, a slightly experienced developer can figure out -from the publicly available commit log- what the vulnerability was. But by directly detailing the particular vulnerability and how to exploit it, we would be increasing the odds of a Habari-powered blog getting attacked.
I don’t think it makes sense to conclude that a strategy like this is about hiding bad coding, because as I mentioned all commit logs are publicly available.
In Habari’s development model, and apart form nominating new PMC members and majour security issues, everything is done in the wild. There are no off-record discussions nor off-record fixes patches. And my personal opinion and experience obliges me to state that I rarely ever been an an open source project open like Habari.
Thank you for your opinion and advise, I will make that I bring it up to the community’s attention in hopes to come up with a way to provide more information on security issues while keeping malicious users as much in the dark about these as possible.
As you noted, we’re still early in our development cycle. We haven’t yet formalized our security policies, and at the present time, we’re still trying to find the balance between the openness we desire, and the need to not disseminate information on how to compromise a Habari site that hasn’t been upgraded. Hopefully we’ll find that balance in the near future. (Actually, hopefully we’ll catch the issues before they’re in the wild, so we won’t need to find that balance. But I don’t think that’s completely realistic.)
Any suggestions you might have for achieving that balance would be appreciated.
Ali and Morydd. Thank you for the feedback.
Firstly, I would like to say that the updated release announcement that is now available does in my opinion strike the right balance between open disclosure and protecting the users who have not upgraded.
Hiding the detail of a security issue from your users but leaving it open to the code savy does your users a disservice because as the code changes are available in the open any hacker has all the information available that they need to create an exploit. In that scenario the user is disadvantaged and the hacker has the upper hand. By providing a terse description of the issue you bring the user back onto a level with the hacker in there ability to understand the criticality of the upgrade.