On Sat, Jul 25, 2026 at 05:44:14PM +1000, Seth McDonald wrote:
GNU SASL does not choose mechanisms the same way Cyrus SASL does.
[...]
ok, fair enough. apparently the api is less helpful than it seems
at first sight.
but i wonder whether it actually makes sense to filter mechanisms
client-side beyond what the config says. is there a plausible situation
where the server would offer a mechanism that the client cannot actually
use because of local constraints?
And to reiterate, as a user, I don't want a program bothering me about
something it can fix itself. If SASL fails, it should attempt to fix
itself by falling back to LOGIN before making it the user's problem.
huh? are you suggesting that isync should ignore what the user
explicitly configured (noting that LOGIN is in the defaults if the
connection is encrypted)?
if not, what _exactly_ is the situation you want changed?
that will only ever trigger for a non-compliant IMAP4 server (since
PLAIN is required),
well, no. the example in
https://datatracker.ietf.org/doc/html/rfc3501#section-6.1.1 shows this
to be false. however, it also shows that absence of AUTH=PLAIN goes with
presence of LOGINDISABLED.
in principle one could just do away with LOGIN, but PLAIN is a poor
substitute in a non-sasl build due to the complexity.
and error while retrieving an error string would be an internal error
in libsasl or the calling code.
The fallback is intended mainly for the latter case. Such an error in
the library is (from the perspective of the calling program) always a
possibility, so the fallback accounts for this.
in either case i want that to be glaringly obvious, not papered over.
Without the fallback, if such an internal error occurs leading to a NULL
return value, the program will just segfault when it attempts to read
from the NULL pointer.
Is that what's preferred?
yes.
it's not useful to handle errors that cannot happen if the library is
reasonably implemented. we don't need to treat it as a black box that
could do anything. if it actually does, then someone has some debugging
to do.
I was referring to my use of temporary variables across the patchset
and in general.
i wasn't. i don't like _these_ temporaries.
But also, are you implying the "print stringified error code" pattern
cannot contain bugs? Because if not, then how is this irrelevant?
"cannot" is a tad strong, but it's unlikely enough to happen and easy
enough to discover, that one can ignore the possibility.
> (1) They make git diff/blame cleaner by separating operations with
> newlines, which allows diff/blame to better identify and show
> the exact operations that were changed.
>
that's equally achievable by wrapping the "resolver" call to the next line.
You say later on that such wrapping of arguments deviates from the style
of the codebase and shouldn't be used without sound justification.
[...]
so stick to the wrapping style that is actually used all over the place?
you don't seem to have switched your git diff algorithm
to histogram yet?
No, I use minimal by default.
any particular reason? saving bytes/lines isn't a very useful objective
when reviewing diffs.
> > > +typedef const char *(*imap_auth_cred_t)( void * );
> > > +
> > the consequences of having these are obviously ugly.
> > just factor out imap_auth_conf_t as i hinted at previously.
>
> Sure, but just FYI without it the logic will no longer be
> self-contained. It'll depend on the implementation of the IMAP driver,
>
why would it?
It'll directly refer to and hence depend on imap_server_conf_t
no, it wouldn't, just like imap_auth_client_t doesn't.
and ensure_(user|password)().
yes, which should be in imap_auth.c.
that should also clarify how that relates to the other series.
> > > +char *
> > > +find_string_list( const string_list_t *list, const char *str )
> > > +
> > > +char *
> > > +find_string_list_case( const string_list_t *list, const char *str )
> >
don't try to make analogous interfaces when there is a cost, but no
obvious
advantage for existing use cases.
What's the cost?
the ugly return casts, if nothing else.
On the other hand, an advantage is a familiar interface.
finding an entire string in a string list isn't logically the same as
finding a substring in one string. it's entirely counter-productive to
pretend that the apis are the same. it's more like QList::contains().
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
