On May 29, 2012, at 1:38 PM, michael(a)stroeder.com wrote:
Still you did not answer why SHA-1 is in and SHA-2 is out.
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
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.