Passcode option (command-line)

Question

Passcode option (command-line)

Opened this issue 9 years ago · 6 comments

It could be useful at times to allow the user to provide the passcode at the time of calling crypto. It is partially related to issue #8, but not really a solution to it. Right now I basically am imagining the same option that gpg provides on the command-line with --passphrase.

Of course the passphrase will be visible on the commandline (and in the commandline history), if you are using this option, but the same is true if you use it with gpg directly. There are many scenarios though, where I would like to be able to call crypto, but not have to wait for it to ask for a passphrase or I might want to call it multiple times from another script and not have to manually type in the passphrase.

I already have a rough implementation for this, if you like to have a look.

Answer 1 · 2015-05-24T15:58:01.000Z

To solve the visibility on the command line, I regularly use for gpg --passphrase-file with a temporary file containing the passphrase.

Answer 2 · 2015-05-24T16:14:10.000Z

Christoph submitted a PR addressing this issue. we are planning to pipe the passphrase through stdin using --passphrase-fd 0 . Discussing it over on Slack if you're interested in getting involved. be happy to send an invite.

Answer 3 · 2015-05-26T07:20:43.000Z

Writing an actual file to disk with the plaintext pswd inside is probably more useful for long keys (such as your private ssh key). When it comes to crypto, maybe we should also have a --passphrase-fd option (since I only implemented the fix for gpg)?

Answer 4 · 2015-05-27T16:58:56.000Z

think that this is widely used?

Answer 5 · 2015-05-28T11:41:47.000Z

Not really :) I was thinking the whole --passphrase option may not be a good idea in the end and we could probably still PIPE the passphrase to crypto, if we wanted to script it. (One thing we might want to consider is disabling the passphrase authentication, which could be annoying at times)

Answer 6 · 2015-05-28T12:52:54.000Z

Definitely agree about the passphrase option given this issue. I like the authentication on the encryption end, agree that it is unnecessary on the decryption side. Will create a new issue and remove it.

—
Chris

On Thu, May 28, 2015 at 7:41 AM, chrisidefix notifications@github.com
wrote:

Not really :) I was thinking the whole --passphrase option may not be a good idea in the end and we could probably still PIPE the passphrase to crypto, if we wanted to script it. (One thing we might want to consider is disabling the passphrase authentication, which could be annoying at times)

Reply to this email directly or view it on GitHub:
#10 (comment)

Not really :) I was thinking the whole --passphrase option may not be a good idea in the end and we could probably still PIPE the passphrase to crypto, if we wanted to script it. (One thing we might want to consider is disabling the passphrase authentication, which could be annoying at times)

Not really :) I was thinking the whole `--passphrase` option may not be a good idea in the end and we could probably still PIPE the passphrase to crypto, if we wanted to script it. (One thing we might want to consider is disabling the passphrase authentication, which could be annoying at times)