Re: Request for linux-distros list membership

[rf () q-leap de]

> > > > > "Alexander" == Solar Designer <solar () openwall 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 () q-leap 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