From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Sat, 23 Jun 2018 14:05:29 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1529755458 18541 195.159.176.226 (23 Jun 2018 12:04:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2018 12:04:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Paul Eggert , emacs-devel@gnu.org To: Jimmy Yuen Ho Wong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 14:04:13 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWhH1-0004e1-Bu for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2018 14:04:11 +0200 Original-Received: from localhost ([::1]:38323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWhJ6-0007bS-QF for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2018 08:06:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWhIP-0007b9-U3 for emacs-devel@gnu.org; Sat, 23 Jun 2018 08:05:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWhIM-000350-Ou for emacs-devel@gnu.org; Sat, 23 Jun 2018 08:05:37 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:39725) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fWhIM-00034d-Ho for emacs-devel@gnu.org; Sat, 23 Jun 2018 08:05:34 -0400 Original-Received: from cm-84.212.221.165.getinternet.no ([84.212.221.165] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fWhIH-0001L1-QS; Sat, 23 Jun 2018 14:05:31 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAD1BMVEVAPjsKCAVwbGohHxy4 tbKo62GwAAACeklEQVQ4jT2UAZKsMAhESfAARucAETlAYuYALnL/M/0m7n6rpsqaF6ChiZSOUssY o5dSRvYkIoRnkFfxAHuf4Bi/D3k27wjoe9mb+KGfn7L60eh2nyCVspNYcu30sYcIOaWPFiX2XOlx ++BoekEZVLKllS8391UfvWk+OxG7W9QwX9S8GlGJHIABBEA3vPnTqH6dmSiLWQuAzPjdg8z1Bljc MgUwB6qQa769wNEqAPRUotSQ+xsgu98zQtZ8bbU2JP8OnsVvUgC8tkbcoEp2JqmqNSsUpBYTjVnh KCPH4imA3xnjjRRo54ROrRYRODWaoDrTihkgU9TNCrEPl3WC8nHUWExdMFxzylTaBGVgRhkBFXEm zKOsL4BBlTSAZROMIE1wlPWBamTK6pWQ0s8JnCCXqkdtwAAPqjN9/UZxOGT6B84rBOPlZ09ft6aq khHqj5rUF5TFRTVr5QYAP+rrYAFQV+xYLwAamxGz+in718Xl0toHMsgEon4U+ITeUHMCLOgotPmJ DjESnRErpB07NnmmWgFQ8yvCi5hyrPhUtTYMH6kMIk/xhkl0go2lrDhn9cKKhiUXX5ReVeEUALzC XOyCfxGRA1yCf4WWKwzL3Dpg/pmGABjnS+SEMQBvg7HzjIgMRxgD4bf4TuEdxYTy7DPA4h2icBHx O3dEWZY6ElLpESDjrhgPVmxVBUDny9MjQu+GBRuY+Dj5bySbx8aRVd4DMONux01LW2wC1MoAoF8A hBrze2DS97mePQDuX18RgR5uRjXK9YzPBMU6rnHzcPG4b+ifTnwlynufw34AGpv8B40uuIjUEMwA 6kvEJwIsIRdTqQGqZDg4yj9jNZlxNi4UYQAAAABJRU5ErkJggg== In-Reply-To: (Jimmy Yuen Ho Wong's message of "Sat, 23 Jun 2018 12:55:03 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:226618 Archived-At: Jimmy Yuen Ho Wong writes: > It's not supposed to -- the connection is stopped at the gnutls level. > Which is why that variable defaults to 256, so that the NSM can handle > the problem. > > How about moving the min-prime-bits knob over to NSM so it can warn > instead of silently bypassing it by fiddling options directly related > to GnuTLS? The NSM does warn about this. Unless you've fiddled with the options, which you've chosen to do yourself. The low-level variables doc strings should mention that you're not supposed to fiddle with them unless you have very specific needs and point you to the NSM instead. > I also notice there's a `nsm-noninteractive` var, it's only used in 1 > place so far. Can we defcustom it and sprinkle a check for this var > strategically such that people who are using Emacs in a script can > still do it without fiddling with the GnuTLS options? In fact, what if > we merged all the NSM and GnuTLS options into NSM so various modules > can rely on it as a central point of control? Well... The low-level variables (which probably shouldn't be defcustoms) are useful in some scenarios. If you're writing an application that needs very specific connection parameters, you have to be able to pass them in to the library. let-binding them provides that flexibility. I don't think `nsm-noninteractive' should be a defcustom, but perhaps there should be a `quit' value to `network-security-level' that just aborts on any network strangeness without querying the user. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no