Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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.