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 DCD6E1381FA for ; Tue, 3 Jun 2014 22:03:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7EA3E0898; Tue, 3 Jun 2014 22:03:08 +0000 (UTC) Received: from mo4-p05-ob.smtp.rzone.de (mo4-p05-ob.smtp.rzone.de [81.169.146.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F0304E0894 for ; Tue, 3 Jun 2014 22:03:07 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyz+57jTVMtVX7771jWiJc= X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet (95-130-165-192.hsi.glasfaser-ostbayern.de [95.130.165.192]) by smtp.strato.de (RZmta 34.2 AUTH) with ESMTPSA id V026d6q53M36IOr (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) for ; Wed, 4 Jun 2014 00:03:06 +0200 (CEST) From: "Andreas K. Huettel" To: gentoo-project@lists.gentoo.org Subject: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014 Date: Wed, 4 Jun 2014 00:02:59 +0200 User-Agent: KMail/1.13.7 (Linux/3.12.13-gentoo; KDE/4.13.1; x86_64; ; ) References: In-Reply-To: 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; boundary="nextPart1924818.4tVUCMNPXP"; protocol="application/pgp-signature"; micalg=pgp-sha512 Content-Transfer-Encoding: 7bit Message-Id: <201406040003.05726.dilfridge@gentoo.org> X-Archives-Salt: eddccd43-f830-49c7-b3ba-4fdd4d412040 X-Archives-Hash: 4cbd3861741a0cc44c0107dc50205861 --nextPart1924818.4tVUCMNPXP Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman: > The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC. >=20 > Please reply to this email with any proposed agenda items. Here's an agenda item. For discussion at the moment, since this is not=20 something the council can decide on its own; we need the help of Infra and = the=20 foundation. Hopefully it will turn into something concrete, though more on = the=20 lines of a GLEP or an Infra policy. Several Infra and Council members have= =20 contributed ideas. ######## Create a mechanism how Gentoo developers can=20 * host non-critical services=20 * on self-provided machines or later Gentoo-provided machines * visible in a subdomain of gentoo.org,=20 * which they themselves administer fully and are fully responsible for * outside the direct control of Infra, but with some limitations (see below) See it as a semi-official staging area for future core services. The foundation is asked to consider supporting such initiatives financially= if=20 they are clearly in the interest of the general developer community. ######## Why? The Gentoo infrastructure is administered with the help of tools like cfeng= ine=20 or puppet, designed to distribute configuration to many machines. The way t= his=20 is set up now, fine-grained access control is not yet possible. Which means= =20 that someone planning deployment of a new service on an official machine ne= eds=20 to get access to the central repositories and thereby intrinsically also po= wer=20 over core, critical services such as, e.g., cvs.=20 Obviously administrative access to critical services should be restricted t= o a=20 small trusted group, and this is what Infra is.=20 Any new service that does not need any elevated access permissions towards= =20 core critical services (example, a repoman-checker that grabs the public=20 portage tree, analyzes it and generates alerts; example 2, a program that=20 parses ebuild SRC_URI, checks for availability of future versions, and=20 displays that information on a web interface) is effectively and unnecessar= ily=20 blocked by this architecture.=20 Our admins are busy keeping the core infrastructure running and safe (and t= hey=20 are doing this very well, thank you!); it's understandable that they may no= t=20 want to accept additional burdens. Here's the way around it.=20 Many of the pieces needed are already possible. This initiative aims to mak= e a=20 package of it and advertise it. What limitations? This is mostly obvious stuff. * The maintainers need to take security into account * Minimal/none interaction with core services (except publically available= =20 things) * No use of infra passwords / credentials * Disclaimers on the service if web-based * Possibly some sort of infra access as non-privileged user required, e.g. = for=20 running glsa-check Cheers & happy discussion,=20 Andreas =2D-=20 Andreas K. Huettel Gentoo Linux developer=20 dilfridge@gentoo.org http://www.akhuettel.de/ --nextPart1924818.4tVUCMNPXP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAABCgBmBQJTjkYZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNzlCRDk4QzA4RENBRkYzQUEwRjQzMDlF QkU2QTMzNkJFMTkwMzlDAAoJEOvmoza+GQOcfNwQAKnanKuTQq9xKUbkp6OJMkpg NpiX6zFbfXaIwFyZbuX2eDUisrYR4q1jqqUSw5YU9cLswZ1Qyx0aL4pUnxkrhQ+V H9rznKVo4AWE0u+gxugX1n2ZhCi6HEPPSb1Gfsz/RQsEagbgPt9LBjXYY1sIvmcv FVQMU9YeFERCAwIdWTT42XQSalY9rpPbGijMbYr+up29ztE1GmDoxNzgzC5kYkX8 bW6cNf9J7h+xmHFQAzmLFd6Q/W9ma4jyOEhcYILI3qpBpzvbJivFWKsjmhwYKNEd tj52BFJrnFbpV11xbCEM53wGEa06EMzh2XWLCLkHRuL3VRE2AhBXlVmVIep2ZpFg FDYMaH958Sf+FT/hqVYFi8ZaVrunzIJKiBVv5QnoAI19s8u2M+0XHvmgUscGX5Nv tw/PBO24WzBrWj2z5PVyboFkypFaLF6UOJV686N/iMUrtJ1shCr8f5RtQlLXTWtg Ux0zXLjYp38YxcbkTbcVSVOecpBWZZaouZhniPZb8M40faIBOQSSQmD//+LorSKG S2uegCg5JiMPsqNMobV80KO2C55QDfATCVTRh6zmGehLfm5vYaVcLYWGsLLjE1O1 DrkYeAbkjuB0VVsUADT1Tq3ZZfH9uNQfox8gTRqhOI5WT5/XDAjD2zQM5JoO2f8w nXVtpmdp0FutFYJWkTmM =hKfw -----END PGP SIGNATURE----- --nextPart1924818.4tVUCMNPXP--