GNU bug report logs - #47788
Add support for TLS client certificates to 'erc-tls'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47788 in the body.
You can then email your comments to 47788 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Cc: emacs-erc <at> gnu.org, jp <at> neverwas.me
Subject: Add support for TLS client certificates to 'erc-tls'
Date: Thu, 15 Apr 2021 00:16:38 -0400

[Message part 1 (text/plain, inline)]

Tags: patch

After a few recent changes in my IRC/ERC setup, I felt ERC's lack of
support for connecting to IRC networks using TLS client certificates as
an alternative to traditional password-based authentication.  So I spent
some time a few nights ago and wired things up in ERC to allow passing a
client certificate to `open-network-stream'.

Fellow ERC user 'neverwas' was kind enough to take my patch for a test
drive and provide feedback.  I have done some work on addressing their
feedback, but for now I'm attaching my very first draft here which I'd
sent to neverwas, and will attach the next version of my patch (along
with a proper commit message, NEWS entry, etc) shortly after neverwas's
reply with their feedback.

For anyone wanting to take this for a spin, the changes here should be
fully backward-compatible, and should not break anything in existing ERC
configurations.  To specify a client certificate, call `erc-tls' with
the new keywords :client-key and :client-crt with the file name of the
certificate key and certificate file itself respectively:

    (erc-tls :server "chat.freenode.net" :port 6697
             :client-key "~/my-freenode-cert.key"
             :client-crt "~/my-freenode-cert.crt")


In GNU Emacs 28.0.50 (build 43, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.10, Xaw3d scroll bars)
 of 2021-04-14 built on trisquel
Repository revision: 4ddad8f1db1f888f3365ac1330989dfbee605dd5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Trisquel GNU/Linux Etiona (9.0)

Configured using:
 'configure --without-gconf --without-gsettings --without-gpm
 --with-x-toolkit=lucid --with-xaw3d --with-mailutils'

[0001-Add-support-for-TLS-client-certificates-to-erc-tls.patch (text/patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Amin Bandali <bandali <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, emacs-erc <at> gnu.org
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Thu, 15 Apr 2021 05:44:03 -0700

Amin Bandali <bandali <at> gnu.org> writes:

> Fellow ERC user 'neverwas' was kind enough to take my patch for a test
> drive and provide feedback.  I have done some work on addressing their
> feedback, but for now I'm attaching my very first draft here which I'd
> sent to neverwas, and will attach the next version of my patch (along
> with a proper commit message, NEWS entry, etc) shortly after neverwas's
> reply with their feedback.

Hey 'bandali' :-)

Below is what I sent you previously. I look forward to trying out the
latest changes!

-------------------- Start of forwarded message --------------------
From: "J.P." <jp <at> neverwas.me>
To: bandali <at> gnu.org
Subject: ERC TLS client certificate
Date: Sat, 10 Apr 2021 07:41:56 -0700

As always, these are just the impressions of an average dummy, so feel
free to dismiss them.

Since my setup is probably the most common (GNU/Linux, x86_64, 28.0.50),
you likely already have it pretty well covered. A few environmental
details I'll mention anyway just in case they add anything:

1. patch applied atop

    commit 0db2126d7176b0bd1b13d4b0d1cd958c8cf55714
    Author: Dmitry Gutov <dgutov <at> yandex.ru>
    Date:   Sat Apr 10 01:51:39 2021 +0300

   with debugging symbols present and no optimization

2. Emacs invoked with -Q -nw and piloted manually thereafter

3. single file used for both key and cert (combined PEM format)

4. isolated network namespace

  sh:~$ ss -tpn
  Local Address:Port   Peer Address:Port Process
      127.0.0.1:54982     127.0.0.1:6670  users:(("emacs",pid=151118,fd=8))
      127.0.0.1:34874     127.0.0.1:6697  users:(("socat",pid=160299,fd=5))
      127.0.0.1:6670      127.0.0.1:54982 users:(("socat",pid=160299,fd=6))
          [::1]:42176         [::1]:6667
          [::1]:42178         [::1]:6667
          [::1]:6667          [::1]:42178 users:(("oragono",pid=147008,fd=9))
  ff:127.0.0.1]:6697  ff:127.0.0.1]:34874 users:(("oragono",pid=147008,fd=11))
          [::1]:6667          [::1]:42176 users:(("oragono",pid=147008,fd=10))

  Oragono is the server accepting TLS on 6697 and talking to the two
  non-Emacs clients (bots) on 6667 (non-TLS). The socat proc is
  listening on 6670 and forwarding to 6697; its purpose is explained
  below.


