From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: NSM certificate prompt Date: Sun, 14 Dec 2014 05:46:15 +0200 Message-ID: <83mw6q51x4.fsf@gnu.org> References: <83a92r625n.fsf@gnu.org> <87wq5vefiz.fsf@gmx.de> <83388j5wrs.fsf@gnu.org> <87mw6reaxu.fsf@gmx.de> <83y4qb4eeg.fsf@gnu.org> <83vblf4b2p.fsf@gnu.org> <87r3w3z60b.fsf@lifelogs.com> <83r3w348m8.fsf@gnu.org> <87iohfyprn.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418528817 5835 80.91.229.3 (14 Dec 2014 03:46:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 03:46:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 04:46:50 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y008v-00045T-BO for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 04:46:49 +0100 Original-Received: from localhost ([::1]:34907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y008u-0005EM-QR for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 22:46:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y008l-0005Dz-Rz for emacs-devel@gnu.org; Sat, 13 Dec 2014 22:46:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y008f-0003Ew-UR for emacs-devel@gnu.org; Sat, 13 Dec 2014 22:46:39 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:34487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y008f-0003Ef-HM for emacs-devel@gnu.org; Sat, 13 Dec 2014 22:46:33 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NGJ00A00ZNSK000@mtaout28.012.net.il> for emacs-devel@gnu.org; Sun, 14 Dec 2014 05:44:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGJ004VSZPOLY40@mtaout28.012.net.il> for emacs-devel@gnu.org; Sun, 14 Dec 2014 05:44:13 +0200 (IST) In-reply-to: <87iohfyprn.fsf@lifelogs.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180048 Archived-At: > From: Ted Zlatanov > Date: Sat, 13 Dec 2014 20:38:20 -0500 > > EZ> What would be the reason for the user to remove 'system from the list? > EZ> If a user is somehow not happy about system trust data, she should > EZ> customize her system (if she is authorized), not Emacs. E.g., add a > EZ> list of blacklisted certificates, remove certificates from the bundle, > EZ> etc. > > I don't see how it's OK to exclude users who are not authorized to > customize their systems. This is a common case. If she's not authorized, she doesn't necessarily know what she is doing. This is security, right? > Another case is where the system is out of date and you don't have the > option of updating it, because it's too old or the update server is > down. This case means the user should want to _add_ certificates, not remove the system ones. > There's also the case that you may not want to use the host OS's trust > store for your own reasons. That should not be a struggle. Emacs is > not a all-in-one web browser, it's a platform. Don't take away the > users' choice of who they trust. No other browser I know of allows that. > Furthermore, GnuTLS until recently didn't have this functionality and > somehow we survived. So it's not essential. We survived because we do the equivalent by reading gnutls-trustfiles. > But even if we decide to make 'system the only option That's not my suggestion. My suggestion is always to use system trust (when it's available), and in addition allow the user to customize gnutls-trustfiles. The only issue is whether to have 'system' in gnutls-trustfiles and allow its removal. > we'd have "if you're running GnuTLS 3.x or older, you'll get this > behavior, but with 3.y or newer, another behavior." Yes, and why is that a problem? Differences in behavior in different versions exist whether we want it or not. > I think it's pretty unpleasant behavior to dynamically toggle who > you trust based on system library versions. So unless we *only* > support GnuTLS versions that have this functionality, I'm strongly > against making it the only option when it's available. > > Finally, we have to consider backward compatibility. Users who have > customized their trustfiles should not be surprised. We can put > warnings in NEWS and blame the users when they don't read them, but I > think it's much nicer to preserve the users' customizations. Fine. I'm going to make this a Windows-only code, and we can then stop arguing.