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 2FCC21382EE for ; Tue, 5 Jul 2016 18:18:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BB72D94087; Tue, 5 Jul 2016 18:18:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B72B914186 for ; Tue, 5 Jul 2016 18:18:00 +0000 (UTC) Received: from [192.168.10.33] (ool-457bb23b.dyn.optonline.net [69.123.178.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: NP-Hardass) by smtp.gentoo.org (Postfix) with ESMTPSA id 9F0D4340C15 for ; Tue, 5 Jul 2016 18:17:59 +0000 (UTC) Subject: Re: [gentoo-dev] why is the security team running around p.masking packages To: gentoo-dev@lists.gentoo.org References: <4c319530-3c7c-e8e3-300d-c80c84cf6674@gentoo.org> <20160704234030.32bad9b5b2fb31f9a7d2ce73@gentoo.org> <42b9c46c-634c-a23c-22dd-4fa7dff55ef2@verizon.net> From: NP-Hardass Openpgp: id=862040BE422755F27FDE13D5671C52F118F89C67; url=https://sks-keyservers.net/pks/lookup?op=get&search=0x671C52F118F89C67 Message-ID: <577BF9CC.5030404@gentoo.org> Date: Tue, 5 Jul 2016 14:17:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.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: <42b9c46c-634c-a23c-22dd-4fa7dff55ef2@verizon.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sDuIF39unOOlTve3v9EOhOk0WB7QDLcFK" X-Archives-Salt: 8920633d-ab9b-423e-80e3-f5be492766cc X-Archives-Hash: 305c431c84c39bc74b1077f0b395ce91 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sDuIF39unOOlTve3v9EOhOk0WB7QDLcFK Content-Type: multipart/mixed; boundary="xcT6r07XSq3U2vIaWFc2X49IBs2FbBX7c" From: NP-Hardass To: gentoo-dev@lists.gentoo.org Message-ID: <577BF9CC.5030404@gentoo.org> Subject: Re: [gentoo-dev] why is the security team running around p.masking packages References: <4c319530-3c7c-e8e3-300d-c80c84cf6674@gentoo.org> <20160704234030.32bad9b5b2fb31f9a7d2ce73@gentoo.org> <42b9c46c-634c-a23c-22dd-4fa7dff55ef2@verizon.net> In-Reply-To: <42b9c46c-634c-a23c-22dd-4fa7dff55ef2@verizon.net> --xcT6r07XSq3U2vIaWFc2X49IBs2FbBX7c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/05/2016 09:07 AM, james wrote: > On 07/05/2016 06:25 AM, Rich Freeman wrote: >> On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman wrote:= >>> >>> The subject of this particular mailing list post is a little alarming= >>> and >>> over reactive. We are not running around p.masking everyone's >>> packages, but >>> issues that have been outstanding for years often result in such >>> courses of >>> action. I personally told Anthony I should have requested his >>> assistance >>> initially on the matter, and I do apologize for that. He is an activ= e >>> developer who would respond in a timely manner. So once again, I do >>> apologize. >> >> Thanks, and my intent wasn't to suggest that I thought there was any >> kind of a trend here. I just wanted to agree that this shouldn't be >> how it happens. It sounds like we're already on the same page, which >> isn't surprising since this was the first complaint I've heard in a >> while. >> >>> Finally, that does not dissolve the developer of providing usable, >>> substantiated, and verifiable information regarding the vulnerabiliti= es. >>> The idea that a developer gets to choose whether or not they do so >>> should >>> not be considered. >> >> Also agree. I think we need to have a reasonable security policy, but= >> clearly there can't be unresolved questions about whether a particular= >> package-version is vulnerable or not. If we don't get a question like= >> that resolved in a timely manner then the version should be masked. >> Users can then make an informed decision as to whether they want to >> take the risk in unmasking it. >> >> Our security policies are a tree-wide QA commitment that our users >> rely on. We shouldn't advertise a security policy that we aren't >> willing to enforce. >=20 > As an old C hack, and user of gentoo for over a decade, I understand th= e > positions being articulated herein. However, I think there is a > fundamental perspective that is missing, so I shall attempt to > illuminate that perspective. 'C' is still a magical and most important > language. It is the transitive language between large, complicated > systems, and hardware. Like it or not, without hardware, there are no > systems. >=20 > There are many new and modern languages with wonderful features. I get > that, and appreciated that they are needed and desired. But modern > (security and usefulness) metrics are being applied to old codes that > are useful for a variety of reasons, beyond compiling them and using th= em. >=20 > There is an intersection between minimal unix (minimal gentoo in our > case) and embedded systems. Docker, many would cite as the leader in > commercial container deployments, has realized that minimal is better, > faster, easier to secure and can always be 'scaled up' by adding more > codes (hence they subsumed Alpine Linux). >=20 > Gentoo has a rich, legacy in old, simpler codes that bridge embedded > linux to (bloated/full-featured) linux. Those old codes that appear to > many as useless, indeed form a narrow bridge to both the past and the > logic/tricks/methods to get various types of hardware working in a > minimal or embedded environment. They are often 'single function' codes= > without the complexity of a gui or bloated formations. They are easy to= > read and with a CLI focus, allow a developer to see how some things > work. Those old codes, folks are quick to purge now, often contain > logical information on how to talk to hardware. (think ethernet for one= ). >=20 >=20 > So when we had 'the attic' I was fine with codes being purged by > whomever. There is no easy to use equivalent in github (and believe me,= > I'm a noooooob at github), so I have much anxiety about what, from my > perspective, appears to be needless purging of many old codes. I have n= o > problem with removal from the official tree, but I'd like to keep them > around, regardless of any security, brokeness or un-maintained status. = I > completely OK with tree-cleaning, just a soon as the ink dries on the > new wiki pages that guarantee archival of old codes. Security, is > important, but not the main issue from my perspective. Maintenance of > old codes, particularly written in C and related to hardware or logic o= f > minimal systems, is keenly important to me. If gentoo remains 'a good > stuart' of these codes, it just another mechanism > to distinguish our distro, imho. >=20 > So I would ask (beg if necessary) the kind folks that are the gentoo > devs to figure out a way to archive those old codes, and document how t= o > retrieve them, via github, as the attic too is probably like sunrise an= d > such, headed towards deprecation and the chopping block..... >=20 >=20 > Thanks, > James >=20 >=20 Here's a solution that handles that doesn't require fancy git knowledge and uses Gentoo infrastructure: 1) Navigate to https://gitweb.gentoo.org/repo/gentoo.git (or any other gentoo repo) 2) Click "Tree" 3) Navigate to the level ABOVE the one you are interested in, for example, if you want app-misc/foobar, navigate into app-misc. 4) To the right of your desired entry, click "Log" 5) This will display the history of the package, allowing you to browse it at any time, (you in particular want the one before the ebuild was removed) (Click your desired commit) 6) Click the name of the category/package on the "Tree" line to view the tree at that point in time. ie, tree 02d93ae662fb1a813380775612e35e819d67e303 /app-accessibility/SphinxTrain (you would click "app-accessibility/SphinxTrain" 7) View and download your desired files by clicking on "Plain" on the rig= ht Protips: *You can view the log of any package (removed or not) with: https://gitweb.gentoo.org/repo/gentoo.git/log// *You can view files as of last commit before removal of any package with:= https://gitweb.gentoo.org/repo/gentoo.git/tree//?id=3D= * If you don't know the last commit before removal, juts load up the removal commit and copy the commit hash of the "Parent" link to get the commit before that Tada! Attic restored ^_~ --=20 NP-Hardass --xcT6r07XSq3U2vIaWFc2X49IBs2FbBX7c-- --sDuIF39unOOlTve3v9EOhOk0WB7QDLcFK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXe/nNAAoJEBzZQR2yrxj7tOwQAKskfiTZ+Wk5GdBnLDY/zjdm VDofQEWxzSNgh0xRjOIj+VIXwqKVH67eGjWSj0z8AnK5qiEwdiDenlrgZ/6er4Dx 6jbQ5rlKdAXZaanMGIyqzE5+2QQA2NQM7BxrSHfztXwdPjmLRk9TIpmeWOS6uEmt WEvlc/mkcx1vwNBHvJq6QMu10dnHi7z991KRmmp+B9F300aA/Ndi3agRFdQ0bQNn eiJjbAH0hBpl6M3y5bSnMw62kERaHhNzPyrF+z/LqrGz4Zj0IhCzgGYPeZ5yljBF xUgk2AdLPBeUg68GR+oxd3r7p6n2g0nkxaQoBFPZ4viKHusIVt1dTDbNnp3zWGnp iiqlguGw7/znrp5Vhm05nVYDRrUTEhW1r+6iOlhtMyn0LppZDsYYA0e9hVs7/X4P /dQy4SaT9pwM8WGYAtLWXiSSXGWLJNzlIivh+TA4zDBo0IEi+GSykWbbZcOH1+/q TkRrF5jmhgYQkGZ3w/KORtFGUgB9SCacl+jwkWFi6YJSHvbts3yx1va1T8n6EoWS BZzzxwSMdAxICZB+eHFaA9LoTd2Rn5VG3iFepxOkXN0fGXWC/9N5VCE0X/zoALZp FE0GEJQ7YN6CSBRPHCbQq3DuaMwYZqpHuf6w7CuOO1tPIkD5DX0qfHAqJcvZP37R njGmg2/K5XYAZeVFWIO+ =lTwD -----END PGP SIGNATURE----- --sDuIF39unOOlTve3v9EOhOk0WB7QDLcFK--