Re: Calysto v1.5 reports on openldap_v2.4.4alpha

[Pierangelo Masarati <ando@sys-net.it>]

Kurt Zeilenga wrote:
> Speaking as an individual participant in the OpenLDAP Project...

>> You posted to the openldap-bugs mailing list.
> 
> Which I think is the right place to start with such reports.  His
> message indicated he wanted to discuss potential bugs.

In fact, I'm glad he didn't file an ITS with that bug list.

>> This list is for
>> discussion about bugs; but to track issues, like a bug report (as yours
>> seems to be) you're supposed to file an ITS using the ITS interface
>> <http://www.openldap.org/its/>.  This is necessary to keep track of the
>> status of your submission, otherwise it's just a bunch of emails,
>> eventually destined to the bin.
> 
> I rather not flood ITS with potential bugs.
> 
> I rather the potential bug list be discussed on -bugs first and upon
> determining there is a signficant bug, reporting that bug as an ITS,
> preferably with patch.

I'd rather avoid a list of potential bugs at all.  But, if it has to be
processed, I'd like it to be on the ITS, so we can track it(s consequences).

>> When you submit a bug, you can mark it as PRIVATE.
> 
> If the its a "major security issue".  If one detects a buffer overrun
> condition, that would be reasonable to report as a major security
> issue.  However, a simple crash (deref NULL) is not.

I concur.  I was speaking of about __after__ real bugs are filtered out
of the list.


> If the original report would have been filed as a "major security
> issue", I suspect it would have been rejected as not being indicative of
> a major security issue.

Yes.  See above.

> Also, it inappropriate to file multiple issues
> in one report.  If there is some particular major security issue, it
> should be filed separately.

Yes.  See above.

> And given the nature of these kinds of issues, there is really no point
> in keeping them private.  We should assume attackers have static
> checking tools.  We should assume such issues are public knowledge.

OK.  It's like not locking a bike because real burglars can easily open
locks.

> And even if they were filed as private, it truly a major security issue,
> it would in all likelihood be fixed immediately.  Once fixed, the
> private flag would be lifted.  This would happen so fast for most every
> issue discovered via static checking making the private flag pointless.

... but the release with the bugfix could take days.

> That is, the private flag should only be sit with the issue is truly a
> major security issue AND it likely that issue will not be fixed
> immediately.

Yes.  So it has to be considered on a case by case basis.  But I'd
rather leave both judgments to the Project and, to be conservative, have
a couple false privates more rather than less...

In any case, I think we have the same opinion about the use of the ITS
and of the PRIVATE flag.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------