>>>>> "Jim" == Jim Popovitch <[EMAIL PROTECTED]> writes:
Jim> Stephen J. Turnbull wrote: >> 5. Security patches are asynchronous, like earthquakes, they >> happen when they happen. Jim> Very bad analogy. Hurricanes would be better. There is Jim> plenty of potential for user-base warning before a patch is Jim> to be released. Oh, if you prefer windstorms, hurricane is a bad analogy. Far more accurate is "tornado".<0.1 wink> Let's look at the pragmatics. Are you suggesting that if on Friday at 4:45, a patch is developed 72 hours faster than the estimate, the developers should withhold the patch until the scheduled announcement time? Or that although the developers release the patch, site admins should wait until the scheduled announcement time to apply it? >> If the patch comes out on Friday at 4:45, I would cancel that >> dinner date with my daughter. Wouldn't you? What difference >> would notice on Tuesday that a patch is expected sometime on >> Friday make to that decision, anyway? Jim> Change "daughter" to "wife" and ask yourself how long your Jim> wife would remain if you kept canceling Friday dinner at the Jim> last minute. I thought about issues like that 35 years ago, when I decided to become a professor. This is one reason I don't regret that decision. Now, you may be "stuck" in your position for financial reasons, or because of the other more attractive aspects it presents, but I don't accept that that gives you a claim on the developers' evenings and weekends, even if users like you outnumber the developers 100:1. Jim> Now look at it from a business standpoint and try and Jim> convince my customers that they should expect their service Jim> to be down at any point in time to do unplanned system Jim> upgrades. Um? Redundancy, man. Either your customers pay for reliability, or you don't provide it. (Well, you could take a loss by providing it and not charging, I guess.) In very few cases does a patch-level upgrade to Mailman require stopping for long enough that anybody would notice in the queue slop. Or you can set up other systems to mitigate the vulnerabilities (or not, if that's inconvenient), and do the security update on banker's hours. >> In sum, I just don't see what benefit there is to the process >> you outline relative to current policy. The information >> doesn't make anyone more secure Jim> No one is advocating that more info means more security. Jim> More info just means that users aren't the only ones in the Jim> dark. If the hack is out and the developers are working on Jim> it, who is left to inform... THE USERS OF THE PRODUCT. Why Jim> leave us in the dark? Because it gives information to the enemy and is only of marginal value to this user; I'm not speaking for anyone else, but I would be surprised if I'm the only one who feels this way. Producing security fixes is done on exactly the kind of off-hours, do-it-now schedule that we all dislike for applying the fixes, and I think it's a good idea to delegate the decision-making to the same experts I trust to do the work. >> (unless they're willing to shut down their systems from >> announcement that "we're worried" until a workaround or fix is >> available) 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. Excuse me, but it is the _volunteers'_ judgment that broadcasting that information will hinder their effectiveness. I value your (and my!) capability to respond to such threats, but I acknowledge that I have no choice but to delegate the matter to the responsible developers. Neither I nor you have any *right* in the matter. See Section 11 of the License under which you received Mailman. If you want that information so badly, there are several ways you can arrange to get it: you can employ the developers, you can follow the security bulletins religiously (and privately ask the the developers what they're doing about it and privately tell those you trust about it), you can become a trusted developer. TANSTAAFL. >> communication with users will slow production of the fix but >> won't reduce the variance on when it gets released, and it's a >> non-negligible burden on the developers. Jim> I don't believe that one bit, certainly not in the scenario Jim> that I described. I really have to disapprove of the way you consistently deprecate costs that others incur, while inflating those that you face. -- 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