Notes
~~~~~

The buffer-local vars you've introduced follow existing conventions in
that they're basically there for recording the options during
entry-point invocation to aid later in reconnecting. For example,
erc-session-connector remembers the initial stream opener, etc.

I've tested this persistence aspect by pulling the plug on an active
session with healthy traffic (hence the socat proxy). It reconnected
successfully with no hiccups, so I think that's one for the win column.

You've probably gamed out the trade-offs more than I have, but seems to
me that mulling over all the ways of specifying TLS connection params
short of explicitly passing them around as you do is kind of moot. I
couldn't think of any that (1) don't buck existing library trends and
(2) make things any easier to maintain/debug. So might as well stick to
the status quo, I guess.

In terms of preserving extensibility and leaving existing escape hatches
intact, it's hard to be sure without test cases or protracted trials,
but if I had to guess, it looks like you're pretty safe in that
department as well. For example, I can't see how folks with their own
erc-server-connect-function would experience any churn from these
changes.

I see you've updated the doc string for the plain `erc' entry point to
include the two new params. Maybe it's also worth mentioning that
specifying them won't magically enable TLS. Users will still need to use
`erc-tls' (right?).

Beyond that, users may appreciate a mention of the new additions in the
info manual and maybe the wiki as well (instead of just NEWS).

Lastly, in the function erc-open-tls-stream, do you maybe want
plist-member instead of plist-get?

  (let ((p (plist-put parameters :type 'tls))
        args)
    (unless (plist-get p :nowait)
    ;;       ^~~~~~~~~~~
      (setq p (plist-put p :nowait t)))
    (setq args `(,name ,buffer ,host ,port ,@p))

