Hide Forgot
My inbox is specified in my ~/.pinerc as: inbox-path={$IMAPS-SERVER/ssl/novalidate-cert/user=$ME}inbox (without the variables of course). When I open pine, it displays the following sequence of messages: [No credentials cache found (try running kinit) for $IMAPS-SERVER] [Can not authenticate to IMAP server: Invalid base64 string] [No folder opened] The same configuration works when I compile pine myself (turning on SSL). Yes, I can just do that, but SSL in pine *is* an advertised feature...
I'll look into this and get back.. You're the first to report that pine/ssl does not work. What imap server is it connecting to, is it a Linux server or something else, and does it support ssl, kerberos, etc? Give me as much information about your setup as you can, both pine, and the imap server if possible. I'll also need your config file ~/.pinerc Replace any private info in the file with XXXXXX or something so as not to publicize your private data. Attach that to the bug report using the link below.
Created attachment 18270 [details] Edited (for privacy) ~/.pinerc
The IMAP server is Solaris (possibly 2.6, but I'm not sure). It supports kerberos for those using the public clusters. I am not in the kerberos domain. It also supports IMAP over SSL, which I use with self-compiled versions of pine (both 4.30 and 4.33). The pine version I tried was that installed with RedHat 7.1. From sniffing the wire while pine starts up, all packets are travelling to/from the correct port (993) on the IMAPS server. The 'invalid base64 string' error is the same one I got when they switched the server to IMAPS and I didn't have SSL compiled into pine. Pleasel let me know if I can provide any more info.
what happens if you set try-alternative-authentication-driver-first, do you still get the same error?
Yes -- I get the exact same sequence of errors.
Here's another suggestion: try adding disable-these-authenticators=GSSAPI to your .pinerc
That got it. So I guess it's a problem in pine "falling back" to SSL when kerberos doesn't work? Or is merely PEBKAC? :) Thanks.
I'm glad that thelast suggestion solved the problem. Here's a more technical explanation of what happened. Pine and the server when they start a session match a list of authenticators that both of them know (in your case, kerberos and ssl). In your case, both the server and Pine had been compiled with this support, the problem that you had was that you could not obtain the Kerberos credentials from your machine. What the command "disable-these-aunthenticators=GSSAPI" does, is to disable Kerberos authentication *in PINE*, as opposed to disabling this on the server, so while the server still advertises kerberos authentication to Pine, Pine in turn does not advertise kerberos authentication to the server, so you are left with ssl authentication (called actually "PLAIN"), which is the authentication that is used to login you to the server. I hope this helps. Have a nice day!
Closing bug - problem determined as not a bug.