[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21338.8255.116685.236780@gargle.gargle.HOWL>
Date: Fri, 25 Apr 2014 10:43:43 +0200
From: rf@...eap.de
To: oss-security@...ts.openwall.com
Subject: Re: Request for linux-distros list membership
>>>>> "Alexander" == Solar Designer <solar@...nwall.com> writes:
Alexander,
just a short reply: I appreciate your serious consideration and fair
reasoning for your decision and can definitely live with it. When we
(Qlustar) meet more of your specified criteria I might reapply.
Thanks for the time you put into this particular issue and for the
effort on these lists in general.
Roland
Alexander> Anthony, Roland, all - I've subscribed Anthony to
Alexander> linux-distros today, for Amazon Linux AMI.
Alexander> Let me use this opportunity to remind the people already
Alexander> on linux-distros and distros lists that I'd appreciate
Alexander> their help in ensuring that list policies are met. While
Alexander> I help host these lists, I never volunteered to be the
Alexander> (only) policeman. ;-) I posted three messages to distros
Alexander> today (right after subscribing Anthony) requesting that
Alexander> coordinated disclosure dates on specific issues be
Alexander> clarified and kept within the maximum of 14 to 19 days
Alexander> (depending on day of week) as stated here:
Alexander> http://oss-security.openwall.org/wiki/mailing-lists/distros
Alexander> In fact, way shorter than the maximum embargo periods are
Alexander> preferred (and are often used), which is also stated on
Alexander> that wiki page.
Alexander> So, can someone already on linux-distros and distros
Alexander> please volunteer to keep track of all issues being
Alexander> brought to these lists (yes, all issues - including those
Alexander> that don't affect your distro) and ensure that each one
Alexander> of them promptly gets assigned at least a tentative
Alexander> public disclosure date, that such date is within list
Alexander> policy, that the issue is in fact publicly disclosed on
Alexander> that date, and that the disclosure includes a mandatory
Alexander> posting specifically to oss-security (as well as to
Alexander> anywhere else the disclosing person likes to post)? If
Alexander> any of these requirements are violated (or are about to
Alexander> be violated), please yell on the (private) list (CC'ing
Alexander> the external reporter of the issue, if applicable) until
Alexander> the violation ceases. Any volunteer(s)?
Alexander> Anthony, can it be you? I deliberately didn't ask you
Alexander> before subscribing you, because volunteering for this job
Alexander> is in no way a precondition for list membership, but it
Alexander> would happen to be an extra justification. ;-)
Alexander> On Fri, Apr 18, 2014 at 05:32:48PM +0200, rf@...eap.de
Alexander> wrote:
>> Just a remark from somebody who's request for linux-distros
>> membership was turned down: I think in case the AMI membership
>> will be granted, you need to provide a clear explanation why
>> Qlustar's wasn't. Better: Setup some clear criteria for when
>> membership is possible and when not.
Alexander> I am hosting these lists at Openwall for benefit of the
Alexander> oss-security community, so decisions are made based on
Alexander> opinions expressed in here, with the exception that I
Alexander> won't do things I find obviously wrong (someone else
Alexander> would need to volunteer to host the lists if my personal
Alexander> opinion would ever be incompatible with what would appear
Alexander> to be the community's sentiment).
Alexander> Based on the discussions so far, I don't have a strong
Alexander> "obviously wrong" feeling towards any of the four
Alexander> possibilities for AMI's and Qlustar's (non-)subscription,
Alexander> although I do feel there's a significantly stronger case
Alexander> for subscribing AMI and a fairly strong case for _not_
Alexander> subscribing Qlustar, so it'd be weird to subscribe
Alexander> Qlustar and not subscribe AMI.
Alexander> Here are some reasons in favor of subscribing AMI, which
Alexander> are not present for Qlustar, in arbitrary order:
Alexander> - AMI appears to have a use for advance notifications for
Alexander> components of
Alexander> the entire distro, not just Linux kernel.
Alexander> - Some community support for getting AMI onto the list.
Alexander> - Some community support for getting the specific Amazon
Alexander> person on the
Alexander> list as the representative for AMI.
Alexander> - The person's track record of contributing to upstream
Alexander> Open Source
Alexander> software and in security relevant areas (QEMU
Alexander> development).
Alexander> - No opposition to subscribing Amazon Linux AMI. For
Alexander> Qlustar, there was
Alexander> not exactly opposition, but no one was convinced that
Alexander> Qlustar should be subscribed when I specifically asked:
Alexander> http://www.openwall.com/lists/oss-security/2014/01/23/6
Alexander> - Amazon Linux AMI having a significant userbase, which
Alexander> is unclear for
Alexander> Qlustar yet. When the first request to subscribe Qlustar
Alexander> was made, IIRC my Google web search for it found
Alexander> surprisingly few results (like 20), and even fewer not on
Alexander> Qlustar's own sites. This has improved since: a Google
Alexander> web search for "Qlustar" (in quotes) gives "About 2,060
Alexander> results" results now, although there's relatively little
Alexander> vendor-independent content (postings other than by or
Alexander> forwarded from Roland, etc.) Hitting "Next" exhausts the
Alexander> actual distinct search results on page 6, saying "In
Alexander> order to show you the most relevant results, we have
Alexander> omitted some entries very similar to the 57 already
Alexander> displayed." About the best potentially independent
Alexander> comments on Qlustar I found now are these two:
Alexander> http://www.microway.com/hpc-tech-tips/sc13-highlights/
Alexander> "Qlustar
Alexander> There are a lot of choices out there to consider when
Alexander> selecting software for your cluster. The product Qlustar
Alexander> will likely be of great interest to those who prefer a
Alexander> Debian/Ubuntu-based approach. Its special because
Alexander> building up an HPC cluster from these distributions
Alexander> usually requires additional effort. Qlustar is also
Alexander> unique in its built-in support for ZFS, LUSTRE (on top of
Alexander> ZFS) and HA."
Alexander> and:
Alexander> http://ubuntuhpc.wikia.com/wiki/HPC_Linux_Cluster_with_Ubuntu_Wiki
Alexander> "If you want to have serious HPC clustering software for
Alexander> Debian/Ubuntu look at Qlustar"
Alexander> Oh, the second one was a wiki edit from an IP address
Alexander> that resolves back to ns2.q-leap.de, so clearly not
Alexander> independent. So at most one maybe independent comment on
Alexander> Qlustar I could find. Does it not have 2+ users who
Alexander> would say anything on the web? It certainly appears so
Alexander> from the few minutes I spent web searching. (And
Alexander> Microway's is based on conference attendance, so probably
Alexander> not from a user.)
Alexander> And no, I don't mean to encourage creating a fake web
Alexander> presence. I actually appreciate Roland's sincerity in
Alexander> this matter very much. I understand it takes effort and
Alexander> time to gain adoption for a new distro. It's just that
Alexander> maybe it's not time for Qlustar to increase the risk
Alexander> exposure for others, for the benefit of extremely few
Alexander> users.
Alexander> BTW, contrary to what some people guess (I heard them say
Alexander> so), there was essentially no userbase size filter on the
Alexander> old vendor-sec. This is a new thing I am suggesting
Alexander> here. I would probably not suggest it if I saw a normal,
Alexander> small userbase distro. But a distro where I can't find
Alexander> any userbase at all? Hmm. I do think Roland is acting
Alexander> in good faith, and the distro is indeed real, but let's
Alexander> not forget that if we start accepting zero-userbase
Alexander> distros, someone might be tempted to create a fake distro
Alexander> just for this purpose.
Alexander> I think as a minimum we should require that someone who
Alexander> has already made contributions to this community has
Alexander> vouched for the new distro and for the specific person.
Alexander> If not, we should not satisfy the request. Anything less
Alexander> just invites abuse attempts. We should also require at
Alexander> least some visible userbase.
Alexander> 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.
