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 ---------------------------------------