emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: open-{gnutls,network}-stream backwards compatibility


From: Robert Pluim
Subject: Re: open-{gnutls,network}-stream backwards compatibility
Date: Wed, 02 Jan 2019 19:56:25 +0100

Eli Zaretskii <address@hidden> writes:

>> From: Robert Pluim <address@hidden>
>> Cc: address@hidden
>> Date: Wed, 02 Jan 2019 18:47:55 +0100
>> 
>> 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ʼll 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ʼt know about this corner of .authinfo until
the bug report came in.

>> If we donʼt 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ʼs
>> those external updates I was hoping to avoid.
>
> Now I'm even more confused.

Iʼm 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ʼs 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ʼd 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ʼd 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]