[Date Prev][Date Next]
Re: Calysto v1.5 reports on openldap_v2.4.4alpha
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
> 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
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.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172