From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.3/8.13.3) with ESMTP id j2DFetvT007735 for ; Sun, 13 Mar 2005 15:40:55 GMT Received: from adsl-67-39-48-196.dsl.milwwi.ameritech.net ([67.39.48.196] helo=freedom.wit.com) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DAVD3-0007yN-Ul for gentoo-dev@robin.gentoo.org; Sun, 13 Mar 2005 15:40:54 +0000 Date: Sun, 13 Mar 2005 09:40:16 -0600 From: Brian Harring To: gentoo-dev@robin.gentoo.org Subject: [gentoo-dev] whitelisting the env ebuilds execute in Message-ID: <20050313154016.GC19847@freedom.wit.com> Precedence: bulk List-Post: , , List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-To: gentoo-dev@gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Archives-Salt: 890300f6-04fa-4dac-9e50-04c9102a192c X-Archives-Hash: d3befe3dde98e3e6b8064f259f05ee2e --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject pretty much says it all. Currently *everything* from the users env= winds up being available to ebuilds. This complicates the hell out of my job of maintaining env handling (saving= , transfering, reloading) in portage-cvs-=20 having literally hundreds of env vars defined prior to even adding in the e= build/eclass/portage env additions. So... yeah. Anyone got a good reason why all vars should be dumped into th= e ebuild environment? I don't see the=20 point in all of my binpkgs having my ECHANGELOG_USER setting, for example. Assuming no one can come up with a valid reason why the entire user env mus= t be dumped into the compilation=20 environment, whitelisting of vars that are allowed in would be the next ste= p. LINGUAS, EXTRA_ECONF, etc. Portage cvs already does it's own filtering of the vars it knows don't belo= ng in the env- portage innard vars for=20 example, are explicitly removed from any saved env. The reason behind this= is that portage wants to control those=20 vars itself, basically striving for a controlled environment for ebuild exe= cution (whether setup phase or compile). I don't see why the same control shouldn't be extended to the portions of a= users env that get pulled in. =20 Ultimately, a user can sidestep it also via profile and portage bashrcs (so= it's not a total lockdown on the env). Thoughts? ~harring --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCNF7gvdBxRoA3VU0RAmrOAKCQ94NbGUNkBc7kvTT1sIkG+CSbxwCgyYbg Sl1zgUbvHin1E7w7oCOXUy0= =xG4k -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- -- gentoo-dev@gentoo.org mailing list