rfjakob/gocryptfs

Providing the password via stdin

petres opened this issue · 7 comments

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!

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
.

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.

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
.

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
.

Here we go. Works for you?

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

It's working like a charm! Thanks!