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 C529C1382EE for ; Tue, 5 Jul 2016 12:58:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE71114186; Tue, 5 Jul 2016 12:58:51 +0000 (UTC) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (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 D12F5E0AA8 for ; Tue, 5 Jul 2016 12:58:50 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id f126so136408283wma.1 for ; Tue, 05 Jul 2016 05:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=bT/oafKX+73bQwEDdy2FPEZwXd69gKuhKz6TYSyky4M=; b=A5AnxPTC+bvoN0S35nKptHmXUQya3W4wLhUOE3jE+E0fZZtWbA87QuekJQuF6M0Zli QL16MW3lVNIAi6VSOmv1uHcoJajJq7Gz5lbf/O233p1D62DktZqGLF2a2TEOfOHpto7D msQrQXVB1ufSSw+s0JyFSYcf0JNew9jOMLEOlvUJIEwlzMj67xKUlOBgZHWohaXFap0o VwFAOjMIBhQtRbTK6SgxhtL1KtbnNGWZXMs8iqb0jVXJaPSuihTByCILD2ucT0dQ7otG 966D+ltXu+H+or/7M1D18HXKl34Ia7ResBdWuxafza9J1JopVVju1JFgeOHvcomGQeXD 0dUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bT/oafKX+73bQwEDdy2FPEZwXd69gKuhKz6TYSyky4M=; b=CkQrwJimUj4Uikc2IFW4PKzr0iYF8ue7JYrLs5Qrpo6W4nOrJ+Y3J0mFoQ6HuuENTN HOVYZ/nKsCuKyLcoV8OadgCMMLhu+VWFt5gEXw9aZnx8apInWHXZSLUnsOu/cufE+GbS QQS/Dv9bRU+eoX671To9ZaQzDK4l/bN3aD1Ji2okOVl9zm+o4J/e1Ph34h0CFlEAIFSk jR01S9Kubxcx7MEBsPu3iT9wkBdkUlBRJ56qRzxiu1+p4hY7fSXBjaxqP4N8m7a2QKS7 f28Z0wBOt4QEFiJsDPBxID2QJ+Yo+jK8AyraERQBrX/D19dWn6dAfVhrOmzWT9Rw5RNS X4jQ== X-Gm-Message-State: ALyK8tLd61yxCDW9I1oL/bNp/k48H3z37060QpBs5CrPkyQ3qViAO2QSg7OVRy38XjRYlQ== X-Received: by 10.194.123.73 with SMTP id ly9mr17720478wjb.21.1467723529190; Tue, 05 Jul 2016 05:58:49 -0700 (PDT) Received: from [172.20.0.40] ([196.212.62.210]) by smtp.googlemail.com with ESMTPSA id g4sm2742365wju.30.2016.07.05.05.58.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2016 05:58:48 -0700 (PDT) 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: Alan McKinnon Message-ID: <583270a0-c779-8f0d-61c9-d36555a3adab@gmail.com> Date: Tue, 5 Jul 2016 14:58:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 674dbb17-f1dc-49d1-96f7-8e40ba516fb2 X-Archives-Hash: c60cbb042889c587d5ce68e14bddd643 On 05/07/2016 15:07, 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 active >>> 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 vulnerabilities. >>> 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. > > As an old C hack, and user of gentoo for over a decade, I understand the > 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. > > 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 them. > > 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). > > 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). > > > 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 no > 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 of > 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. > > 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 to > retrieve them, via github, as the attic too is probably like sunrise and > such, headed towards deprecation and the chopping block..... s/github/git/g Big difference. Gentoo's tree is not hosted on github, and infra isn't going to put an attic equivalent there. -- Alan McKinnon alan.mckinnon@gmail.com