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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