Hello, Happy new year to everybody!
I have setup “Cyrus IMAP” to offer both IMAP and HTTP access over GSSAPI/SPNEGO. This works: echo abc|kinit a...@aegee.org curl -XPROPFIND --negotiate -u: https://mail.aegee.org/dav/calendars/ If I go to this cyrus-sasl commit 975edbb69070eba6b035f0 (Add Channel Binding support for GSSAPI/GSS-SPNEGO) imtest -m GSSAPI -t "" mail.aegee.org works consistently, while curl -v --ssl -u: imap://mail.aegee.org consistently fails. At commit 26835b156ec9b69f22 (Revert "Call gss_acquire_cred() before gss_init_sec_context() in") both curl -v --ssl -u: imap://mail.aegee.org and imtest -m GSSAPI -t "" mail.aegee.org work. During my tests, curl, imtest and the IMAP server are on the same system, so they use the same libsasl2 plugins. After each checkout, I reinstall libgs2.so.3.0.0 and libgssapiv2.so.3.0.0, kdestroy, kinit and kill the imapd process and restart the saslauthd process. In each iteration I recompile and reinstall only the files in plugns/ ( so no client/* and no server/*). At commit 2383802 calling curl -v --ssl -u: imap://mail.aegee.org does work consistently, but «imtest -m GSSAPI -t "" mail.aegee.org» always fails. Obviously, the truth is somewhere there, but where exactly? More importantly, does the Channel Binding support for GSSAPI/GSS-SPNEGO expose errors in plethora of software? In particular, does applying it on servers, break clients? On my PC, where I have not touched libsasl2 and its plugins, reverting the channel bindings made my MUAs (Evolution and Thunderbird, I guess they both use NSS) again functional. I use curl 7.74 and imtest/cyrus imapd 3.2.4. Is somebody willing to test other clients? Greetings Дилян ------------------------------------------ Cyrus: Devel Permalink: https://cyrus.topicbox.com/groups/devel/T891d82e88f5ceb6b-M18ee5b098435e0791ef4eaf8 Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
