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: Wed, 02 Jan 2019 19:56:25 +0100 Message-ID: References: <831s5v3s9w.fsf@gnu.org> <83zhsj2arw.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 1546455273 5730 195.159.176.226 (2 Jan 2019 18:54:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2019 18:54:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 02 19:54:29 2019 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 1gelev-0001QR-FP for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2019 19:54:29 +0100 Original-Received: from localhost ([127.0.0.1]:46822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gelh2-0000R0-Gr for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2019 13:56:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gelgw-0000Qr-1k for emacs-devel@gnu.org; Wed, 02 Jan 2019 13:56:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gelgu-0007AF-BT for emacs-devel@gnu.org; Wed, 02 Jan 2019 13:56:33 -0500 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:41154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gelgs-00078P-Az; Wed, 02 Jan 2019 13:56:32 -0500 Original-Received: by mail-wr1-x430.google.com with SMTP id x10so31441212wrs.8; Wed, 02 Jan 2019 10:56:28 -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:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=9lilGqmCOIjJC4FaMxDiBdisW41aE6ZWv7f/+mAN+F4=; b=PbBQNlWIDp/cl1lJSGs97Q1p/W/wJoe9D4dhgU+Z26XCeDVIBm1tQEPXFxnTPDbdF4 Rl/Dqmc3Tx0OusirZmOv9e5xWBvC/90L5kswipxqwOLUs7RMZgEF5UayWSwAO/fTtio7 Sv+csY4RZ66msbf9VPvTMxUUUfXXjA1ugxYO3suUXt9RonxfruWD2l4r2aJ9stCKrkrR n1E+A5xpH3by3sibW5yau/5wIZkL8rL2gH7g5dkS/Y12u7I8MgWjbvyDaLrfrgZzo9fu XwhyuXQqwGGUQp+x4uh9+RR9qg/9mewdpnNT76iYX5OVy9y+JoUpEysBibc20ZFEN9nc uSJg== 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:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=9lilGqmCOIjJC4FaMxDiBdisW41aE6ZWv7f/+mAN+F4=; b=j2ouf5/zCdDmZ4emtL5Ipdvz38YeHRaIvHlpB8ztpttU8Hns0pHyrQV1UjiPhlYREW VJ2OK54heClA35GlQA/kfBc0JTJxuixSJVZmOH6O5Z1hihBPtEcrCK+zHrT864qiRf+W dXMVKXmt4W/dgJhfOkSy8yW+n32LcBuacX9viwpZ2TBGu50xux07HluqmgdwT3g4nQRH nvXhdioJPuLwSXRYYOBdqNy7yFT+67V3rbh2XbzBGBUevc3edBtnH9U+z/cDgGXmOmlE tg8/inQRNnFkIU+r4N3IYHE6aibUgEbxl95yxr+3RhOhh0HDSH9NDL3OMvV6qXzmdLHo yQeQ== X-Gm-Message-State: AJcUukfpOyJTQJcqbb8MlSw4VvMYBCWa64CdRHuS9xDNfQONRvrWkUb0 jKOMNENNg6lH6RrZjM3tfJwjPJrL X-Google-Smtp-Source: ALg8bN5YZQJSKiUi8A3U2RP6pPMIGVluRb8M0SDF0ktLDArS2EacR59FnYdf1dNMpO4/PQtLKN6pgQ== X-Received: by 2002:adf:9dd2:: with SMTP id q18mr39030199wre.12.1546455386993; Wed, 02 Jan 2019 10:56:26 -0800 (PST) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:49e7:b838:816f:540b]) by smtp.gmail.com with ESMTPSA id y34sm122848915wrd.68.2019.01.02.10.56.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 02 Jan 2019 10:56:26 -0800 (PST) Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83zhsj2arw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Jan 2019 20:07:47 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::430 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:232099 Archived-At: Eli Zaretskii writes: >> From: Robert Pluim >> Cc: emacs-devel@gnu.org >> Date: Wed, 02 Jan 2019 18:47:55 +0100 >>=20 >> So nil/t would mean :nowait nil/t, and anything else would be a >> plist. > > Not exactly. What I meant is if that arg is _any_ symbol, it is > interpreted as the old NOWAIT argument; otherwise, it has to be a > plist (if not, we signal an error). > OK, I=CA=BCll make those changes. >> That applies to open-gnutls-stream, but I was asking about >> open-network-stream. For people who have no client certificate entries >> in their auth-source, there would be zero difference. > > Then perhaps I misunderstand your suggestion. Please tell more. (And > I'm talking about those for whom this change _will_ mean some > difference, not those who don't use :client-certificate.) > > I guess the part which is confusing me is this: > > 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? > For what I think is a tiny (perhaps non-existent) minority of Emacs users. I certainly didn=CA=BCt know about this corner of .authinfo until the bug report came in. >> If we don=CA=BCt change open-network-stream, then I was planning on >> changing all callers in Emacs to use :client-certificate t in any >> case, so only external users of open-network-stream would need to >> update their code to enable automatic use of client certificates. It=CA= =BCs >> those external updates I was hoping to avoid. > > Now I'm even more confused. I=CA=BCm explaining badly. Currently, specifying ':client-certificate t' to open-network-stream causes client certificates to be looked up via auth-source up when using external gnutls-cli. My fix intends to extend that behaviour to do the same when using built-in GnuTLS. So far I think that=CA=BCs uncontroversial. 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. 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. 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. Robert