[Koha-devel] Koha Library Software

[Robin Sheat]

Op maandag 6 juni 2011 20:34:17 schreef MJ Ray:
> So let's document the current practice and make it easier?  Changing
> the process, adding more steps and special bug cases seems wrong.

No it doesn't. (If you can claim something in that manner, so can I :)

> Delayed disclosure (the neutral name for what you describe, because it

That's not neutral at all.

> is highly irresponsible in the eyes of full-disclosure supporters) has
> often gone too far and resulted in people trying to keep problems
> secret for far too long, like until every vulnerable system is
> patched.  

Well then you establish a policy that doesn't have those issues. Problem 
solved.

> There are also the risks that someone inside the privileged
> group leaks information to attackers, while good people outside that
> privileged group don't even know that there's a problem.

If you release everything in a full disclosure manner, you give the attackers 
information without getting it (and a fix) first to the people who have 
something to defend and will require a bit of time to do so. I think that's a 
bigger, actual risk than a hypothetical risk of disclosure. If you discover 
it's already in use in the wild, then you release immediately, falling back to 
full disclosure mode. Best of both worlds.

> Basically, what type of people are we?  Would we tell our neighbours
> that their homes are insecure when there's a burglar about?  Or would
> we keep quiet until we figured out how to secure our own home first?

You're making a strawman argument. In particular the "there's a burglar about" 
bit. In this case, there isn't.

> As far as I know, early all of the vulnerabilities that Koha has
> suffered have been discoverable with fairly simple tools if you knew
> where to point them - 

Yes, but (afaik) they are generally discovered long after they're implemented, 
which suggests that this doesn't happen a lot.

> most have needed some access to intranet or
> related websites, thankfully.

That's more good luck than good management.
 
> I don't think there is any such standard (got a link?).  Yes, many
> "open source" projects are really closed when it comes to security,
> but popularity is not a good argument for something, else Koha would
> almost never be adopted.

They're not closed. They're just not so open their brains fall out. They (in 
general, and I'm sure there are pathalogical examples too) simply try to 
ensure that a fix is available at the same time the attack information is 
available. 

Personally, I'm something of a fan of something along the lines of the policy 
described here:
http://web.archive.org/web/20100813161135/http://www.wiretrip.net/rfp/policy.html

As an example, if you report a security issue on the Mozilla bug tracker, the 
bug is closed by default until a fix is released. Then it's opened.
http://www.mozilla.org/projects/security/security-bugs-policy.html
This is far more involved than anything I'd suggest for Koha however. My main 
concern is to avoid the world at large knowing how to exploit Koha before 
anyone can quickly work around the issue (I might know how to mitigate a SQL 
injection, but I go to one or two security conferences a year. Not everyone 
does.)

> The disagreement between full and delayed disclosure has been going on
> in general for at least 150 years, and over 20 for internet security.
> We're probably not going to change each others' views, but at least
> know that not everyone wants delayed disclosure.

As someone who deploys Koha systems, I'd like to see a release of a fix with 
an announcement so that I know I need to update now, and the information 
required to do so is immediately available. If it's a difficult fix, then I'd 
consider something that mitigates the issue to be acceptable.

-- 
Robin Sheat
Catalyst IT Ltd.
✆ +64 4 803 2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/koha-devel/attachments/20110607/562f35ad/attachment.pgp>