Bug 816174
| Summary: | creating a new TLS context always succeeds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jakub Hrozek <jhrozek> | ||||
| Component: | openldap | Assignee: | Jan Synacek <jsynacek> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | collura, jsynacek, jvcelak, rcritten, rmeggins | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-13 15:26:25 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jakub Hrozek
2012-04-25 12:30:31 UTC
Created attachment 580148 [details]
a test program
Unfortunatelly requesting a new TLS context does not mean initializing it. OpenLDAP with Mozilla NSS uses deferred initialization. The context is initialized with the first connection. Is the situation different with OpenSSL? Is there no way to initialize the context on demand? Yes, OpenSSL does not use deferred initialization. The initialization would take place immediately after LDAP_OPT_X_TLS_NEWCTX option is set. I'm not aware of any possible way of forcing the initialization. And I even don't know why exactly deferred initialization is used. It would work without it. I think it remained after the old implementation of the backend. Currently it just complicates the things. As far as I know, Fedora and Red Hat are the only who use MozNSS backend. We can probably consider removing the deferred initialization from MozNSS and upstream could accept that. The behavior would be more consistent with OpenSSL backend. And some other stuff which is possible with OpenSSL and impossible with MozNSS would work (like entering the password for the certificate when starting slapd server). Rich, I'm I right about the deferred initialization? Or is there any other reason why it is there now? Maybe I miss something. I guess it depends on what you mean by initialize. Do you want it to actually make the SSL connection or simply verify that the arguments you provide exist in the filesystem? NSS abstracts the SSL connection a lot more than OpenSSL. With NSS you just need to call PR_Read() and it takes care of the handshaking for you. With OpenSSL you have to manage a lot of this yourself. There are ways to force a handshake to occur (like SSL_ForceHandshake) that may do what you want but you may still be required to do a read. > I guess it depends on what you mean by initialize.
I think that Jakub needs this to recognize TLS configuration errors from connection errors. I understand initialization in OpenLDAP as loading the modules (PEM), creating NSS context, opening certdb.
(In reply to comment #5) > I guess it depends on what you mean by initialize. Do you want it to actually > make the SSL connection or simply verify that the arguments you provide exist > in the filesystem? > Verifying that the arguments exist on the filesystem would be a good start, actually establishing the SSL connection might not be possible or practical anyway with all SSSD configurations (we might need to do a SRV resolution etc etc). (In reply to comment #7) > Verifying that the arguments exist on the filesystem would be a good start, This can be achieved by removing deferred initialization. (In reply to comment #8) > (In reply to comment #7) > > Verifying that the arguments exist on the filesystem would be a good start, > > This can be achieved by removing deferred initialization. I'm not sure if deferred init is needed anymore - should try without it. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |