Re: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Sorry about the double post. It looked like the other one went out with the original non-subscriber address. -Paul Paul Speed wrote: [reposting from my subscribed account] [snip] -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a commiter I voted +1 if the discussions on the list where ONLY about security and not features and others devel related subjects. It shouldn't be a 'behind closed doors' discussion area. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Since the discussion will be about security, we could send a digest in the CVS fixes as soon as the thread has been closed and problems fixed. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Paul Speed wrote: Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's :-) Yes, I think I know what you mean. Trust me, you're not the only one who things that, and 'closed doors' is the last thing I want. I see it more like an 'open doors' situation ( private Cc: - a larger group ). already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for No, I just sugested that it would be nice to avoid some of the incidents that happened in the past. I admit - in most cases I do send a private mail to the person and few private mails to some other commiters to ask their opinions. Jumping directly and making the proposal is not the best strategy IMO, and at least I never did that without at least a second opinion. So the only thing that will change is having this 'do you think it's a good idea' sent to everyone. And avoid 'no, I don't think so because ...' in the public list. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) I agree for most part. And I think that an all-commiter list is better than Cc: chains with few people, it's more inclusive and better for everyone. Regarding all-messages to the list - I agree, all information should get to tomcat-dev, ( unless whoever posts it wants to keep it private ). One of the reasons Cc: is used is because some people don't want certain issues to become public ( for example me asking Remy really dumb questions on JNDI :-). I think it would be better if most of the Cc: will go to the commiters list, and most of the commiters list will go to tomcat-dev. Both are improvements over current situation IMO. And besides - if someone really wants to be on the commiters list, there is a way to do it, and we are all happy to get more people involved ( and on the list ) :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
It sounds like there is already a closed forum for discussing security, CC'ing all who might be interested. Making it a list just makes lives easier for all involved, and the whole thread is not lost and always exclusive only to those CC'd. (If the messages are eventually forwarded to the dev list or archived). People are saying that they are worried about something that is already going on, in a slightly different form. As long as the committers are responsible with this other list, things should only be better. Maybe the automatic forward (with a delay) will serve to keep everybody responsible on into the future. How hard is that to set up?? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 10/17/02 8:14:59 AM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Costin Manolache wrote: Paul Speed wrote: Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's :-) Yes, I think I know what you mean. Trust me, you're not the only one who things that, and 'closed doors' is the last thing I want. I see it more like an 'open doors' situation ( private Cc: - a larger group ). Phew. I feel better already. Seriously. already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for No, I just sugested that it would be nice to avoid some of the incidents that happened in the past. I admit - in most cases I do send a private mail to the person and few private mails to some other commiters to ask their opinions. Jumping directly and making the proposal is not the best strategy IMO, and at least I never did that without at least a second opinion. So the only thing that will change is having this 'do you think it's a good idea' sent to everyone. And avoid 'no, I don't think so because ...' in the public list. Yeah, I see where you're coming from, but some of that should end up public. Fine line. For example, let me paint a (hopefully) brief picture. I'm probably one of your more avid non-committers: I still read (and to some extent participate) even though I haven't used tomcat professionally in over two years. I've been on the list for maybe three years... lost count. During a period of unemployment a year ago, my itch was to bring the SSI stuff up to spec and so I mostly rewrote the SSI servlet and associated classes. These were accepted and committed to head. All was well and even kept up on recommending people stay away from the older version when issues would crop up in bugzilla. Eventually I got a job and spent a few months off the list. During that time someone else also found the old SSI code lacking and rewrote it again without ever noticing that there was alreay a newer better version. Unfortunately, the committers didn't notice either and all of my work was blown away. Sad, but such is life sometimes. Anyway, long story short, this person was made committer shorlty after that, persumably just to maintain the SSI code. There was some controversy on this list at the time about whether or not this was appropriate since there hadn't been many other contributions from said person. If I hadn't witnessed this conversation, it really would have added insult to injury when they were made committer. Instead, it was no big deal at all other than a little disappointment. So, that's probably why your earlier committer vote proposal comment grabbed my interest in this thread. Ok, so not brief. Oh well, -Paul As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) I agree for most part. And I think that an all-commiter list is better than Cc: chains with few people, it's more inclusive and better for everyone. Regarding all-messages to the list - I agree, all information should get to tomcat-dev, ( unless whoever posts it wants to keep it private ). One of the reasons Cc: is used is because some people don't want certain issues to become public ( for example me asking Remy really dumb questions on JNDI :-). I think it would be better if most of the Cc: will go to the commiters list, and most of the commiters list will go to tomcat-dev. Both are improvements over current situation IMO. And besides - if someone really wants to be on the commiters list, there is a way to do it, and we are all happy to get more people involved ( and on the list ) :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Vote results + Security Audit redirection
From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Vote results + Security Audit redirection
At 10:46 PM 10/16/2002 -0700, you wrote: There was also some comment about other special issues, which has not been clear to me yet. It's not clear to me either :-) Maybe short notices like I want to propose X as a commiter, does anyone has any objection ? - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. So, essentially, this is a vote for an open ended, closed, decision on what the committers decide is covered by the vote? Seems to me that, if people are going to put in time to become a committer, and I am spending a lot of time right now familiarizing myself in order to begin to help, they ought to be in on these unpleasant things that may affect them. I appreciate that sometimes things are unpleasant. But, open source and closed discussions are not exactly in tune. That is especiallys so when the closed discussions are open-ended. Just my two sense. I would suggest that you have the vote only on the issues that are articulated, and not on issues that will be articulated in private. Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Vote results + Security Audit redirection
Costin Manolache wrote: IAS wrote: I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. The problem is when the bad people find out about the security problems before they are fixed. I'm not saying that anyone subscribe to tomcat-dev is 'bad', but the list is archived and google searchable and has a lot of subscribers. All information will become public - it's just that I think it is better ( at least for the bugs we discover ) to first have a fix. You probably noticed most of the announcements on security issues from apache and many other organizations include a fix or at least workaround. It is a common practice to have the security issues forwarded first to some commiters, and then made public. And I think this should be true not only for bugs found from outside, but also from inside. There was also some comment about other special issues, which has not been clear to me yet. It's not clear to me either :-) Maybe short notices like I want to propose X as a commiter, does anyone has any objection ? - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. Except, this is exactly the kind of thing I think should stay on this list. A slippery slope indeed. Maybe all tomcat-dev traffic should be vetted through this other list first and posted here at a 1 to 2 week delay, just in case something is mentioned that might turn out with analysis to be a security risk. The more security through obscurity the better, right? ;) The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. I think the only way you can keep the new list from feeling like a double secret exclusive club is to forward _all_ traffic at some delay and keep that traffic to a minimum. Otherwise, it's going to start feeling an awful lot like some of you felt when working for Sun were having extended offline discussions that eventually just popped up here as a pre-resolved proposal/issue. Wish I could site a specific case, but it was a while ago. It will be as frustrating as waiting for a JSR public draft. Sorry, I didn't mean to go on so long originally. There's just something about all this that worries me a bit. Perhaps because noone else seems particularly concerned. Oh well, what do I know. -Paul Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. Same for me. My main goal was to get all active commiters involved in future security issues. We are all equally responsible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Vote results + Security Audit redirection
-Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache Sent: Wednesday, October 16, 2002 7:46 AM To: [EMAIL PROTECTED] Subject: Vote results + Security Audit redirection It seems the vote on a tomcat-commiter list got a majority - unless all inactive commiters start voting -1. Craig/Sam - please create the list or let me know who can do it. The intention is to have all active commiters in asap. As soon as we get the list, I think we should move the [Security Audit] and the other thread to it. Being sorry to interrupt you and not even a committer, I don't fully understand what [Cc] threads mean and do negatively. (Would someone mind explaining more or less about that?) We can forward the mails to the public list - but I would like to have the fixes in CVS and the potential releases before the information gets public. I'm all for full disclosure and public exploits - but at least if we find the bugs, we should fix them before making it public. I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. There was also some comment about other special issues, which has not been clear to me yet. What are criteria of distinguishing committer-closed special issues and developer-open common issues? (I'm able to infer security must be one of the criteria, though.) I think some agreement among tomcat dev mailing list should be made before an issue is into tomcat committer-only mailing list. Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] IAS Independent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Vote results + Security Audit redirection
IAS wrote: I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. The problem is when the bad people find out about the security problems before they are fixed. I'm not saying that anyone subscribe to tomcat-dev is 'bad', but the list is archived and google searchable and has a lot of subscribers. All information will become public - it's just that I think it is better ( at least for the bugs we discover ) to first have a fix. You probably noticed most of the announcements on security issues from apache and many other organizations include a fix or at least workaround. It is a common practice to have the security issues forwarded first to some commiters, and then made public. And I think this should be true not only for bugs found from outside, but also from inside. There was also some comment about other special issues, which has not been clear to me yet. It's not clear to me either :-) Maybe short notices like I want to propose X as a commiter, does anyone has any objection ? - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. Same for me. My main goal was to get all active commiters involved in future security issues. We are all equally responsible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Vote results + Security Audit redirection
It seems the vote on a tomcat-commiter list got a majority - unless all inactive commiters start voting -1. Craig/Sam - please create the list or let me know who can do it. The intention is to have all active commiters in asap. As soon as we get the list, I think we should move the [Security Audit] and the other thread to it. We can forward the mails to the public list - but I would like to have the fixes in CVS and the potential releases before the information gets public. I'm all for full disclosure and public exploits - but at least if we find the bugs, we should fix them before making it public. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
