Can't forge a key

[RuntimeX]

After forging a key, I am not prompted for a password in a seperate window. The message "tomb [w] you set empty password, which is not possible" prints until it quits.

root /mnt/01CF7A9CC65C5360/pentest # tomb forge -k pentest.tomb.key tomb . Commanded to forge key pentest.tomb.key tomb . Commanded to forge key pentest.tomb.key with cipher algorithm AES256 tomb . This operation takes time, keep using this computer on other tasks, tomb . once done you will be asked to choose a password for your tomb. tomb . To make it faster you can move the mouse around. tomb . If you are on a server, you can use an Entropy Generation Daemon. 256 blocks (0Mb) written. 256+0 records in 256+0 records out

THE PROBLEM

tomb (*) Choose the password of your key: pentest.tomb.key tomb . (You can also change it later using 'tomb passwd'.) tomb [W] You set empty password, which is not possible. tomb [W] You set empty password, which is not possible....

[melon3r]

Do you have pinentry instaled?

[RuntimeX]

yes. 0.8.3-1

[jaromil]

try using sudo?

it seems a tty ownership issue...

[RuntimeX]

I'm su. I installed tomb from AUR. Worked when I had Manjaro, Now I'm using Atergos; and the prompt window doesn't appear.

[melon3r]

Okay... it happens to me too with the last HEAD. It has to do with redirection to -. It went mad and wouldn't stop:

@jaromil That's why I made #133. Because right now we have some /dev/null redirection, some closed stdouts and some redirections to -, being the later what I was trying to fix.

[RuntimeX]

Oh, it'll go for about 5 minutes without me stopping. The source code doesn't help me. I know nothing of coding GUI. I think the problem could be addressed here. Why does it not fallback to ask through console stdin?

I'll wait. and hope the commits mentioned in #133 will come soon and will work.

[melon3r]

@RuntimeX In the picture you posted pinentry's stderr is redirected to /dev/null, but in the current code it's redirected to - (yeah, to a file called -). That's a bug I introduced. There are a lot of other things redirecting to -, and one of them probably runs with sudo, so creates a - with permissions only for root, which make pinentry fail when trying to write to it as a normal user. ;-)

I know the problem and the solution, but I need @jaromil to merge the patch.

[RuntimeX]

But I'm using tomb as root. I would think that would overide most, if or all, permission issues. I learned of tomb on the Linux Action Show, and one of the caveats they mentioned was having to be logged in as root to work with app. I haven't even tried using sudo as my regular user. I will do that and post if my results are any different. Can we arrange to dig and forge in one command (or even dig, forge and lock), so that we can use an option to create a password with dig, and forge automatically run and create x.tomb.key? I'm sure there is a good reason that they are seperate actions, but maybe making a workaround like that, if possible, is better than being unable to use tomb at all. I wish I started learning to code years ago so I could help more. Thank you all very much for your attention in this matter. FYI - I tried the irc first, but nobody replied.

[melon3r]

@RuntimeX I connected to IRC (#dyne at irc.dyne.org) a few minutes ago, so we can talk there :wink:

Also, you don't have to log as root or use sudo to run tomb. It'll run sudo for you when it needs it, so it'll ask you for the password then.

[RuntimeX]

can I change the pinentry config to be mode accomodating?... oh I see that^^^. I'll open hexchat.

[RuntimeX]

update: using sudo works, using root doesn't. also, not using sudo works. (for forging at least) This can be closed. Thank you all.

[jaromil]

@gdrooid merding that will create conflicts now

lets revert all to /dev/null Ill do it on HEAD

[melon3r]

@jaromil I can rebase it if you want.

[jaromil]

its done. all tests passed.