>>>>> "Jim" == Jim Popovitch <[EMAIL PROTECTED]> writes:
Jim> Stephen J. Turnbull wrote: >> Oh, if you prefer windstorms, hurricane is a bad analogy. Far >> more accurate is "tornado".<0.1 wink> Jim> Hurricane is the most accurate analogy, because with Jim> hurricanes nobody knows about them until the NWS (at least Jim> here in the USA) informs them The reason nobody knows until they're told is because they haven't thought to google for "satellite weather photos".<wink> One reason I say that hurricanes are a bad analogy (besides the fact that they're not sentient, while even script kiddies are sentient) is that they're big and they trash everything in their path. Of course it makes sense to invest in a press office to make announcements about them. Furthermore, non-specialists have a strong interest in the news, because they have options---they can board the windows and run away. This is not the case with Mailman; only specialists (sysadmins as well as developers) can do anything about it, and they should know where to find the equivalent of satellite weather photos (CERT, SecurityFocus, etc). Here, we have a vulnerability; in this case the exploit is obvious, but who is really going to exploit it? Furthermore, if you just keep daily stats on the size of the queues, you'll almost certainly catch it before it's a real problem, unless you're using lists for time-sensitive information. But in that case you'd better be set up for hourly reports, anyway. While there are profitably exploitable defects, most defects are like this one. Is there really much benefit to keeping everyone up to date? No. Now consider a moderately dangerous bug, like the path-traversal bug. *It wasn't a Mailman bug, Mailman cannot enforce access control.* If you announce this bug, and how to work around it, you've exposed the bug in Apache to the world. If the Apache developers don't have a fix ready to deploy, this is very dangerous. Even if you don't mention Apache, the black hats see your announcement and realize (1) Mailman is not a webserver; (2) the path traversal bug must be in a webserver; (3) they see how it works through the countermeasure taken. Mailman has just published a way to exploit Apache. Of course not all cases are like this example, but determining what kind of case it is, and what information others are likely to consider sensitive (including asking them), is time- and attention-consuming. Jim> You mis-characterize (yet again?) what I am saying. I am not Jim> advocating for the developers to work more, or differently. But you are. I've worked on such fixes (a rank amateur, but I was who was available), and I've seen pros at work. You consistently assume that the developers already possess the information you ask for; I see no reason to believe they do. Even the small amount of information you say you want takes a fair amount of attention to produce. If there are two developers involved, they'll undoubtedly have different cost estimates, so there needs to be a meeting. If there is another project involved, there will have to be a national election<wink>. In a free software project, it's reasonable to say that the only tasks where reliable schedule estimates can be made are those that are already finished. Release of security-related information is yet more controversial (witness this thread). More meetings.... Jim> That is an option that I reserve the right to make the Jim> decision on. Don't remove my capability to make that decision Jim> by hiding the info. >> Neither I nor you have any *right* in the matter. Jim> Huh? re-read my comments. I reserve the right to shut my Jim> Mailman system down, for any reason, at any time, Jim> lack-of-a-workaround or not. No, you re-read your comments. "Don't remove" is an imperative phrase in the English language. Your use of the imperative mood is sufficient justification for assuming you think you have some rights in the matter of receiving information. Elsewhere you talk about what you "expect", which corroborates that inference. Jim> Why should Mark/Barry/Tokio trust me anymore then the next Jim> guy? They shouldn't. I'm saying that there are a number of alternatives. One of those is for you to contribute enough (and otherwise show reliability) to become trusted. If you want to ask them for "off the top of their heads" estimates, you'd better be trustworthy, because they're in too much of a hurry to think carefully about what they're saying. >> I really have to disapprove of the way you consistently >> deprecate costs that others incur, while inflating those that >> you face. Jim> You need to re-read what I've been writing. I've read what you've written carefully, see above for evidence. You may need to be more careful to write what you mean more precisely, but that's not my problem---it's hard enough to respond accurately to what's there in black and white. Regarding the inflation of costs, you imply that schedule estimation is costless and accurate enough to save you from overtime work. It is neither. I've told you so, and you simply ignore that. That is deprecating others' costs. Note that you are quite welcome to back up your opinion and contest mine; I'm not Watts Humphrey. You simply haven't tried. I'd ignore you, but there are altogether too many people out there who believe the things you do, and your statements (especially the implicit ones) should be debunked. As to inflating your costs, that's a lot more controversial, and in the end you're the expert. But given that for a project like Mailman security risks are fairly rare (a couple times a year at most), I suppose it comes out in the wash with all of Mr. Murphy's other attacks on your spare time. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp