Bug#368297: About the libgcrypt and OpenLDAP issue

[Werner Koch]

On Sat, 20 Apr 2013 20:18, clopez at igalia.com said:

> Are you planning to merge it upstream?

Sure.  Unfortunately I released 1.5.2 just a few days ago.  Thus it
won't happen in the next few weeks.

> I believe it will be useful for everyone that asked for this feature on
> the past and ended workarounding the problem by disabling secmem.

[Why don't they ask on gcrypt-devel@ or add a feature request into the
tracker].

> I was meaning that this patch adds a flag (GCRYCTL_DISABLE_PRIV_DROP)
> that the application should enable.

Right.

> Therefore, after patching libgcrypt with the patch you provided to add
> support for this flag, is still needed to patch either libldap or gnutls
> to enable the flag.

Wrong.  This would be a surpising policy change.

>  1. libgcrypt (to add support for the flag).

Yes.  There are anyway to required bug fixes for ECC pending.

> This is probably a bigger diff change than the previous ones proposed,
> and maybe the release team is not happy with that at this point of the
> freeze.

I explained it several times: You can't do that in a library.  I even
won't do that without an _API_ break in Libgcrypt.  If we break the API
it would be possible to do just because everyone is then required to
read the release notes.

> IMHO is just impossible to add this at the application level. This
> applications don't have a dependency on libgcrypt. They don't use any

If they don't have a dependency we could close the bug immediately.

> library or symbol related to libgcrypt. So (i guess) asking their
> developers to introduce a dependency on libgcrypt just to enable such

It is already there ...

> This applications just happen to have a dependency on libpam.

... due to this dependency.

> And when PAM is configured to use LDAP as backend, the libpam-ldap
> module for PAM will chain to libldap (openldap). Then, libldap will need

Do you want to say that dlopen does not introduce a dependency?
Actually it introduces a very fragile dependency.  I don't know how this
could be handled without a strict plugin interface which does only allow
the use modules with any external dependencies.

> And the first "libgcrypt aware" library on this chain is libldap
> (openldap). The previous ones on the chain have no idea about libgcrypt.

Well, then you could add a wrapper to libldap to set the new Libgcrypt
flag.  But you need to dlopen libldap (respective the plugin using
libldap) right after main.  Any other call sequence might indirectly
load Libgcrypt via different code paths (plugins) before libldap has a
chance to set the flag.

The bottom line is that the architecture of PAM is severely broken due to
its in-process plugin interface.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.