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 8AA68138334 for ; Wed, 5 Dec 2018 09:12:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5441CE0AA2; Wed, 5 Dec 2018 09:12:10 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C74A3E0A9E for ; Wed, 5 Dec 2018 09:12:09 +0000 (UTC) Received: from [192.168.6.147] ([212.159.46.162]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.163]) with ESMTPSA (Nemesis) id 1MJEIl-1gnWJQ3dNr-00KdYF for ; Wed, 05 Dec 2018 10:12:07 +0100 Subject: Re: [gentoo-project] Re: [pre-glep] Security Project Structure To: gentoo-project@lists.gentoo.org References: <6137e99b-2995-0569-9d3d-250924fdf116@gentoo.org> <1d3c9d30-5570-de92-3da9-75bd33c02075@gentoo.org> <21194272-4039-e473-8f57-426021fb24b7@gentoo.org> <20181204223059.GN16376@monkey> From: "M. J. Everitt" Openpgp: id=BA266E0525CFAB101523351B4C30334F93C22371 Autocrypt: addr=m.j.everitt@iee.org; prefer-encrypt=mutual; keydata= xsFNBFngC8gBEAC8/nQZrVrr8v0kaD4OLw8UftKfPQFEMGY/rnFA81M9IvdyPP8/8u/+9AGc DEN3i/LRvW0KUBdKIngcUY/p1M/sJqBspMOBaoOLp6K53/2uxcGXw62TulQJU+7a37Jukv2r HNSyZzM6II0myConmJa8ja1HfsiVoqDrqNigBF+Sts1kqG4xg8YeyOl1Tk+LZwC+ukzzutE9 pbpIL2snu5I6a6RNi9DtbB9FZKzkbXx8TlpMXrcorNryOLQHPRw6tir5Z8kpetiJgoEpKGBX botDOWLVW+s9XnwPzAFmL03gH+3reY+LfrQWQTDphfZIp75caZQUicQHpc1NUr+8bLr3n79A FCPY3CfWriGn17aqaaXDFfeYPJIlH8UmOXI41JqR47C5eYFbocA8A4k7cGVAdKJFWLy51165 dt7qZyvUQc/olzrZOrvoiWXA8ELg7pqxxObM4kl0502IHz9kb6Lt712HvfjH5yAP8zTYpetn sCPR9aVVSQsRgluNrQFlKpVmUXbeBLjw05UBEunS6prDwXOyZdn7t03LSOlK2nBGM+gtxg8l /0Nb1saYMGGN8qtO4RLFRiRBc20kNz01cC89PKRIXYlW9dRZNH1zebIUCAg+S4hSmmV4uvaZ XRADb2G+ZZ2jj9cNTTnI+X1/a19S8XjBZ4z+9+Hty4nhoB6fawARAQABzSNNLiBKLiBFdmVy aXR0IDxtLmouZXZlcml0dEBpZWUub3JnPsLBgAQTAQgAKgIbAwUJA8JnAAULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWeAgogIZAQAKCRBj58Z59NQx3awfD/4wMWDKcu0/s2KQhz5JUBfi v+PdY7xxJj77gPhHximyjWW8O1pu3H280HsL2751AuUyQ2JNWYUtbr8FIvk8dLBnjLmXQwu/ JhkPyAoW/3UcpSCjGkwZ0B/amHs9/dC99Y9Fk1lYDqm1FEmSmqnXHFg7tgdKpMF5eV7B0moS ISL0IKSOCMPHE1u/0bSwUVXbzuqWOLbWRcqH819aVsZG+unrQf87R0RKG5rI7OEkdtCDO+8D KlOPqo1i+Un9YvzdktNymHJtoHGljIWLoo5QMciHH5JX+y7bGH1mHfmnsqFsHiPQFkun3/xV qk9hI0qvl1q5ykX/UVZMmXaMVwWcpiLz4pHnN92v9BxyAESKJkj9fh9CoR958nmoLzhmVzdf pXHBlI4E5uYaKeCPbGNHZX0WoHaStf0f/AkuLSQj3g53VDWvDBt+qfnzBkGwYSGhM6tOQX5T Cz0WP8cZa6ghyzTy+z4jwT8/O9umurExdRl2D0VNdT4RPoCFs/jlFXFbnlGPC2FjvWfMEF8j 9FiPq19NPPRd8WiQYgRYehFFoDqNOzIu3LbshV2CPdVN5fsRD1lwOGlrmiPWQrWlfKoUK98G M5MfAcSJVkixsfoajZlH5lk48kBQsMnLxut2pmRiahtsEV0af+FHLs1ZuYngk0kJh5q+UyZi 4exXsLvHC/rPbs7BTQRZ4AvIARAA2MeaJF9ma6ngqTogwle2dHfAzilYpWSgt7Gej9APzidO mVfyoXIBsd3UMNQErFkRZNk/U0vyy0x9Azs3z0gqOo5E98veiN3VOf8g9vhTfxfHcVTz6JwX 9ggzO//iRPvUH3NKfEvpLNn8gkOvN9cTyh0k9Vrj28vBpD3HWWHJlU5wVrpFUpE4RFXDOpMD aAQAPkArzxXmc6CtnQfupkpZPe+mplDoEjFmw1F6fLp/09a+K0m97xZU0eG/tYWqItRpTHnY 8d92wFHNx1RdYyII8y2kCDNwp+E6oEX/DP5WspKGzgf/f9zci61v192wpXiqzoE9D+quFo9v z6Ywn8NCfqOUs+dnwZ9xtQXOHBU5lZi0avkg3HYQ1lArSkUHzlO4k5AslEu5AXqEOKe9Mo4q nYX/HK3xQEPwEJji2T8SR9IDPfAIYjSK6iMw7LT4ugCwVemNHmDSuWdZDjtbVMRdNtsWu0ar i04FQ+8cBovQHQyrVVYVduuazlBioX7dN8go17eue2C3hTr8xJhB4dX7/bfVAay1LeCWyaGr 15nfkAH4wXp11sSU482GwRnEEL5TeYDgHHtd+FyiYm3Wd5T5NKgPM5XpzIhm4MvLmWMhmC4O nLc5gZj2aQ7IWi2W5FlxSSu0VrC0q6hoNB0rCsz1GBKDBrLX+03hZrMRC0TeZZ8AEQEAAcLB ZQQYAQgADwUCWeALyAIbDAUJA8JnAAAKCRBj58Z59NQx3cwiEACpDgKf6ZlEx27TWzoV73v/ FV0Zy2vz+pqIIw2BKb1PbuEJnluZnWQ/u9nVCRoIQKDU5IHS+DoR76iTOUTiVmE+9ZltAHYi 9QRAHlwWdFkZqkoTNvrHw7pA0oOhgqC3k1n3FpAbT8GFZeIKRqgWCacTMBepMJRlz46nQ/CX 4Eh2HwrJrbgJJaMpNqoh+hJee7ev/TXV+OFLc310tJSZhSPXo9NkWGHu631RjOJl4Xf0vE4t Zy4aNE94NjMUOILjmaTp78HBUbsgqZrdl/wu2HbNNF5IKWwnyYRAeF9l73JuQwXLMrVQxbqP P9XiQqgKT4CF3xxdiXCS3Hq5s3OQLouFg03LGHyMAMtsP+8PepndmL/i79s/Mp0WYcJK6XAm Mi+Xknfi5Lay1oAjYu8UvGOWo5nOq62saN/bXG8/m+qqiueMOTDGXHZfklBglW5p6VYJd2eY W1teykJa7oGAOsiePl+z4UllNTBQVzhRPfmc/O3Yg6JJbISqHw84IWDINVUAN6wldIay83Tr gc1aAXDepgf6aNDbbWiQ+BBBJkAOGYTG9pnAaNMUKM65dkN7WufV2fwJHn900f2vzKyFYkKF bIiuODXBTfJG1yvMUQIgnDBYUBuBdDXB3NhOG8nHOJSQXTdI+Ma9ZMkxmVCxV9RXFPYBO8ji nurTf8FtGwnuig== Message-ID: Date: Wed, 5 Dec 2018 09:12:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <20181204223059.GN16376@monkey> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="grgPN70XHZuNn6gsM5wfpOMCjkXga6UgO" X-Provags-ID: V03:K1:cWU+1VqttuR29bz1iig4DA5gzTL+Ns5omoSlQ3doQPAruvs7Loo olhT2kfQGAQi85MwJ6CLWmjHf3GhIsuzVtiD7cW/tlZ9YqMM9Y/eG+E2pcdiWtJvsnMKO2f lsxjg+Un9RDV3pDV0QLyjq7EXGvlKB5M0lWVcc6p7ksAkkcwxoQoMitHEKszh72ZHUMpHoO JNzcey3QXu9ku1OwTjsHQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:fb3e0dimGzY=:KWaPokLeoXUA9QDTqoL4lB QbeWbNIbFsmqu7oP4f8cA9ix/yxDL/uhC1FIjzK85eOcGjfpRJL0zf+T1hfO/PAUlYJL0vpA7 xRkjV+uoIE+WfV/GeDSZN8apTCQenwlsw93dlMZEULnIROUqCzTyHm5zHMK7xrZyOP30mm26p cUm1gAKZJIj2Dz3ulWnbuAJfMu520sKjAusnjrziB72OqaeGJ2qMznLGOD9K5SyWU/a3wGQIf vCtjxVPd6p4qgpq29t3ew90xn8dyur+gPWYLR/3EHtU+OAMFcsBt2kgwpGdaZPzBi6W6KywQb L3ZN/4NRbIEpOiFQPgAXHQ1phaCTcPNDqs23dQ9rwf6EdLYAQdd/JSC433ZQq9ovFdMrVqPBk aoki0J7LQQ1Nppl1j8qaMDe41anWQ+l8tWl5VI3P86TbK2MiAbf8Jqs4KSCwLKa/iSvmxcfwI BwZLjDEXVXYBk014Bj93oC9WnST33XD7MJasQot4S+ghwvxqj0qxHK20GCRNIM18YFNLLhkY5 IR1IwddG1RFoJhHsc759b3BD1AlvB6GMv3TVdvJr4cyeAjBUGyNlCtQJgovaeu7G3DSkq2md/ X0CUpoXiOIHKN0QbzGkp/okN+c6t0sY7iL2X9wxLH1/m00mztUARypGUvYoeN7kFSaZCCyo6g GY/9UdKPO5pRBHevbVhesnYfu8vrd29UZExoMOnOxScmaHFT5jpqtbNvt53CG2DBu7zraYuRf cyYosGdzRp/IYGuzCLBcn1vQE/aVgSbqwza9dA== X-Archives-Salt: f1fad0b8-e31f-4265-90c3-bb9885faacee X-Archives-Hash: 825f3f37bb1fb54b26f961de91589dbf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --grgPN70XHZuNn6gsM5wfpOMCjkXga6UgO Content-Type: multipart/mixed; boundary="DwoW1GznTQ2sBsyBV02hZq5hxC54CyLh4"; protected-headers="v1" From: "M. J. Everitt" To: gentoo-project@lists.gentoo.org Message-ID: Subject: Re: [gentoo-project] Re: [pre-glep] Security Project Structure References: <6137e99b-2995-0569-9d3d-250924fdf116@gentoo.org> <1d3c9d30-5570-de92-3da9-75bd33c02075@gentoo.org> <21194272-4039-e473-8f57-426021fb24b7@gentoo.org> <20181204223059.GN16376@monkey> In-Reply-To: <20181204223059.GN16376@monkey> --DwoW1GznTQ2sBsyBV02hZq5hxC54CyLh4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 04/12/18 22:30, Aaron Bauman wrote: > On Tue, Dec 04, 2018 at 05:05:55PM -0500, Michael Orlitzky wrote: >> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote: >>> I personally don't agree with part of this section; security is >>> relative, and if it is stated to not be supported there are no securi= ty >>> assumptions. If anything the removal of these arches as security >>> supported demonstrates an active decisions not to support them, and >>> signals to users of these arches that they can't depend on security >>> information from Gentoo. Stable generally means a stable tree of >>> dependencies, without security assumptions, if this is e.g used in a >>> closed lab that likely doesn't impact much. >>> >> This is technically correct, but: how many users even know what a=20 >> security-supported arch is? I would guess zero, to a decimal point or = >> two. Where would I encounter that information in my daily life? >> >> If I pick up any software system that's run by professionals and that = >> has a dedicated security team, my out-of-the-box assumption is that=20 >> there aren't any known, glaring, and totally fixable security=20 >> vulnerabilities being quietly handed to me. >> >> Having a stable arch that isn't security-supported is a meta-fail... w= e=20 >> have a system that fails open by giving people something that looks li= ke=20 >> it should be safe and then (when it bites them) saying "but you didn't= =20 >> read the fine print!" It should be the other way around: they should=20 >> have to read the fine print before they can use those arches. >> > +1 > > Wonderfully put and I couldn't agree more! > I accept that this is probably (to many) a ridiculous proposal, but is it= time to reconsider our arch profile definitions of "stable", "developer" and "experimental" so that security policy is reflected in this? Somethin= g like a "gold","silver", "bronze", "copper" system perhaps, with criteria similar to the following: - Gold - fully security audited, solid dependency tree - Silver - best effort security audited, solid dependency tree - Bronze - something akin to 'Developer' currently (dependency tracked bu= t not solid) - Copper - entirely experimental For me, as a concerned user, I'm prepared to take some risks on security,= as most of my systems are behind some form of firewall, and are mostly no= t exposed to the wild internet. I would prefer that the packages I use are "stable" ie. don't have known bugs, and their dependencies all check out too. So I would qualify as a 'Silver' user. I buy the argument that there are plenty of Gentoo users who want/need/expect a 'Gold' service, and I think the security team are most= ly able to satisfy this requirement, even if arch teams are not (and I would= argue that it is simply the case that stabilisation can be 'passed' by an= y maintainer for amd64/x86 arches that makes this feasible). For arches with a depleted 'team' to do testing and stabilisation (and indeed support) there should remain scope for that arch to be able to mov= e up or down (with council approval) easily and quickly, especially if ther= e should be a resurgence in interest from prospective devs/users. This woul= d automatically fulfil the manpower requirement, and the possibility of reaching 'Gold' standard would become feasible. I think there is merit also, in the distinction between 'dev' and 'exp' profiles - and this is the reason I propose a 'Copper' status for arches which really are truly experimental or problematic. Again, if there shoul= d be an interested group willing to take on a change of status, this should= be encouraged and facilitated where possible. I apologise in advance that this is somewhat tangential to the topic of Security policy, but I feel that we shouldn't lose the basic meaning of 'stable' that we are using currently, without some form of tangible replacement. Also, we shouldn't have users jumping through too many hoops= , to get a relatively known-good setup regardless of Arch. veremitz/Michael. --DwoW1GznTQ2sBsyBV02hZq5hxC54CyLh4-- --grgPN70XHZuNn6gsM5wfpOMCjkXga6UgO 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 iQIcBAEBCAAGBQJcB5ZmAAoJEGPnxnn01DHdMR8P/0yn2T8/ql7u3i9D3+Kqoy4O BAwiEHGhc5dTFWv5Grk+nRf+TmSYf+rUa7gmW966JfkCp8c8+SflZOoBBq9bPe5k 1d7ItodL7/liql86MzAGHkB245qBwkzPH8UgwGdrkS4lw/zDS0sJ9sVUV9CjsyhR aTD5M07vqqZjv8B4jgb0HfTMBLjLfg+0Ijc/Oo87rLHodOQeKo1nBpfmojXCo3DG xTs4ksV1JYPKmT6ClO/1pjXlcKzqZTmGIzGWnmkk+eCVurnHiMzCRRh8Ka27t9fQ sYd+H9L8In/5/HUazaQW1Nk9TrlT4psYp7EUhIlxm7TnlAsDVqNex03kb3f2N5Ni S7tqVbP+GxfBCaysJhnzJzS0xTrktc+RbCzaHp27JFyrEbKQqay2SRvbuGvk0d+u 36kCxt3S1/PUdnGM8ua+7xA8gvGUGixA3m2YqRWajtIvgejDsmr91swjmkl9G0pj bBFltzPjBTwKkxeK1SJ+i7NTe/fZhHdFGTpHwDJZqJu6bzNNJrqMU+uRCPobx2Ng 67ADhaCqEu9RelNVY3j8JEBBTxkKcPy8G7uJw5eKqkMrQ3PqtfNQFcpb/NAJm4ix Bf8ynuzvMmksw71ALaypdtEv6Pd/QtIjBJWl/cEQiGUmTKuT0xe9JnS5RHlcvLFU E6EgnkeKS1LYp6hnY8o2 =vxhG -----END PGP SIGNATURE----- --grgPN70XHZuNn6gsM5wfpOMCjkXga6UgO--