bug#61411: [PATCH] Handle a case where url-basic-auth can crash

bug#61411: [PATCH] Handle a case where url-basic-auth can crash

[me--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Hi all,

This seems like a simple patch, in cases where 
'url-request-noninteractive' is set and valid credentials either aren't 
found or the server sends 401 regardless (which is how I found this 
bug), this causes Emacs to crash.

I have copyright assignment assigned, even though this would fall under 
a "trivial change".

Thanks,
Ellis

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-potential-crash-with-url-basic-auth.patch --]
[-- Type: text/x-diff; name=0001-Fix-potential-crash-with-url-basic-auth.patch, Size: 943 bytes --]

From c35eddf8bc938ccfa0d9a55fc6f142595bc2de15 Mon Sep 17 00:00:00 2001
From: Ellis Kenyo <me@elken.dev>
Date: Sat, 11 Feb 2023 07:27:56 +0000
Subject: [PATCH] Fix potential crash with url-basic-auth

* lisp/url/url-auth.el (url-basic-auth):
Handle a case where Emacs would crash where no valid credentials are found
and 'url-request-noninteractive' is t
---
 lisp/url/url-auth.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/url/url-auth.el b/lisp/url/url-auth.el
index e9ee72029f..83b4fa6468 100644
--- a/lisp/url/url-auth.el
+++ b/lisp/url/url-auth.el
@@ -100,7 +100,7 @@ instead of the filename inheritance method."
 			     (setq retval
 				   (base64-encode-string
 				    (format "%s:%s" user
-					    (encode-coding-string pass 'utf-8))
+					    (encode-coding-string (or pass "") 'utf-8))
                                     t))))
 		 (symbol-value url-basic-auth-storage))))
      (byserv
-- 
2.39.0

bug#61411: [PATCH] Handle a case where url-basic-auth can crash

[me--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Not sure of the etiquette here, but it's been a little bit now so I'm 
just bumping this :)

bug#61411: [PATCH] Handle a case where url-basic-auth can crash

[Eli Zaretskii]

> Date: Sat, 25 Feb 2023 21:36:37 +0000
> From: me--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Not sure of the etiquette here, but it's been a little bit now so I'm 
> just bumping this :)

That bug report has no description of the situation where the problem
happens and no reproduction recipe.  Talking about "crash" is also
inaccurate, I think: it just signals an error, right?

So it isn't surprising that bug report got no attention.

Could you please add the missing details?

Thanks.

bug#61411: [PATCH] Handle a case where url-basic-auth can crash

[me--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Eli,

Thanks for responding; I incorrectly assumed because the patch was so 
trivial my description was enough. My bad!

Below is a snippet of elisp that when `M-x eval-buffer`'d crashes an 
`emacs -Q` and causes an `emacs -Q -l repro.el` to freeze indefinitely 
on e444115d026c809395d4d248a99bb467bc87bb1d

(require 'url)
(eval-when-compile (require 'cl-lib))

(cl-defun send-request (endpoint &key verb data headers noninteractive 
json noauth sync callback)
   (let* ((url-request-method (or verb "GET"))
          (url-cookie-trusted-urls '(".*"))
          (url-request-noninteractive noninteractive)
          (url-request-extra-headers
           `(("Referer" . ,endpoint)
	    ("X-CSRF-TOKEN" . nil)
             ("Cookie" . nil)))
          (url-request-data data))
     (if sync
         (with-current-buffer (url-retrieve-synchronously endpoint)
           (funcall (or callback #'identity) url-http-response-status))
       (url-retrieve
        endpoint
        (or callback #'identity)))))

(send-request "https://httpstat.us/401" :noninteractive t :sync t)

The linked API is a simple service used to return various status codes, 
in this instance always a 401 regardless of what authentication is 
passed.

I'm not sure if my patch is the best catch-all solution to the 
underlying issue (I confess, I don't fully understand why this crashes). 
With my simple patch applied though, Emacs continues as expected.

I hope this is enough information now, I apologize for the poor initial 
report. As I already had a patch ready, I didn't think I should have 
used `M-x report-emacs-bug` but I will in future :)

bug#61411: [PATCH] Handle a case where url-basic-auth can crash

[Eli Zaretskii]

> Date: Sun, 26 Feb 2023 08:52:31 +0000
> From: me@elken.dev
> Cc: 61411@debbugs.gnu.org
> 
> Thanks for responding; I incorrectly assumed because the patch was so 
> trivial my description was enough. My bad!
> 
> Below is a snippet of elisp that when `M-x eval-buffer`'d crashes an 
> `emacs -Q` and causes an `emacs -Q -l repro.el` to freeze indefinitely 
> on e444115d026c809395d4d248a99bb467bc87bb1d
> 
> (require 'url)
> (eval-when-compile (require 'cl-lib))
> 
> (cl-defun send-request (endpoint &key verb data headers noninteractive 
> json noauth sync callback)
>    (let* ((url-request-method (or verb "GET"))
>           (url-cookie-trusted-urls '(".*"))
>           (url-request-noninteractive noninteractive)
>           (url-request-extra-headers
>            `(("Referer" . ,endpoint)
> 	    ("X-CSRF-TOKEN" . nil)
>              ("Cookie" . nil)))
>           (url-request-data data))
>      (if sync
>          (with-current-buffer (url-retrieve-synchronously endpoint)
>            (funcall (or callback #'identity) url-http-response-status))
>        (url-retrieve
>         endpoint
>         (or callback #'identity)))))
> 
> (send-request "https://httpstat.us/401" :noninteractive t :sync t)
> 
> The linked API is a simple service used to return various status codes, 
> in this instance always a 401 regardless of what authentication is 
> passed.
> 
> I'm not sure if my patch is the best catch-all solution to the 
> underlying issue (I confess, I don't fully understand why this crashes). 
> With my simple patch applied though, Emacs continues as expected.
> 
> I hope this is enough information now, I apologize for the poor initial 
> report. As I already had a patch ready, I didn't think I should have 
> used `M-x report-emacs-bug` but I will in future :)

Thanks, I fixed this in a slightly different manner on the emacs-29
branch, and I'm therefore closing this bug.