Is this true? I thought you could use GSSAPI over LDAPS?

without rehashing my previous comments about this feature and it's threat/security implications, perhaps if this is to be a bootstrap only credential, than after next successful incremental repl with the primary creds, can we remove the bootstrap password? That way the bootstrap password is only needed to be added in the case of recovery scenarioes?

without rehashing my previous comments about this feature and it's threat/security implications, perhaps if this is to be a bootstrap only credential, than after next successful incremental repl with the primary creds, can we remove the bootstrap password? That way the bootstrap password is only needed to be added in the case of recovery scenarioes?

No not really, because one of the scenarios that brought this up happened during OS upgrade. So we always need valid credentials. Waiting for replication to break before resetting the bootstrap password kind of defeats the purpose of this. It's not just for initialization, it can happen in other scenarios. The upgrade scenario is one (incremental update), and also if replica that was disabled and then re-enabled later(incremental or total). I know you don't like this patch, you made that very obvious with all your previous comments, but people are not forced to use this feature. This is optional, and the "risks" will be documented.

Hmmm okay. If that's scenario was accounted for than thats fine. :)

@tbordaz i've already checked this and it was okay to me, can you check too just to be completely sure it's good to go?

Could also be slapi_ber_bvdone that looks more the symmetric of slapi_ber_bvcpy

It can also be done in a function agmt_set_bootstrap_credential_no_lock

could be replaced by slapi_ber_bvcpy (as well in agmt_get_credentials)

bootstrapBindmethod is be int64_t

ra->bootstrapCreds->bv_len = 0 is not strictly necessary (slapi_ber_bvdone did it) but IMHO it helps when reading the code.

Why not BINDMETHOD_SASL_GSSAPI ? @firstyear raised a concern of have bootstrap bind method weaker than main one ?

Does not it leak ?
Not related to your fix. Reading the code, creds is a allocated berval that is bvcpy from the agmt credential (agmt_get_credentials). ber_bvfree frees bv_val but does it free the berval itself ?

Nice !!

Why not BINDMETHOD_SASL_GSSAPI ? @firstyear raised a concern of have bootstrap bind method weaker than main one ?

Well, you can't really have two outbound identities with GSSAPI, and if your GSSAPI is broken (more than likely) you'll need to use dn + pw to resolve it which I think is the intent of this ticket. Which as mentioned, does mean that the security becomes the baseline of dn + pw and the benefit of GSSAPI at all in this becomes questionable :)

So as it stands, provided people are willing to accept that having GSSAPI + fallback dn + pw is equivalent to "dn + pw only" in security, than it's no problem to allow the current code.

Okay I am fine dropping GSSAPI as fallback method.
Note that the intention was to not put any limit on how fallback works. For example an admin may prefer dn+pw as primary method, because it is faster, and fallback to a more expensive/slow GSSAPI.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/4305

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.