Comments on: Responsible security releases

By: westi

westi — Sat, 18 Oct 2008 14:29:50 +0000

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.

By: Morydd

Morydd — Sat, 18 Oct 2008 13:36:03 +0000

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.

By: Ali B.

Ali B. — Sat, 18 Oct 2008 13:26:08 +0000

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.