On May 29, 2012, at 1:38 PM, michael(a)stroeder.com wrote: Well, the general rule is simply all new hash schemes should go in contrib first. What you ask is for an exception to this general rule for SHA-2. I don't see the arguments for the exception being all that strong. Arguing it should be "in" because SHA-1 is "in" is a really poor argument. SHA-1 is "in" because it was grandfathered in. SHA-2, like any new hash scheme, is "out" because of the current practice to put new schemes in contrib. It's as simple as that, I think. I do note that there's many issues bring hashes into core. One key one is that core schemes ought to work with minimal 3rd party libraries, and that means without OpenSSL. So bringing these schemes also means, if we hold to this, bring in a SHA2 implementation into core... and that's gets, well, more involved. And that's one of reasons we have the core/contrib split. Anyways, I personally think no exception should be granted, these schemes should go into contrib like any other new hash scheme would. I've thought a bit about whether slappasswd should or should not load modules. I stand against slapppasswd reading slapd configuration by default. I would not object to reading slapd configuration when specifically requested by the user (by a command line argument). I generally run slappasswd (for setup purposes) as a user which has no access to slapd configuration. This not only for convenience, but for security reasons (limit programs which can read the configuration, as the configuration contains sensitive information). While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. -- Kurt