From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BB7C9138A1A for ; Wed, 7 Jan 2015 19:35:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9BF8EE0849; Wed, 7 Jan 2015 19:35:26 +0000 (UTC) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E0B6E0841 for ; Wed, 7 Jan 2015 19:35:26 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id g201so4299902oib.12 for ; Wed, 07 Jan 2015 11:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=gl3YgkEtU99ZoY0gZvJUpUNXyfXHQmregCYVhs2w+50=; b=XtwMhvMbUv83/i/MfyDZbVoJfhe1lHdfL+e0C1lAk0o5ohP40VCjIpSShzjH0eqZkD KRtBPr4BqdYyO1dO6jL5teegkspQJpeSzKOILNrPIBdGHQtg+FqXTBCQXk37P4IotSoR G0EVi7JHct5H1/K5UII0LUamLC1n06ggDz9C1Vs5lzXTEteevuLddSp+89W+PF81Is+o h5JokXoDyYummqyHmSRqhTEMImL0Ec0sU9MdW4B5ZAAFglLGpA5nKvcbXaTakRNCg+Ex fA3626UySWJYDf92KyghpZB9UtKf2E5OsC4GbjxNkY31C0SGuJJIQvS2OpGEpow2zq+e +evA== X-Received: by 10.183.3.36 with SMTP id bt4mr3175922obd.44.1420659325451; Wed, 07 Jan 2015 11:35:25 -0800 (PST) Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128]) by mx.google.com with ESMTPSA id g11sm1418830oem.4.2015.01.07.11.35.23 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 07 Jan 2015 11:35:24 -0800 (PST) Sender: William Hubbs Received: (nullmailer pid 8030 invoked by uid 1000); Wed, 07 Jan 2015 19:35:17 -0000 Date: Wed, 7 Jan 2015 13:35:17 -0600 From: William Hubbs To: gentoo-project@lists.gentoo.org Cc: Richard Freeman , Sergey Popov Subject: Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items Message-ID: <20150107193517.GA7953@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org, Richard Freeman , Sergey Popov References: <201412271334.34252.dilfridge@gentoo.org> <20150107163052.GA7151@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: 47a75afe-ee7f-4c8f-a437-71c23161235d X-Archives-Hash: ab76df8caa6a26b15c8fe16428473c26 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 07, 2015 at 12:45:07PM -0500, Rich Freeman wrote: > On Wed, Jan 7, 2015 at 11:30 AM, William Hubbs wrot= e: > > That's the whole point of a last rites, to get people to step up and > > take responsibility for packages. Also, this was cleared with the qa > > lead before it was ever sent out. >=20 > Define "take responsibility for packages." As far as I'm aware there > is no policy that requires maintainers to fix any upstream bug, and > security issues are almost always upstream bugs. You're right, there isn't a requirement for us to fix upstream bugs, and there shouldn't be. >=20 > A package with a security bug for 10 years could be perfectly > well-maintained, with regular updates/etc as often as upstream > publishes them. Some software projects are fairly mature and don't > get a lot of upstream updates, so a package might be untouched for 5 > years and have security issues and still be "well-maintained." >=20 > I think the solution to this is to have the community agree on just > what "well-maintained" actually means and documenting this as policy, > versus just making individual judgment calls. To be sure there will > still be grey areas, but I think that right now the policies are too > vague to try to enforce something like this. Based on our conversation on irc, what about this -- this is really about information in package.mask. If we want to keep proprietary packages with security issues in the tree, they should be marked as proprietary in package.mask so it is obvious that they will never be fixed. If there is an upstream security issue with a non-proprietary package: When a version or revision with the fix is available, it should be fast stabled. Once that is done, all older versions should be removed if possible. if this is not possible right away, the older versions should go in p.mask with a removal date. Thoughts? William --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlStinUACgkQblQW9DDEZThlgQCcDJ+I0wDTCO/BA5jdQ1t+Huru lwgAniBPJzH3fGdVWRvS+oCaqAGktki1 =LNF2 -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--