Avoiding further (LDAP) stack proliferation in Samba

[Andrew Bartlett]

On Wed, 2020-06-24 at 12:22 +0200, Stefan Metzmacher wrote:
> 
> Can you agree on that plan?
> 
> If so we can start working on this without running into a deadlock
> again.

Sounds like a plan.

I also agree that touching smbldap itself is quite risky, I had hoped a
way out of smbldap would be via deprecation and removal of the callers,
but it seems we will have these for a while yet.

Splitting ldap_message.c into client and server would be useful for
many good reasons (we decode client messages on the server right now,
before rejecting them). 

I just hope that we can agree to allow (dare I say encourage) AD client
code to use the LDB and LDB-adjacent utility functions for the above-
LDAP parsing (DN, Extended DN, GUID, SID, etc).  This stuff looks so
simple until you read ads_parent_dn() and cry...

Finally, I wanted to say a big thank you to you and everyone else for
taking the time to understand my concerns, I think we are in much more
agreement now.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions
https://catalyst.net.nz/services/samba