[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110413230205.GF1252@dojo.mi.org>
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.
