Subject: bug#37221: 27.0.50; gnus fails to open connection post-NSM update

From: Robert Pluim <[email-masked]>
Date: Wed, 04 Sep 2019 17:04:37 +0200

>>>>> On Wed, 04 Sep 2019 16:59:35 +0200, Lars Ingebrigtsen <[email-masked]> said:

    Lars> Robert Pluim <[email-masked]> writes:
    >> Iʼve spotted one possible problem: nsm-query runs even when the
    >> connection is unencrypted, which ends up doing (insert nil), which
    >> aborts the connection. Does the following help? (Lars, why is nsm
    >> prompting for unencrypted connections?)

    Lars> It runs for all kinds of connections -- a non-encrypted one could, for
    Lars> instance, be one that's a result of a downgrade attack.

    Lars> So if it now assumes that the connection is always encrypted, that's a
    Lars> new bug.  Hm...  anybody know of a server that absolutely not doesn't
    Lars> have STARTTLS that I can test with?  :-)

Not quite. nsm-query-user assumes that status is non-nil, which is not
the case in my test, which was imap to localhost. It never gets the
chance to emit STARTTLS, since nsm has already killed the connection:

(defun nsm-query-user (message status)
  (let ((buffer (get-buffer-create "*Network Security Manager*"))
        (cert-buffer (get-buffer-create "*Certificate Details*"))
        (certs (plist-get status :certificates)))
    (save-window-excursion
      ;; First format the certificate and warnings.
      (with-current-buffer-window
       buffer nil nil
       (insert (nsm-format-certificate status)) <= status is nil here,
  which gives us "(wrong-type-argument char-or-string-p nil)", which
  causes nsm-query to kill the connection.

Robert