After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 700522 - User is asked for password, which isn't needed and is then ignored.
User is asked for password, which isn't needed and is then ignored.
Status: RESOLVED DUPLICATE of bug 703181
Product: evolution-ews
Classification: Other
Component: Miscellaneous / EWS Core
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: Matthew Barnes
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-05-17 13:03 UTC by David Woodhouse
Modified: 2013-07-15 09:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Woodhouse 2013-05-17 13:03:56 UTC
NTLM authentication just started failing for me on Fedora 19 with Evolution-EWS, although I have no idea what's changed; it was working earlier today and I don't think I've updated any relevant packages.

I see an HTTP request with an NTLM type1 request, which elicits a 401 Unauthorised response, with the type2 challenge as expected. And then instead of responding with the type3 response to complete authentication, I get the following:

(evolution:16633): libsoup-CRITICAL **: soup_message_headers_append: assertion `strpbrk (value, "\r\n") == NULL' failed

... followed by resending the request *without* any 'Authorization: NTLM' header.


(gdb) bt
  • #0 g_logv
    at gmessages.c line 981
  • #1 g_log
    at gmessages.c line 1010
  • #2 g_return_if_fail_warning
  • #3 soup_message_headers_append
    at soup-message-headers.c line 189
  • #4 soup_message_headers_replace
    at soup-message-headers.c line 227
  • #5 soup_message_set_auth
    at soup-message.c line 1211
  • #6 soup_auth_manager_request_started
    at soup-auth-manager.c line 688
  • #5 soup_message_set_auth
    msg=msg@entry=0x7fffb400d050 [ESoapMessage], 
    auth=auth@entry=0x1564de0 [SoupAuthNTLM]) at soup-message.c:1211
1211			soup_message_headers_replace (msg->request_headers,
(gdb) p token
$8 = 0x7fff940b3500 "NTLM est:\n 0000 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx\nnthash:\n 0000 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx\nnt_resp:\n 0000 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx\nKK TlRMTVNTUAADAAAAGAAYAFIAAAAYABgAagAAAAMAAwBAAAAACAAIAEMAAAAHAAcASw", 'A' <repeats 14 times>, "ggEIAEdFUmR3b29kaG91VU5LTk9XTg", 'A' <repeats 31 times>, "EjB+NT75uOCql+nkBRjht/BPePwtALHCQ=="
Comment 1 Dan Winship 2013-05-17 13:08:15 UTC
might be useful to see if valgrind notices anyone misbehaving?
Comment 2 David Woodhouse 2013-05-17 13:13:12 UTC
Aha, this is my fault. I had rebuilt my local ntlm_auth "helper", which is supposed to be part of Samba/winbind but in my case is just http://david.woodhou.se/ntlm_auth_v2.c — and I had left some stray debugging output in it.

I forgot I'd done that. Partly because I was still being *asked* for my bloody password even though it was being handled automatically. WTF?
Comment 3 David Woodhouse 2013-05-17 13:15:34 UTC
Changing title; let's forget my own stupidity and make it about that bug :)

Not sure if this is a libsoup issue; perhaps more likely to be evolution-ews?
Comment 4 David Woodhouse 2013-05-17 13:17:34 UTC
(perhaps libsoup could be more robust if the ntlm_auth helper misbehaves too, and silently fall back to behaving as if it weren't there?)
Comment 5 Dan Winship 2013-05-17 13:21:54 UTC
ntlm-test is supposed to verify that "authenticated" never gets emitted if you're using ntlm_auth. It might be missing some case though.
Comment 6 David Woodhouse 2013-05-17 13:42:45 UTC
More likely that the Evolution-EWS side is *assuming* that a password is required and asking for it in advance, even though it doesn't need it.

I *thought* we'd fixed the various ESource APIs not to do that, and to only request passwords when they were actually needed. Maybe not though.

One for mbarnes, methinks...
Comment 7 David Woodhouse 2013-07-15 09:04:43 UTC

*** This bug has been marked as a duplicate of bug 703181 ***