Providing the password via stdin

[petres]

Could it be implemented that the password is provided via stdin to the gocryptfs command. Right now I am getting:

Could not read password from terminal: inappropriate ioctl for device

Additional question: Are there some security concerns in providing the password in that way. It doesn't have to be stdin, some other file descriptor would be also fine.
Thanks!

[rfjakob]

Out of interest, where will the password come from? A graphical prompt?
(Also, are you aware of the "-extpass"?)
On Jun 9, 2016 16:53, "Peter Reschenhofer" notifications@github.com wrote:

Could it be implemented that the password is provided via stdin to the
gocryptfs command. Right now I am getting:

Could not read password from terminal: inappropriate ioctl for device
Additional question: Are there some security concerns in providing the
password in that way. It don't has to be stdin, some other file descriptor
would be also fine.
Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30, or mute the thread
https://github.com/notifications/unsubscribe/AARgf6lYPrf0s6ofoENmJDXYQTX97DxRks5qKCjJgaJpZM4IyD4Z
.

[petres]

I already tried the option -extpass with zenity and it works well.

Basically I want that a program - which knows already the password (and yes, through a graphical prompt) - to be able to call gocryptfs and providing directly the password. Sure, I could write the password in a file or an environmental variable and use -extpass to grab it from there, but wouldn't a mechanism which doesn't have to exec another program to get the password a better way?

Actually I thought that would be trivial change.

[rfjakob]

Makes sense. I'll take a look.
On Jun 9, 2016 18:22, "Peter Reschenhofer" notifications@github.com wrote:

I already tried the option -extpass with zenity and it works well.

Basically I want that a program - which knows already the password (and
yes, through a graphical prompt) - to be able to call gocryptfs and
providing directly the password. Sure, I could write the password in a file
or an environmental variable and use -extpass to grab it from there, but
wouldn't a mechanism which doesn't have to exec another program to get the
password a better way?

Actually I thought that would be trivial change.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARgf9i6YiBS4h6PaHp-x4sOSpMvpuVMks5qKD3OgaJpZM4IyD4Z
.

[rfjakob]

Should be no problem. I will implement this early next week.
On Jun 9, 2016 6:24 PM, "Jakob Unterwurzacher" jakobunt@gmail.com wrote:

Makes sense. I'll take a look.
On Jun 9, 2016 18:22, "Peter Reschenhofer" notifications@github.com
wrote:

I already tried the option -extpass with zenity and it works well.

Basically I want that a program - which knows already the password (and
yes, through a graphical prompt) - to be able to call gocryptfs and
providing directly the password. Sure, I could write the password in a file
or an environmental variable and use -extpass to grab it from there, but
wouldn't a mechanism which doesn't have to exec another program to get the
password a better way?

Actually I thought that would be trivial change.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARgf9i6YiBS4h6PaHp-x4sOSpMvpuVMks5qKD3OgaJpZM4IyD4Z
.

[rfjakob]

Here we go. Works for you?

[rfjakob]

And no, passing the password through stdin is good and secure.

[petres]

It's working like a charm! Thanks!