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.