Domagoj Babic wrote:
Pierangelo,
I didn't understand the last part on marking submissions private. Pardon my ignorance. Could you please elaborate?
Please keep replies on the list.
For this purpose, the ITS allows to mark submissions as PRIVATE.
You posted to the openldap-bugs mailing 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.
When you submit a bug, you can mark it as PRIVATE. This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities.
For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest.
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 ---------------------------------------
Pierangelo,
On 8/21/07, Pierangelo Masarati ando@sys-net.it wrote:
You posted to the openldap-bugs mailing 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.
When you submit a bug, you can mark it as PRIVATE. This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities.
For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest.
Ok, thank you a bunch for the clarification.
This might be especially relevant to buffer overrun checking (that I'm planning to introduce in the future).
However, Kurt, on the behalf of the OpenLDAP Foundation, explicitly stated that the foundation is not interested in having the code statically checked, so I won't be sending reports (except for one more I have already generated).
Once Calysto becomes publicaly available, you might actually get in a position where other people will be capable of finding exploits automatically --- every great technology has its dark side :-)
Cheers,
Domagoj Babic wrote:
Ok, thank you a bunch for the clarification.
This might be especially relevant to buffer overrun checking
exactly
However, Kurt, on the behalf of the OpenLDAP Foundation, explicitly stated that the foundation is not interested in having the code statically checked, so I won't be sending reports (except for one more I have already generated).
I don't think he said exactly that. I believe he said the project is not interested in receiving plain reports just for the purpose of debugging Calysto (nothing personal: only, we're just a few volunteers, and we cannot dedicate too much time in reviewing reports potentially filled by false positives). If you put some effort in separating what could be critical from what isn't likely, any report would be welcome.
For example, I'm reviewing your initial submission and, apart from what's directly related to the clients, there are a couple of reports that may require some action. I'll post about my findings later, on a private basis. Only, I'm not going to do this routinely and too often.
Once Calysto becomes publicaly available, you might actually get in a position where other people will be capable of finding exploits automatically --- every great technology has its dark side :-)
I know. That's why I'm not going to entirely decline the reports you offered to submit.
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 ---------------------------------------
On Aug 21, 2007, at 1:27 AM, Pierangelo Masarati wrote:
Domagoj Babic wrote:
Ok, thank you a bunch for the clarification.
This might be especially relevant to buffer overrun checking
exactly
However, Kurt, on the behalf of the OpenLDAP Foundation, explicitly stated that the foundation is not interested in having the code statically checked, so I won't be sending reports (except for one more I have already generated).
I don't think he said exactly that.
He's (mis)characterizing what I said in a private email. I have separately posted clarification.
I believe he said the project is not interested in receiving plain reports just for the purpose of debugging Calysto (nothing personal: only, we're just a few volunteers, and we cannot dedicate too much time in reviewing reports potentially filled by false positives). If you put some effort in separating what could be critical from what isn't likely, any report would be welcome.
I think is your mistake to some extent my earlier public comments. In particular, I was speaking then as an individual. I stated what I, personally, was interested in. Others may have different interests than myself. It was not my intent, in those emails, to speak for collectively for the Project. I leave that to Howard.
For example, I'm reviewing your initial submission and, apart from what's directly related to the clients, there are a couple of reports that may require some action. I'll post about my findings later, on a private basis. Only, I'm not going to do this routinely and too often.
Once Calysto becomes publicaly available, you might actually get in a position where other people will be capable of finding exploits automatically --- every great technology has its dark side :-)
I know. That's why I'm not going to entirely decline the reports you offered to submit.
As I noted in the recent message I sent clarifying the Foundation's recent action, it was the strings attached to his future reports that were declined.
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
On Aug 21, 2007, at 1:16 AM, Domagoj Babic wrote:
However, Kurt, on the behalf of the OpenLDAP Foundation, explicitly stated that the foundation is not interested in having the code statically checked, so I won't be sending reports (except for one more I have already generated).
I think this is a mischaracterization of the particular action the Foundation took (in off-list email).
The Foundation was presented with a offer to participate in a marketing program. As a matter of policy, such offers are to be rejected and the Foundation, hence, declined your offer.
It our correspondance with you, we noted that our statement declining your offer in no way impacts licenses the OpenLDAP Foundation has granted regarding the use and/or distribution of OpenLDAP Software. That is, you can continue to use OpenLDAP Software under the terms of the copyright and license statements. No special license is need to perform static checking of OpenLDAP Software.
Subsequent to this, you asked whether it would be okay to send an additional report to the list. The Foundation responded that you need no special permission to submit additional messages to OpenLDAP mailing lists.
To summarize: you made an offered reports with strings; we rejected the strings. No one has precluded you from submitting further reports for discussion. Just no strings, please.
Kurt Zeilenga, Executive Director The OpenLDAP Foundation
Kurt,
On 8/21/07, Kurt Zeilenga kurt@openldap.org wrote:
I think this is a mischaracterization of the particular action the Foundation took (in off-list email).
The Foundation was presented with a offer to participate in a marketing program. As a matter of policy, such offers are to be rejected and the Foundation, hence, declined your offer.
It our correspondance with you, we noted that our statement declining your offer in no way impacts licenses the OpenLDAP Foundation has granted regarding the use and/or distribution of OpenLDAP Software. That is, you can continue to use OpenLDAP Software under the terms of the copyright and license statements. No special license is need to perform static checking of OpenLDAP Software.
Subsequent to this, you asked whether it would be okay to send an additional report to the list. The Foundation responded that you need no special permission to submit additional messages to OpenLDAP mailing lists.
To summarize: you made an offered reports with strings; we rejected the strings. No one has precluded you from submitting further reports for discussion. Just no strings, please.
Heh, there are no free rides - you would like to get the reports, but you are not ready to give anything in return.
Years of research have been invested in Calysto (and its sub-parts, like Spear theorem prover), running checks takes significant computational resources, and finally, I spend significant amounts of my own time filtering and pre-analyzing the reports for you.
I asked for only two things: prompt feedback and adding logo to the web page. That's not _really_ a marketing request. Anyways, doesn't matter, there are plenty of other projects out there willing to collaborate.
I'd also like to reply to Pierangelo in this email:
On 8/21/07, Pierangelo Masarati ando@sys-net.it wrote:
I believe he said the project is not interested in receiving plain reports just for the purpose of debugging Calysto
Quid pro quo. I help you debug your code.
(nothing personal: only, we're just a few volunteers, and we cannot dedicate too much time in reviewing reports potentially filled by false positives). If you put some effort in separating what could be critical from what isn't likely, any report would be welcome.
I respect everyone's time and don't want to waste it with piles of false positives. The focus of much of research related to Calysto is to make it as precise as possible, meaning that there are already few false positives, and there will be even fewer in the future.
For example, I'm reviewing your initial submission and, apart from what's directly related to the clients, there are a couple of reports that may require some action. I'll post about my findings later, on a private basis. Only, I'm not going to do this routinely and too often.
Thank you for your feedback. I'll post you a private reply.
Cheers,
Domagoj Babic wrote:
Heh, there are no free rides - you would like to get the reports, but you are not ready to give anything in return.
I think in return we already give OpenLDAP software. That should be enough, IMHO. If the internet were made by narrow-minded persons like you (I guess it's not just you, there might be some company's policy behind), you wouldn't even have been able to contact us by email, because email wouldn't have existed, not to mention the rest.
Years of research have been invested in Calysto (and its sub-parts, like Spear theorem prover),
Same on OpenLDAP, not to mention the rest.
running checks takes significant computational resources,
Same as above.
and finally, I spend significant amounts of my own time
Same as above.
filtering and pre-analyzing the reports for you.
I asked for only two things: prompt feedback
and you got it.
and adding logo to the web page.
That's not allowed by the foundation's charter.
That's not _really_ a marketing request. Anyways, doesn't matter, there are plenty of other projects out there willing to collaborate.
You started this, no one invited you. Feel free to leave.
I believe he said the project is not interested in receiving plain reports just for the purpose of debugging Calysto
Quid pro quo. I help you debug your code.
Well, so what would be your interest in our project? If you offer me something I guess you do it for some purpose.
I respect everyone's time and don't want to waste it with piles of false positives. The focus of much of research related to Calysto is to make it as precise as possible, meaning that there are already few false positives, and there will be even fewer in the future.
You see, you need our feedback to debug your product.
Anyway I think with this series of greedy public messages you gave good advertising to your project. I wish you tons of customers.
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 ---------------------------------------
Hi,
On 8/21/07, Pierangelo Masarati ando@sys-net.it wrote:
enough, IMHO. If the internet were made by narrow-minded persons like
Thx for the characterization :-)
Well, so what would be your interest in our project? If you offer me something I guess you do it for some purpose.
Well, I certainly want to help the open source community providing a completely automated way to find some bugs. However, as long as the project is somewhat important and has a decent base of users, I don't really care which project it is. Currently, I'm seriously limited with computational resources and my own time, so I can provide regular checking for only several projects.
Considering the constraints, I have to choose those that provide prompt feedback and are willing to add the logo. Very simple rule, nothing personal.
I respect everyone's time and don't want to waste it with piles of false positives. The focus of much of research related to Calysto is to make it as precise as possible, meaning that there are already few false positives, and there will be even fewer in the future.
You see, you need our feedback to debug your product.
I do need your feedback, but not primarily for debugging.
Cheers,
On Aug 21, 2007, at 11:17 AM, Domagoj Babic wrote:
Kurt,
On 8/21/07, Kurt Zeilenga kurt@openldap.org wrote:
I think this is a mischaracterization of the particular action the Foundation took (in off-list email).
The Foundation was presented with a offer to participate in a marketing program. As a matter of policy, such offers are to be rejected and the Foundation, hence, declined your offer.
It our correspondance with you, we noted that our statement declining your offer in no way impacts licenses the OpenLDAP Foundation has granted regarding the use and/or distribution of OpenLDAP Software. That is, you can continue to use OpenLDAP Software under the terms of the copyright and license statements. No special license is need to perform static checking of OpenLDAP Software.
Subsequent to this, you asked whether it would be okay to send an additional report to the list. The Foundation responded that you need no special permission to submit additional messages to OpenLDAP mailing lists.
To summarize: you made an offered reports with strings; we rejected the strings. No one has precluded you from submitting further reports for discussion. Just no strings, please.
Heh, there are no free rides - you would like to get the reports, but you are not ready to give anything in return.
The Foundation is simply not willing or able to offer any consideration in exchange for contributions, yours or those of others. Contributions are expected to be made freely.
Over the years, has been offered many contributions in exchange for consideration. Without regard to the size or shape of the consideration, we've declined all such offers. As we decline your offer for contribution in exchange for consideration.
We also routinely reject requests for the Foundation or Project to join this or that effort. Our policy is that while individuals are free to join whatever efforts they might choose to join, the Foundation shall remain neutral to external efforts. The Foundation shall not play favorites.
Years of research have been invested in Calysto (and its sub-parts, like Spear theorem prover), running checks takes significant computational resources, and finally, I spend significant amounts of my own time filtering and pre-analyzing the reports for you.
Your comments, in my opinion, belittle not only the significant investment others have made to the OpenLDAP Project, but belittle the significant investments others have made in direct response to your contribution.
All investment, small or large, direct or indirect, in the OpenLDAP Project is appreciated.
Your contributions are appreciated.
I asked for only two things: prompt feedback and adding logo to the web page.
Regarding feedback. You are free to submit messages to project mailing lists or not, others are free to respond or not. The OpenLDAP Foundation can no more require you to submit a message than it can require others to respond to it. So the Foundation simply cannot, and will not, offer "prompt feedback" or even "feedback". What feedback is provided is provided by individuals as they freely choose to provide.
Regarding the logo. You ask for consideration (logo placement) in exchange for contributions. We reject contributions requiring consideration.
That's not _really_ a marketing request.
IIRC, it was you who first used the term "marketing" in this thread.
Anyways, doesn't matter,
We're certainly are not going to abandon our principles to gain your contributions.
there are plenty of other projects out there willing to collaborate.
No comment.
I'd also like to reply to Pierangelo in this email:
On 8/21/07, Pierangelo Masarati ando@sys-net.it wrote:
I believe he said the project is not interested in receiving plain reports just for the purpose of debugging Calysto
Quid pro quo. I help you debug your code.
quid pro quo [WordNet] n : something for something; that which a party receives (or is promised) in return for something he does or gives or promises [syn: {quid}]
Contributions here are expected to be made freely. That means you may not receive anything, you are certainly not promised anything, in return for the something you give. So, in that sense, there is no 'quid pro quo' here.
Nothing personal here as well.
Regards, Kurt
Speaking as an individual participant in the OpenLDAP Project...
On Aug 21, 2007, at 1:00 AM, Pierangelo Masarati wrote:
Domagoj Babic wrote:
Pierangelo,
I didn't understand the last part on marking submissions private. Pardon my ignorance. Could you please elaborate?
Please keep replies on the list.
For this purpose, the ITS allows to mark submissions as PRIVATE.
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.
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.
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.
This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities.
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. Also, it inappropriate to file multiple issues in one report. If there is some particular major security issue, it should be filed separately.
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.
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.
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.
For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest.
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
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 ---------------------------------------