I'm using Puppet in part to ensure [Federal Information Processing Standard 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) (FIPS 140-2) compliance on my network. Part of this compliance for the system underlying Puppet is to make sure that only [FIPS Approved](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) algorithms are used. OpenSSL does this by ensuring that any attempts to run an unapproved algorithm result in either a SIGSEGV or a SIGABRT. MD5 has been broken enough that it is no longer a FIPS Approved algorithm.
The consequence for Puppet is that, if it tries to use MD5 on a FIPS-compliant system, it will crash. Here is where I have seen Puppet crash for this reason:
1. the puppet/util/checksums.rb, used by File resources;
2. the puppet/parser/functions/md5.rb, implementation of the md5 DSL function;
3. certificate signature in puppet/ssl/certificate_request.rb;
4. certificate fingerprinting in puppet/ssl/base.rb;
5. outside Puppet, in the session ID code in openssl/ssl-internal.rb, class OpenSSL::SSLServer, due to using WEBrick.
It was easy enough to replace MD5 with SHA256 in all those places - and, in case 4, it appears I may not have needed to change the code; but the DSL function is still called md5, and MD5 is still named in some of the messages. My changes lack the refinement necessary to be useful to others.
What I think I need is to be able to say, in one place like puppet.conf, "use SHA256, not MD5," and algorithms and messages alike will change. I think the `md5` DSL function would need to be replaced with a `digest` function which uses the configured algorithm, and there should also be a way in the DSL to find out which digest is being used, like a `digestname` function.
Then, in some years when SHA2 is decertified, I can tell Puppet, "use SHA3, not SHA2," instead of filing an issue like this one and doing code changes. (I don't know what migration issues this scenario may pose.)
[How can I make Red Hat Enterprise Linux 5 FIPS 140-2 compliant?](https://access.redhat.com/kb/docs/DOC-39230) (Red Hat login required)