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: NSM certificate prompt Date: Sun, 14 Dec 2014 06:34:32 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87egs2zcqf.fsf@lifelogs.com> 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> <83mw6q51x4.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418556856 20842 80.91.229.3 (14 Dec 2014 11:34:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 11:34:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 12:34:08 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 1Y07RA-00006a-E6 for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 12:34:08 +0100 Original-Received: from localhost ([::1]:35639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y07R9-0004b7-UY for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 06:34:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y07R2-0004ab-1r for emacs-devel@gnu.org; Sun, 14 Dec 2014 06:34:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y07Qw-0006b3-Sf for emacs-devel@gnu.org; Sun, 14 Dec 2014 06:34:00 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y07Qw-0006az-Lg for emacs-devel@gnu.org; Sun, 14 Dec 2014 06:33:54 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y07Qv-00083A-J8 for emacs-devel@gnu.org; Sun, 14 Dec 2014 12:33:53 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Dec 2014 12:33:53 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Dec 2014 12:33:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 75 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net 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" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:7nxzhCdg9ZVimRrTkr9nHL8+wow= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:180065 Archived-At: On Sun, 14 Dec 2014 05:46:15 +0200 Eli Zaretskii wrote: >> 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. EZ> If she's not authorized, she doesn't necessarily know what she is EZ> doing. This is security, right? The authentication and authorization structure of the host system targets different risks. I've often had the need to build and install binaries or dynamically updated external package systems like oh-my-zsh for instance. Even when I was the host system's manager, it didn't always make sense to make system-level changes to accommodate one user's preferences and needs. >> 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. EZ> This case means the user should want to _add_ certificates, not remove EZ> the system ones. There have been several cases where users wanted to remove certificates signed by a compromised certificate authority before updated CA certificate OS packages were available. Sometimes a few hours can be critical in these situations. While CRL support is a good way to deal with this in general, I still think giving the user the option to manage their trustfiles is valuable. But we should definitely try to support CRLs or DANE more urgently, rather than expecting the user to manage trustfiles and certificate revocations. >> But even if we decide to make 'system the only option EZ> That's not my suggestion. My suggestion is always to use system trust EZ> (when it's available), and in addition allow the user to customize EZ> gnutls-trustfiles. The only issue is whether to have 'system' in EZ> gnutls-trustfiles and allow its removal. OK, sorry, I was arguing with a straw man. I think there's a better approach, below... EZ> Fine. I'm going to make this a Windows-only code, and we can then EZ> stop arguing. Please add the code unconditionally as you planned. I think it will be an improvement that way. I will then add code to make the transition easier after your patch: * add a featurep or a function to GnuTLS that tells us if that system function is available * when it's available, default the trustfiles to nil * when it's not available, use the old trustfiles default * add a specific boolean option to disable that system function, off by default * improve messaging to tell the user what trustfiles we're loading * update NEWS, docs, etc. I hope that's more agreeable. Ted