From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 86E33139082 for ; Tue, 3 Jan 2017 16:59:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10A77E0CF2; Tue, 3 Jan 2017 16:59:39 +0000 (UTC) Received: from omr-a016e.mx.aol.com (omr-a016e.mx.aol.com [204.29.186.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AF431E0CDC for ; Tue, 3 Jan 2017 16:59:38 +0000 (UTC) Received: from mtaout-mcd01.mx.aol.com (mtaout-mcd01.mx.aol.com [172.26.223.205]) by omr-a016e.mx.aol.com (Outbound Mail Relay) with ESMTP id 160973800048 for ; Tue, 3 Jan 2017 11:59:38 -0500 (EST) Received: from [192.168.1.52] (0x5b3139322e3136382e312e35325d [71.122.242.106]) by mtaout-mcd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id A04F8380000A3; Tue, 3 Jan 2017 11:59:37 -0500 (EST) Subject: Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement) To: gentoo-dev@lists.gentoo.org References: <4a185773-6144-69b8-a466-0e554732f12f@gentoo.org> <3374938.6WoLSc5MN8@mal> <589f3521-af7e-488d-8bba-4465c3a78e8e@gmail.com> <7959202.qokhvJWHAx@mal> From: james Message-ID: <6ef62f9f-237f-d40d-a27f-e77b7b5ad14d@verizon.net> Date: Tue, 3 Jan 2017 11:59:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit x-aol-global-disposition: G x-aol-sid: 3039ac1adfcd586bd879130e X-AOL-IP: 71.122.242.106 X-Archives-Salt: bf442543-9eca-47b7-8885-f6e9857a046f X-Archives-Hash: 43ca0b9cb62aa3c8ae35990811e11f18 On 01/03/2017 10:41 AM, Alice Ferrazzi wrote: > On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman wrote: >> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol wrote: >>> >>> For security's sake, even mature software needs, at minimum, routine auditing. >>> Unless someone's doing that work, the package should be considered for >>> removal. (Call that reason # π, in honor of TeX.) >>> >> >> Are you suggesting that we should ban any package from the tree if we >> don't have evidence of it having recently being subjected to a >> security audit? We might literally have 3 packages left in the tree >> in that case, probably not including the kernel (forget the GNU/Linux >> debate, we might be neither). >> >> The fact that a project gets 47 commits and 100 list posts a week >> doesn't mean that it is being security audited, or that security is >> any kind of serious consideration in how their workflow operates. >> >> I tend to be firmly in the camp that a package shouldn't be removed >> unless there is evidence of a serious bug (and that includes things >> blocking other Gentoo packages). If somebody wants to come up with a >> "curated" overlay or some way of tagging packages that are considered >> extra-secure that would be a nice value-add, but routine auditing is >> not a guarantee we provide to our users. The lack of such an audit >> should not be a reason to treeclean. > > +1 >> Rich Not only do I agree with those sentiments express here (Rich's sentiments), I have an additional prospective. I have been deeply following the development of clusters, particularly "in-house" clusters run on less than a dozen systems. There are an endless number of uses for such clusters, kinda like the modern version of when "X" servers were all the rage decades (and decades) ago, at the very least. In fact the cluster space for in-house clusters, imho, will eventually end up, being a collection of tarballs (stage-4s in gentoo case) that are customized for thousands of finely tuned, secure needs. "Unikernels" is the current buzzword, that docker and others have been using. [1] and have a tightly and minimized framework. Folks that work for "Cloud Vendors" should understand that if individuals and small companies are able to build and run localize, small clusters, then is very easy and comfortable for them to expand into hybrid clusters and become comfortable with outsourcing to the cloud. Many larger companies I consult with or have conversations with, are still uncomfortable with "cloud" anything. In-house clusters are the gateway to growing the entire cloud business, imho. Many of those old and stable codes, that lots of folks are so keen on purging from the tree, are actually quite useful and easy to secure, for such custom frameworks. Those frameworks can easily be packaged up into a stage-4 or a forked gentoo distro or implemented via any number of deployment methods, included CoreOS's fleet, recently added to portage. Security is the pivotal issue with clusters, whether they are in-house or outsourced (the cloud/Paas/Saas/etc) imho. So keeping those old codes around makes my life easier and more interesting. Sure I can go to these old codes and resurrect most, as needed, but why be vindictive by purging things that are old? Does the younger and more progressive devs in gentoo really want to purge old C-hacks like me from the community? I do not mean to offend anyone, but it just seems to me to be just plain unjustified purging useful that are currently not popular codes, and that hurts me on a personal basis. Us 'old farts' are the unix historians, here at gentoo; perhaps the more aggressive devs will consider being 'politically correct' towards old farts that have decades and decades of history, with these old codes? Newer codes are valuable too, but often they add a layer of complexity and many attack surfaces, that older codes do not suffer from. So, I would hope we err on the side of keeping ebuilds of old codes around as long as possible, despite the download count. My work is liable to take another year or two to bear fruit, but that's not even the point. I would be excited if we could just move these old packages to an overlay, if/when they do have to be pruned from the gentoo-proper tree. Perhaps the new GLEP on formalizing forking gentoo, will lead to a gentoo-legacy fork, just for historical and nostalgic reasons? I'm betting that these old codes are much more useful than most have figured, but it's going to take some time to establish this performance and superior security postulate, as I use 'old-fart' methodologies..... hth, James [1] http://unikernel.org/blog/2015/unikernels-meet-docker