Date: Wed, 13 Apr 2011 19:02:05 -0400 From: "Mike O'Connor" <mjo@...o.mi.org> To: oss-security@...ts.openwall.com Subject: Re: Closed list :----- Original Message ----- :> :> Your initial e-mail indicated we would be part of this new group since we :> where a vendor-sec member. Now there are new requirements we have to :> meet. Is there a possibility of a probationary period so we can try to :> comply to these new requirements and still be on the closed list? :> : :I don't want to start arguing technicalities, semantics, or politics. Here :is my current view, I'm going to leave the final decision up to Solar :Designer, I view this as Openwall's list. : :We have rejected certain membership requests because they are not currently :releasing security updates. I agree with this policy, I would say my :initial mail was too vague. This instance is no different. It's clear that :one of the membership requirements is now producing security updates. If :you can show you're doing this, that's grounds for membership in my :opinion. Josh, I think in your quest to make things less vague, you may have actually made them more vague. "security updates" and "public advisories" aren't the same thing, That's not just a semantic distinction. There's many s vendors who release security updates, but not necessarily public advisories on them. They may have constituencies that would simply get confused by advisories, or they have auto-update mechanisms, or part of their support model involves pushing their customers to keep up with all fixes, security or otherwise. They may simply thing that advisories are a waste of time because customers don't read. For linux-distros, I think what you really want to go for here are *timely* updates. If a distro isn't generally capable of producing a security update within, say, a month of when the issue was released, then their getting the issue in advance through linux-distros isn't going to do them or their distro community a lot of good because they have other constraints in getting fixes out the door. Focusing on how you think an update ought to *look* (e.g. should the advisories be public?) isn't as important as the update getting *out*. Especially since you're dealing with GPL'ed code, I think that's something you can measure. Just ask the constituency a month or so after some major kernel issue who has released updates/fixes and who hasn't, show the relevant source, and take it from there. Take it for what it's worth... -Mike -- Michael J. O'Connor mjo@...o.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "I'd give my right arm to be ambidextrous." -Anguished English Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.