As is, I think it basically enforces non-nil (unless that's the idea).

In general, I think these changes lower the barrier to entry by getting
folks connected faster OOTB, which can only help with adoption and
mind/market share.

J.P.
-------------------- End of forwarded message --------------------

Message #11 received at 47788 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 47788 <at> debbugs.gnu.org, emacs-erc <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#47788: Add support for TLS client certificates to 'erc-tls'
Date: Fri, 16 Apr 2021 09:38:49 +0200

>>>>> On Thu, 15 Apr 2021 00:16:38 -0400, Amin Bandali <bandali <at> gnu.org> said:

    Amin> Tags: patch
    Amin> After a few recent changes in my IRC/ERC setup, I felt ERC's lack of
    Amin> support for connecting to IRC networks using TLS client certificates as
    Amin> an alternative to traditional password-based authentication.  So I spent
    Amin> some time a few nights ago and wired things up in ERC to allow passing a
    Amin> client certificate to `open-network-stream'.

It would be nice if you could arrange for an option to pass
':client-certificate t' to 'open-network-stream' so it would leverage
'auth-source'

Robert

Message #14 received at 47788 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: 47788 <at> debbugs.gnu.org,  emacs-erc <at> gnu.org
Cc: Robert Pluim <rpluim <at> gmail.com>, "J.P." <jp <at> neverwas.me>
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Sun, 18 Apr 2021 15:23:18 -0400

[Message part 1 (text/plain, inline)]

J.P. writes:

[...]
>
> Hey 'bandali' :-)

Hey :-)

> Below is what I sent you previously. I look forward to trying out the
> latest changes!

Thanks again for your feedback!  I'll address each point inline, and
attach an updated version at the end of the message.

> From: "J.P." <jp <at> neverwas.me>
> Subject: ERC TLS client certificate
> Date: Sat, 10 Apr 2021 10:41:56 -0400 (5 days, 9 hours, 28 minutes ago)
> To: bandali <at> gnu.org
>
> As always, these are just the impressions of an average dummy, so feel
> free to dismiss them.

Please be kinder to yourself :-).  All feedback and impressions are
welcome and very much appreciated.

[...]
>
> Notes
> ~~~~~
>
> The buffer-local vars you've introduced follow existing conventions in
> that they're basically there for recording the options during
> entry-point invocation to aid later in reconnecting. For example,
> erc-session-connector remembers the initial stream opener, etc.

Indeed.

> I've tested this persistence aspect by pulling the plug on an active
> session with healthy traffic (hence the socat proxy). It reconnected
> successfully with no hiccups, so I think that's one for the win column.

Oh great, thanks for testing that scenario specifically!

> You've probably gamed out the trade-offs more than I have, but seems to
> me that mulling over all the ways of specifying TLS connection params
> short of explicitly passing them around as you do is kind of moot. I
> couldn't think of any that (1) don't buck existing library trends and
> (2) make things any easier to maintain/debug. So might as well stick to
> the status quo, I guess.

Right, I gave it some thought and I thought this would be the most
straightforward and "idiomatic" (w.r.t. the rest of the ERC codebase)
way of doing it.  That said, I'd welcome ideas for simplifying and/or
improving the implementation as part of this patch, or the status quo in
general in separate patches.

> In terms of preserving extensibility and leaving existing escape hatches
> intact, it's hard to be sure without test cases or protracted trials,
> but if I had to guess, it looks like you're pretty safe in that
> department as well. For example, I can't see how folks with their own
> erc-server-connect-function would experience any churn from these
> changes.

Right, yeah I made sure to not change the existing parameters of any of
the functions and/or their order and only add new parameters at the end,
so as to not break any existing configurations.  But indeed, having a
test suite would've been nice to help give more assurance about that.

> I see you've updated the doc string for the plain `erc' entry point to
> include the two new params. Maybe it's also worth mentioning that
> specifying them won't magically enable TLS. Users will still need to use
> `erc-tls' (right?).

Indeed, very much so!  Thanks for noticing that; amended in v2.

> Beyond that, users may appreciate a mention of the new additions in the
> info manual and maybe the wiki as well (instead of just NEWS).

Certainly; done in v2.

> Lastly, in the function erc-open-tls-stream, do you maybe want
> plist-member instead of plist-get?
>
>   (let ((p (plist-put parameters :type 'tls))
>         args)
>     (unless (plist-get p :nowait)
>     ;;       ^~~~~~~~~~~
>       (setq p (plist-put p :nowait t)))
>     (setq args `(,name ,buffer ,host ,port ,@p))
>
> As is, I think it basically enforces non-nil (unless that's the idea).

Indeed :-).  My intention was to enforce non-nil there, to always make
the connection in an asynchronous/non-blocking way, similar to its dual,
`erc-open-network-stream'.  I think passing :nowait nil could be useful
for debugging, but off top of my head I can't think of any other reason
one would want to do it.  And for debugging, one could easily redefine
the function completely.  On the other hand, I don't see any harm in
allowing/respecting :nowait nil if it's explicitly set.  So I've changed
the above plist-get to plist-member in v2.

> In general, I think these changes lower the barrier to entry by getting
> folks connected faster OOTB, which can only help with adoption and
> mind/market share.

Great!  It certainly scratches an itch for me personally and greatly
simplifies the use-case of authenticating with client certificates.
Hopefully others will find this useful as well. :-)

                                 * * *

Robert Pluim writes:

[...]
> It would be nice if you could arrange for an option to pass
> ':client-certificate t' to 'open-network-stream' so it would leverage
> 'auth-source'

Thanks for the suggestion.  After some thought, I decided to change the
interface of erc-tls from the two separate :client-key and :client-crt
arguments in v1 of the patch to just one :client-certificate in v2,
matching that of `open-network-stream'.  I tested the change with
`:client-certificate t' and confirm that it works fine for me.

I've attached v2 below, and if there are no other comments or feedback
I'll commit it to emacs.git in a few days.  Main changes from v1 include
using just one :client-certificate argument like `open-network-stream',
adding a NEWS entry, and documenting erc-tls in the ERC manual.

                                 * * *

[0001-Add-support-for-using-a-TLS-client-certificate-with-.patch (text/x-diff, attachment)]

Message #17 received at 47788 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 47788 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>, emacs-erc <at> gnu.org
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Tue, 20 Apr 2021 06:49:57 -0700

