That reason seems pretty shallow coming from the OBSD team... How can changing the language make it more secure by itself? Is a rewrite in C the next planned enhancement?
At the risk of dumping yet more karma, let me rephrase more constructively. OpenBSD has focused on security from the beginning. Precisely for that reason, and considering all the audits they run, it feels like, if OpenBSD has used (up to 4.9) shell scripts for security(8), there mustn't be any compelling reason against using the shell. Surely they must not have them.
I realize this was a changelog and not an article, and probably due reasons were found and discussed by the team. I still feel, nonetheless, that "For additional security, security(8) was rewritten in Perl" is either too short (provide a brief reason such tedunangst's) or too long (omit half-baked reasons and simply provide the fact that "security(8) was rewritten in Perl").
Work in progress to replace /etc/security, not yet linked to the build.
Main design goals:
1. Safely handle untrusted file names and file content.
2. Output compatibility with current security(8) to please people
parsing the output with scripts (except when improving functionality
right away saves considerable implementation effort). Substantial
functional enhancements are for later.
Prodding to do this in Perl by deraadt@.
Using some feedback from espie@.
Is security(8) setuid? perl does a number of things to make setuid Perl scripts more secure than either setuid schell scripts or C programs (cf. taint mode).