tevent_abort_nesting crash in idmap_ad

[Jeremy Allison]

On Sat, Jun 25, 2016 at 05:42:04PM +0200, Volker Lendecke wrote:
> 
> So that makes gensec unusable in an async API, sorry. With SMB there's
> not much we can do, because we have too much code depend on it. But
> with TLDAP we still have the chance to do the right thing and admit
> what I have tried to achieve is impossible.

gssapi is the same (unusable in async code). Just use it as sync
here and move on. It's not a big deal - all other uses do the same.
In fact your original code was doing a sync bind - it was just doing
it under the covers via a tevent_immediate callback so it didn't
look like it. So it isn't really any change. The way tldap works
with these patches is the same way it worked yesterday without.

It was good on Thurday, why is it suddenly, irrerevably broken
on Friday ?

> We don't know how well it works. It was never used in production, we
> have no idea about its performance etc. Also, may I remind you of your
> attitude towards ASN.1? This is a shitload of homegrown ASN.1 code that
> others have done already for us.

You forget - I reviewed tldap. It's *better*. We already
have our working ASN.1 code ('cos both you and I and Metze
have gone over and fixed the issues with it).

As another point - our ASN.1 code was attacked at the
plugfest this week by a full Codenomicon test. No flaws
found. At this point I trust our implementation more
than the others.

> The old code has its flaws, but it is
> known to work in production for ages. We should go back and revert the
> big chainsaw commit and do the thing you are arguing for: Slowly fix
> the bugs in more understandable pieces in the old code.

The tldap code was reviewed, and many people - not just you - consider
it a significant improvement over the openldap client code. It
has many advantages - for the generic ldap read and write it
fits really will into the async tevent model - allows much more
efficient async use of the processor (keep processing other
requests whilst we're waiting for ldap return).

To throw it all away simply because the initial bind request
has to be synchronous (as is the same for all other ldap
libraries) is madness.

Let's not do that. We have at least 2 solutions (Ralph's
and mine) that fix the issue and retain the fully async
nature of tldap. I would be happy with either. I wouldn't
be happy to lose tldap.

As I said, let's talk about this in person on the phone.
I think that might help clear up any misunderstandings
we have that email can make worse.

Cheers,

	Jeremy.