Amin Bandali <bandali <at> gnu.org> writes:

>> It reconnected successfully with no hiccups, so I think that's one
>> for the win column.

This continues to be the case with the latest changes applied; ditto
when using the authinfo variant of the new :client-certificate param.

>> Beyond that, users may appreciate a mention of the new additions in the
>> info manual and maybe the wiki as well (instead of just NEWS).
>
> Certainly; done in v2.

Nice job. This sort of thing can be a real time sink (at least for me).

One question. And stop me if I've confused myself here, but the doc
string and the tex-info section for `erc-tls' both offer the same
example (borrowed from their plain `erc' counterparts) in which the
function `erc-compute-full-name' is said to be consulted despite the
:full-name "Harry S. Truman" keyword arg being present. While it's
(technically) true that `erc-compute-full-name' always runs, I suspect
its inclusion in the original example was inadvertent (or something
about it has changed since 2007). Would it perhaps make sense to omit
`erc-compute-full-name' from the Truman example?

>> As is, I think it basically enforces non-nil (unless that's the idea).
>
> Indeed :-).  My intention was to enforce non-nil there, to always make
> the connection in an asynchronous/non-blocking way, similar to its dual,
> `erc-open-network-stream'.  I think passing :nowait nil could be useful
> for debugging, but off top of my head I can't think of any other reason
> one would want to do it.  And for debugging, one could easily redefine
> the function completely.  On the other hand, I don't see any harm in
> allowing/respecting :nowait nil if it's explicitly set.  So I've changed
> the above plist-get to plist-member in v2.

Thanks, but I shouldn't have proposed that tweak without a concrete use
case in mind. In fact, I've only ever needed :nowait to be nil when
using a custom opener. If my suggestion made things more confusing or
distracting, my apologies. Perhaps it's best to just revert to what you
had originally or even just force it to t. (Not that you should waste
another second on this relative nothingburger.)

> Thanks for the suggestion.  After some thought, I decided to change the
> interface of erc-tls from the two separate :client-key and :client-crt
> arguments in v1 of the patch to just one :client-certificate in v2,
> matching that of `open-network-stream'.  I tested the change with
> `:client-certificate t' and confirm that it works fine for me.

The interface change is a welcome improvement, IMO. Although dealing
with a list may feel slightly more cumbersome to some, the multiple
helpful examples make that a nonissue. (And sparing contributors an
extra param to worry about is a nice bonus as well.) But I guess the
real win is in accommodating the authinfo facility, which seems a rather
obvious and essential inclusion in retrospect. Great work!

Message #22 received at 47788-done <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: "J.P." <jp <at> neverwas.me>
Cc: Robert Pluim <rpluim <at> gmail.com>, 47788-done <at> debbugs.gnu.org,
 emacs-erc <at> gnu.org
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Thu, 22 Apr 2021 20:45:29 -0400

[Message part 1 (text/plain, inline)]

J.P. writes:

> Amin Bandali <bandali <at> gnu.org> writes:
>
>>> It reconnected successfully with no hiccups, so I think that's one
>>> for the win column.
>
> This continues to be the case with the latest changes applied; ditto
> when using the authinfo variant of the new :client-certificate param.

Great!

>>> Beyond that, users may appreciate a mention of the new additions in the
>>> info manual and maybe the wiki as well (instead of just NEWS).
>>
>> Certainly; done in v2.
>
> Nice job. This sort of thing can be a real time sink (at least for me).

Thanks, and agreed; but it's good to take the time and do it anyway. :-)

