On a linux box, read /proc/200/mem. Or just allocate a bunch of memory and force it to swap out, then read the swapfile. Season liberally with local root exploits if needed (these come in bucketfuls on most unices). This is a classic attack: while it's not terribly practical, it's a whole lot easier than trying to brute force the password stream.
I'm not saying local-attacker password security can't be locked down securely. Simply that doing so is a much more complicated proposition than "use a library". In practice, most web applications are not secured against hostile local users. I'm not sure I've ever seen one that was. So to my mind, ruling out some of the most powerful tools you have (perl's IPC facilities) in a vain attempt to achieve a security level that the rest of your architecture doesn't support seemed silly.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
I'm not sure where all these security discussions are going. My point was simply that taking the passwords out of the command line of gpg was woefully insufficient to secure them (note, again, that they're going to be stored in a database whose password is stored locally in a file), so using "security" as a reason to avoid perl's elaborate and very robust IPC facilities was a poorly grounded argument. Nitpicking about whether one (!) of my examples matches the original author's security assumptions is very much missing the point.
To get back to perl: note that you can feed the password to GPG via stdin if you want with just one extra byte to the open string, and a call to autoflush() and print().
Is your security analysis assuming that the attacker is running under a different uid than the web server?
Well, that's just what my example question above said.
Why on earth would you do that?
To avoid them reading the memory? It's pretty common for shared hosting to have each user running on their own local port and a reverse proxy listening on 80, just so that each user gets the benefit of the basic UNIX security model (we assume trust in the admin, of course). I guess I don't understand the whole password in a file thing, either. If those have proper permissions then the only person who have to trust other than yourself is root. Seems better than nothing to me.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
In a secure shared hosting environment applications do not run as the web server UID. They run as the owner of the virtual host. Apache does this with mod_suexec.
Are you doing it differently? Why on earth would you do that?
The unix security model isn't amazing, but it does a reasonable job of protecting you from users other than root -- putting cleartext passwords in command line arguments is one way of throwing that away.
Then again, as you seem to be saying, manipulating cleartext passwords are usually a bad idea in the first place
I'm not saying local-attacker password security can't be locked down securely. Simply that doing so is a much more complicated proposition than "use a library". In practice, most web applications are not secured against hostile local users. I'm not sure I've ever seen one that was. So to my mind, ruling out some of the most powerful tools you have (perl's IPC facilities) in a vain attempt to achieve a security level that the rest of your architecture doesn't support seemed silly.