From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: :file keyword for Customize Date: Fri, 09 May 2008 09:11:31 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <86iqxnpnxo.fsf@lifelogs.com> References: <004101c8b129$788cd490$0ab32382@us.oracle.com> <85zlr0msi8.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1210342134 11849 80.91.229.12 (9 May 2008 14:08:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 May 2008 14:08:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 09 16:09:29 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JuTHo-0005de-9J for ged-emacs-devel@m.gmane.org; Fri, 09 May 2008 16:09:24 +0200 Original-Received: from localhost ([127.0.0.1]:51584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuTH5-00086S-Vs for ged-emacs-devel@m.gmane.org; Fri, 09 May 2008 10:08:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JuTGz-00086H-63 for emacs-devel@gnu.org; Fri, 09 May 2008 10:08:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JuTGw-000855-BI for emacs-devel@gnu.org; Fri, 09 May 2008 10:08:32 -0400 Original-Received: from [199.232.76.173] (port=54850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuTGw-000852-6j for emacs-devel@gnu.org; Fri, 09 May 2008 10:08:30 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:38327 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JuTGv-0005FG-JU for emacs-devel@gnu.org; Fri, 09 May 2008 10:08:30 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JuTGp-0005DW-Bb for emacs-devel@gnu.org; Fri, 09 May 2008 14:08:23 +0000 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 May 2008 14:08:23 +0000 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 May 2008 14:08:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:Mjd0y4g1uCkNj01V3dNTNZTtbZw= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:96886 Archived-At: On Thu, 08 May 2008 22:48:47 +0200 David Kastrup wrote: DK> So what? [the user's custom file] is a "monolithic blob" not DK> intended for human consumption, and one can't really delay loading DK> it, anyway. So all this buys us is added complication and longer DK> load times. I think monolithic blobs have historically been proven unsuitable for human consumption. In the case of a binary, that's fine. For configuration data, that's dangerous. For example, the /etc/shadow file is intended to make the /etc/passwd file less dangerous when compromised. /etc/passwd can do the job by itself, but it makes sense for security to take the dangerous bits out. As another example, the Windows registry is a monolithic blob. A special tool is needed to edit the blob and its capabilities are limited by the lowest common denominator (key=value, plain text data). In the same way a user's customizations for authentication are more sensitive than the default customizations, and should probably be stored in a separate file that's encrypted with some mechanism. The default customizations are then available to fellow users without danger of compromising security. In the case of Gnus, it makes sense to separate Gnus-specific settings. I do this manually in my gnus.el, but I can't customize the Gnus variables without a manual resync between my custom file and gnus.el. I think Drew's proposal is worth considering as an add-on package, but I wouldn't push it on every user by default. Ted