> One question. And stop me if I've confused myself here, but the doc
> string and the tex-info section for `erc-tls' both offer the same
> example (borrowed from their plain `erc' counterparts) in which the
> function `erc-compute-full-name' is said to be consulted despite the
> :full-name "Harry S. Truman" keyword arg being present. While it's
> (technically) true that `erc-compute-full-name' always runs, I suspect
> its inclusion in the original example was inadvertent (or something
> about it has changed since 2007). Would it perhaps make sense to omit
> `erc-compute-full-name' from the Truman example?

Yeah that's fair!  I've tried to clarify/remedy that in the latest
revision.

[...]
>
> Thanks, but I shouldn't have proposed that tweak without a concrete use
> case in mind. In fact, I've only ever needed :nowait to be nil when
> using a custom opener. If my suggestion made things more confusing or
> distracting, my apologies. Perhaps it's best to just revert to what you
> had originally or even just force it to t. (Not that you should waste
> another second on this relative nothingburger.)

No worries :-).  And per our short discussion on #erc the other day,
there could be a legitimate use-case for that.  So I think it's safe to
say that all in all it was a net positive change.

>> Thanks for the suggestion.  After some thought, I decided to change the
>> interface of erc-tls from the two separate :client-key and :client-crt
>> arguments in v1 of the patch to just one :client-certificate in v2,
>> matching that of `open-network-stream'.  I tested the change with
>> `:client-certificate t' and confirm that it works fine for me.
>
> The interface change is a welcome improvement, IMO. Although dealing
> with a list may feel slightly more cumbersome to some, the multiple
> helpful examples make that a nonissue. (And sparing contributors an
> extra param to worry about is a nice bonus as well.) But I guess the
> real win is in accommodating the authinfo facility, which seems a rather
> obvious and essential inclusion in retrospect. Great work!
>

Awesome.  Yeah I couldn't think of a more straightforward and/or less
cumbersome way of doing it, except for using the same shape of argument
as expected by `open-network-stream'.  Per usual, I would be open to
reconsideration if a better way of doing it is suggested.

For now, I went ahead and finally installed the attached patch on the
master branch.  Thanks for all the feedback/suggestions. :-)

[0001-Add-support-for-using-a-TLS-client-certificate-with-.patch (text/x-diff, attachment)]

Message #25 received at 47788-done <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 47788-done <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Fri, 23 Apr 2021 05:31:46 -0700

Hey, guess we both missed this:

  @@ -505,18 +512,23 @@ erc-server-process-alive
            (memq (process-status erc-server-process) '(run open)))))
   
   ;;;; Connecting to a server
  -(defun erc-open-network-stream (name buffer host service)
  -  "As `open-network-stream', but does non-blocking IO"
  -  (make-network-process :name name :buffer  buffer
  -                        :host host :service service :nowait t))
  +(defun erc-open-network-stream (name buffer host service &rest parameters)
  +  "Like `open-network-stream', but does non-blocking IO."
  +  (let ((p (plist-put parameters :nowait t)))
  +    (open-network-stream name buffer host service p)))
     ;; ^~~~~~~~ Need an apply #' here because ~~~~~~^
   
  -(defun erc-server-connect (server port buffer)
  +(defun erc-server-connect (server port buffer &optional client-certificate)

Turns out my silly tests for one of those unofficial #erc bugs (the
azur12 one) caught it by failing (which means your patch magically fixed
the issue!).

Anyway, no rush; I doubt this really impacts anyone.

Message #28 received at 47788-done <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 47788-done <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: Add support for TLS client certificates to 'erc-tls'
Date: Fri, 23 Apr 2021 18:52:27 -0400

J.P. writes:

> Hey, guess we both missed this:
>
>   @@ -505,18 +512,23 @@ erc-server-process-alive
>             (memq (process-status erc-server-process) '(run open)))))
>    
>    ;;;; Connecting to a server
>   -(defun erc-open-network-stream (name buffer host service)
>   -  "As `open-network-stream', but does non-blocking IO"
>   -  (make-network-process :name name :buffer  buffer
>   -                        :host host :service service :nowait t))
>   +(defun erc-open-network-stream (name buffer host service &rest parameters)
>   +  "Like `open-network-stream', but does non-blocking IO."
>   +  (let ((p (plist-put parameters :nowait t)))
>   +    (open-network-stream name buffer host service p)))
>      ;; ^~~~~~~~ Need an apply #' here because ~~~~~~^
>    
>   -(defun erc-server-connect (server port buffer)
>   +(defun erc-server-connect (server port buffer &optional client-certificate)
>
> Turns out my silly tests for one of those unofficial #erc bugs (the
> azur12 one) caught it by failing (which means your patch magically fixed
> the issue!).
>
> Anyway, no rush; I doubt this really impacts anyone.
>

Oh whoops!  Good catch, and thanks for the quick notice. :-)
I committed a fix to the master branch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.