From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1I1A1R-0001Go-Ql for garchives@archives.gentoo.org; Wed, 20 Jun 2007 23:55:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l5KNscM8022493; Wed, 20 Jun 2007 23:54:38 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l5KNqj9P020262 for ; Wed, 20 Jun 2007 23:52:45 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 4456E64C45 for ; Wed, 20 Jun 2007 23:52:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 required=5.5 tests=[AWL=-0.696, RCVD_NUMERIC_HELO=1.253] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoNv8CFeW60j for ; Wed, 20 Jun 2007 23:52:43 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5282864ECC for ; Wed, 20 Jun 2007 23:52:42 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I19yQ-0007Lk-Oi for gentoo-dev@gentoo.org; Thu, 21 Jun 2007 01:52:30 +0200 Received: from 81.5.170.119 ([81.5.170.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jun 2007 01:52:30 +0200 Received: from slong by 81.5.170.119 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jun 2007 01:52:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: how to handle sensitive files when generating binary packages Date: Thu, 21 Jun 2007 00:51:48 +0100 Message-ID: References: <200706200047.04951.vapier@gentoo.org> <200706201627.27790.vapier@gentoo.org> <20070620213546.0352ca85@snowflake> <200706201654.35042.vapier@gentoo.org> <20070620220142.629252a4@snowflake> <1182378692.21577.4.camel@inertia.twi-31o2.org> <20070620233541.1a3ffa00@snowflake> <1182380913.21577.20.camel@inertia.twi-31o2.org> <1182381155.6470.17.camel@ashe.anyarch.net> 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@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 81.5.170.119 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 8e0c88ac-9214-4d70-9416-259101155798 X-Archives-Hash: 057353d32ef6403c668f59a2702ddb86 >> Oh yeah,and who said we really needed more than one use case? I think >> providing tools to allow Gentoo to be adopted in the corporate >> environment is reason enough to have binary package support, and I feel >> that many people will agree with me. >> Well I'm sure you'll be over the moon to know I do ;) > > The issue isn't whether or not we should have them, or for that matter > whether or not there is more then one use case. The issue is making sure > that we know what the use cases are to ensure that the tools we have are > flexible enough to be able to support every case and so that we don't > paint ourselves into a corner by making decisions before we know how > people plan on using the tool. > Agreed, but the actual mechanism in question is only adds functionality; nothing is being taken away aiui. As to it borking use cases, surely it's better to explain which use case it breaks than get into a nitpick about whether there might be any others. After all that's why there's an externally-facing list: so people can chime in with their concerns. The discussion on default policy doesn't change the fact that it is a needed mechanism, imo. Having it as a switch in FEATURES makes a lot of sense, and i think that ensuring Gentoo systems won't leak sensitive information, unless explicitly told to, is a worthwhile objective. A warning when adding sensitive files to a binpkg seems like a wise idea, especially if it is a set and forget flag. (Devs can always tweak an env var, users who've lost data are harder to mollify.) -- gentoo-dev@gentoo.org mailing list