From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel Subject: Re: open-{gnutls,network}-stream backwards compatibility Date: Fri, 04 Jan 2019 23:29:17 +0100 Message-ID: References: <831s5v3s9w.fsf@gnu.org> <83zhsj2arw.fsf@gnu.org> <838t0034bh.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546641024 4161 195.159.176.226 (4 Jan 2019 22:30:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2019 22:30:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 04 23:30:20 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfXyq-0000sS-MA for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2019 23:30:16 +0100 Original-Received: from localhost ([127.0.0.1]:56128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfXyA-0008QX-7y for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2019 17:29:34 -0500 Original-Received: from eggsout.gnu.org ([209.51.188.92]:54376 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfXxy-0008ME-QB for emacs-devel@gnu.org; Fri, 04 Jan 2019 17:29:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfXxy-0007Az-PJ for emacs-devel@gnu.org; Fri, 04 Jan 2019 17:29:23 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:45109) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gfXxy-00078u-HO; Fri, 04 Jan 2019 17:29:22 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id t6so37814807wrr.12; Fri, 04 Jan 2019 14:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-followup-to:mail-copies-to :gmane-reply-to-list:date:message-id:mime-version :content-transfer-encoding; bh=aKgSgaOzVjkAFxV980n4gOKQwmxl1hM51di8IQj6F5E=; b=PmWI69gWJyMevycMubL8QUexuKu43u2eY4O7eCG40EZybsYNtdiCkoWve/W9/O7pgQ D3gqXNP1wwwnrc1sZc+/BYOEgCdeldadjBWzMc1lGe6WcFy1+4dEqOf941nuufQCQmzX xKLCZohAzqf277I2ulXjXRih9ersAir7SOj906NEeG1XoccZpjm6YWSZf2AnKBek12QE v9+zBC8QMnaBV1eSUGP+bo5ca/71oxS9ewRrUmDrbr5sBm5BVtomChknhlks8bPIERKo 47qBrDZ9gFJhpIxUPJC85qojO0OyLWsiXHU5ZglbC6n+AgASa2BnlAPjGd9PdsOCTezA 3s6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-followup-to :mail-copies-to:gmane-reply-to-list:date:message-id:mime-version :content-transfer-encoding; bh=aKgSgaOzVjkAFxV980n4gOKQwmxl1hM51di8IQj6F5E=; b=CoRzO5peo0LWblN9nBMJcEFeQg6X+8swOFjXieVoxkODzGkRUUOo7LjxregBGztI91 fASzXR0TBEk995eM5HiURgOxaJDg2Zxlqf3JicfuXrW9cntWkGAmCkn2e5Dqx1NRsoRi HEVhWgCx6Wh1xJBaWel6u4LUpFgbrVGYcUFWPrXG21NtVHtYjLXcyzaIPRlSZYeFdzeP vKA7g9CJKjNbEG+y2jBynD0iRJmLbl3JPvrfG07drOU7nxJzUfHffchEHcBS5nuEu1q9 KMpnyQz1dS7OwRY9dr5Owsk73u9cVnc5YrSzff+A4hgDrnezEmZs9sUehZvuXY8Hw1ux eqzg== X-Gm-Message-State: AJcUukdcyxhAV8y0nEpYYMT1wwQlq6u1UhhRwD2h/CPBwpfFMGFy39kH QumqjWy5VzZpUUrF/Xq2ZANOhigq X-Google-Smtp-Source: ALg8bN4cl/rOnE8rdumKklYKGLXswtgiwqENmCO1SMdVkWaMqxSjSIKdsWBZZEynnFF+z06gx4OAeA== X-Received: by 2002:adf:b6a1:: with SMTP id j33mr45372305wre.55.1546640960518; Fri, 04 Jan 2019 14:29:20 -0800 (PST) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:191f:f3bc:2f65:d8e6]) by smtp.gmail.com with ESMTPSA id x3sm43541024wrd.19.2019.01.04.14.29.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 Jan 2019 14:29:19 -0800 (PST) Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Gmane-Reply-To-List: yes X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42e 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:232178 Archived-At: Eli Zaretskii writes: >> From: Robert Pluim >> Cc: emacs-devel@gnu.org >> Date: Wed, 02 Jan 2019 19:56:25 +0100 >>=20 >> > change open-network-stream such that not specifying >> > :client-certificate is the same as specifying t >> > >> > Doesn't this mean an incompatible change in behavior? >>=20 >> For what I think is a tiny (perhaps non-existent) minority of Emacs >> users. > > We have no reliable way of estimating the number of affected users. > Besides, even if there's only a single user affected, it requires us > to consider this an incompatible change, which should be avoided if > possible. > OK. We can check back in a year to see how many people have changed the configuration variable below from the default. > >> My follow-on to that fix would be to assume that not specifying >> :client-certificate at all when calling open-network-stream is the >> same as specifying ':client certificate t'. Only people with existing >> client certificate entries in their auth-source provider (such as >> .authinfo) would see a change in behaviour. > > It's still a change. At the very least, we should provide a way to > have the old behavior back. > See below >> If that last change is unacceptable, I=CA=BCd want to change all the >> callers of open-network-stream inside Emacs to specify >> ':client-certificate t'. People using built-in Emacs packages would >> then be able to use client certificates by changing configuration data >> only. People using packages developed outside Emacs would need to >> update those external packages to versions which specify >> ':client-certificate t', which is what I=CA=BCd like to avoid. >>=20 >> Short version: we assume a username/password entry in auth-source for >> a specific server means 'use this username/password', so we should do >> the same for a client-certificate specification. > > I don't necessarily disagree, provided that we give users who > want/need that a way to get back the old behavior. Maybe I'm > misunderstanding, but it sounds like both of your alternatives are > backward-incompatible, so they both need such a "fire escape". How about: (defcustom network-stream-use-client-certificates "Whether to use client certificates for network connections. If set to the default value t, `open-network-stream' will automatically look for matching client certificates (via 'auth-source') for a destination server, but only if it is called without a :client-certificate keyword. Set to nil to disable this lookup globally. To disable on a per-connection basis specify ':client-certificate nil' when calling `open-network-stream'. :type '(choice (const t :tag "Always") (const nil :tag "Never"))) (Now to find which custom group this goes in...) Robert