I would say that it's probably better to use this stdin method for mysql, if
possible. Even if there's nothing in the log, the command name usually shows
up in the process list, so it's usually a bad idea if there's an
alternative.
I just create a per-user ~/.my.cnf -- most MySQL libraries can read that
file, and if they can't, it's easy to parse (I have a script that generates
database.yml partly from .my.cnf).
On Tue, Apr 1, 2008 at 12:34 PM, Jamis Buck <[EMAIL PROTECTED]> wrote:
> On Apr 1, 2008, at 10:38 AM, Andrew McClain wrote:
> >
> > Sean,
> >
> > I'm already prompting the user for a password using password_prompt.
> >
> > The issue isn't showing the password when the user _enters_ it, the
> > issue is that the password shows up in the capistrano log when the
> > command is executed.
> >
> > i.e.
> >>> pass = Capistrano::CLI.password_prompt('secret password:')
> >>> run "mysql -p #{pass}"
> >
> > secret password:
> > {USER ENTERS FOO}
> >
> > * executing "mysql -p FOO" <--- there it is in plaintext!
> >
> > I'm wondering how capistrano manages to get around this for sudo
> > passwords, which look like:
> > * executing "sudo -p 'sudo password: ' some_command" <--- obfuscated
>
> Cap doesn't send the password on the command-line for sudo (there's no
> obfuscation going on--the password just isn't set that way). Instead,
> cap watches for sudo to prompt for the password (e.g., 'sudo password:
> ' on the output), and then sends the password via the SSH channel's
> stdin (e.g., channel.send_data(password + "\n")), to mimic the
> password being entered on the remote command-line.
>
> That said, I can totally understand your concern, and I would
> definitely be amenable to patch that obscures passwords in the logged
> output.
>
> - Jamis
>
>
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
