I have to wonder - if the API was so bad, but he didn't have to do anything that isn't available from openssl "the tool"... why did he write the code at all? Excerpt from openssl x509 help:
His requirement was writing an application that provided certificate authority services. You could write a crapload of messy wrapper functions that call external programs, or link in a library and avoid adding glue to your app.
The annoying answer is that it's "cleaner", the realistic answer is you don't have to account for as many potential problems you might encounter while executing applications on any given system. The sysadmin in me would use the tool but the programmer in me would use the API. (Oh, and depending on how heavily this application would get used, the API might be significantly faster and reduce load on the server...)
If you're generating new CAs in such volume that the (in)efficiency of a UNIX pipe becomes a problem, you should just stop right there. That should be a red flag.
It's not the pipes, it's fork() and exec() and re-main()-initialization. Try doing that a few ten thousand times and see how long it takes compare to doing everything in-process where you only initialize once.
While I'm not a fan of premature optimization, I don't see nothing wrong here even if I like the Unix philosophy of "Write programs that do one thing and do it well". Why run an external program when the same thing should be possible by calling functions from a (well written) library?
