On Sat, 20 Apr 2013 20:18, clo...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org