[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150320145413.GA10416@openwall.com>
Date: Fri, 20 Mar 2015 17:54:13 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: membership request to the closed linux-distros security mailing list
On Fri, Mar 20, 2015 at 02:00:29PM +0100, Sona Sarmadi wrote:
> On behalf of Enea Software AB, I would like to request membership to
> the closed linux-distros security mailing list.
Oh, recent attention to OpenSSL does wonders. I already got off-list
reminders from IBM and VMware this same week.
Of course, this is primarily about PR, and only secondarily about
security. But should this be stopping us, if early security updates are
also, unsurprisingly, good for security?
OK, we got to handle these requests, and more. Yes, there were several
more off-list requests (obviously, they would not be handled without
bringing them to oss-security first) during the 11 months that distros
list membership has essentially been locked (in terms of which distros
are represented; there were minor changes in who is subscribed for
distros already on the list).
Oh, and I need to announce that one distro left the list earlier this
month: the person previously subscribed for Android determined that "the
mail going to those lists hasn't been actionable" for Android.
So, our options are:
1. Shut down the (linux-)distros lists and be done with this. ;-) To me,
they were more clearly doing more good than bad when they were a subset
of the old vendor-sec. With more membership requests coming in, and
with simply ignoring such requests being unfair, maybe the time of these
lists is over. No, this does not mean that's my current opinion, but
when doing something as controversial as this, I think we should at all
times be reconsidering whether the "more good than bad" condition is
possibly no longer met. (Of course, some people are convinced that it
never was. I am not. Rather, I am unsure.)
-OR-
2. We can just go ahead and review each request for acceptance for the
existing (linux-)distros lists. In this case, we'd be less likely to
satisfy all of the pending requests. And maybe we should question the
subscription of Amazon Linux AMI, MontaVista, and Wind River, which are
now linux-distros members.
-OR-
3. Setup a separate list for primarily non-free software and primarily
non-software vendors. Of the existing linux-distros members, maybe
Amazon Linux AMI, MontaVista, and Wind River should be moved there.
(Maybe also Chrome OS?) And then maybe Enea and VMware would reasonably
be added, too. Not sure if IBM is non-free enough to be restricted to
that list.
The idea behind such list is that we'd let people decide who they want
to notify: all distros (including this separate list) or just the more
free'ish subset (not including this separate list).
We already use this sort of setup for not bothering *BSD's with
Linux-specific issues (although this happens from time to time anyway,
as some messages get misaddressed to the full distros list even when
Linux-specific). So technically this sort of setup is tested, and we
can add more instances of it. We need to decide what to call the
externally-visible lists, though. Perhaps "distros" will reach all
three groups (*BSD's, free Linux, non-free Linux), "linux-distros" both
Linux groups (free Linux, non-free Linux), and maybe "free-linux-distros"
just the free Linux? Oh, and we'd also need "free-distros" (*BSD's and
free Linux). Having this fourth address would also allow us to
subscribe distros that are neither Linux nor free (perhaps IBM?)
So that's four external addresses. Too many? Too confusing?
And indeed, the separation between these sub-lists is unclear. There
will always be doubts where a given vendor belongs. For example, to me
Red Hat is free enough to be on the privileged sub-list, but someone
might disagree. And then there's Oracle, which is even less obvious.
BTW, we may need to discuss whether Oracle's subscription is for their
Linux distro only or also for Solaris. So far, I refused to subscribe
an extra person for them who was not involved in their Linux distro,
since I felt their subscription had only been approved by this community
for Oracle Linux and not for Solaris.
Finally, what if we need a different separation later? For example,
what if we start getting too many reasonable requests, from distros who
do proper security response, etc. but are just too numerous? (I think
distros doing proper security response are not too numerous currently,
but who knows how this changes over the years.) We could end up having
to separate a core list vs. the rest, to let senders decide whether they
want to only notify e.g. 10% of distros corresponding to 90% of users,
or 100% of distros that are on our lists (increasing the risk of leaks
possibly ten-fold). So far, there hasn't been any discrimination for
smaller userbase distros, neither on the old vendor-sec nor on
(linux-)distros. Our criteria do not include userbase size, as long as
existence of some userbase not limited to one organization can easily be
seen. However, I am not strictly opposed to this changing if the
conditions change. Adding this sort of separation on top of four
addresses we might setup now would be even more confusing. Perhaps we'd
replace the four addresses with different ones if we need to introduce
this kind of separation? Or maybe this would be time to shut down the
lists, after all.
Comments?
Alexander
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.
