gpg2 strange behaviour

H

hruodr

I want the following simple script gpgpass in order that gpg2 save my password key in the cache:

Code: 
#!/bin/sh
gpg2 --sign --armor <<!
Nonsense
!

Well, the script does not work, I get:

Code: 
gpg: signing failed: Invalid IPC response
-----BEGIN PGP MESSAGE-----

gpg: signing failed: Invalid IPC response

But if I run manually gpg2 --sign --armor, all is OK.

I suspect, this does not occur in Linux (I cannot test it), because I get the same error with

gpg --use-agent --sign < /dev/null > /dev/null

And this is recommended here for saving the pass in the cache:

https://www.gnu.org/software/emacs/manual/html_node/message/Passphrase-caching.html
 
What is that <<! supposed to do?

My guess is that whatever instructions you're following are focused on using Bash. But /bin/sh is not the same as Bash and as such several bash specific tricks will therefor not work.

See, within the context of /bin/sh I am somewhat familiar with << and <<- but I've never seen an exclamation mark being used in there. As such my assumption regarding Bash.
 
hruodr said:
Just see "Here Documents" in "An Introduction to the Unix Shell" of S. R. Bourne.
Click to expand...
Please don't insult my intelligence if you actually want me to help you.

If you checked those documents for yourself you'd notice that redirection is a thing. And sure: sometimes also used for stdin, I never said otherwise. However, what you won't find in here, and for good reasons, is the construction you've been showing us above.

I also get the impression that you seem to think that there can only be 1 "Unix shell". Trust me: that's not the case. For example, there's a difference between the Bourne shell on FreeBSD (oops, see SirDice's comment below ;) ) (/bin/sh) and, for example, the one used on Sun Solaris (see shells/heirloom-sh).

So reading a random PDF file about a random Bourne shell provides no guarantees what so ever that whatever you're reading will also be usable on FreeBSD. For that you'd refer to the sh(1) manualpage. Guess what? What you're showing us above isn't listed in there.

I'm sure you can figure out why.
 
It was not a PDF about a random Bourne shell, it was a PDF about the Bourne shell, wrote by Bourne self. It should not surprise that the most elementary and old features of the original shell went to the posix standard that is followed by FreeBSD. And in page 7 you do find my construction above, as also in FreeBSDs man sh:

Code: 
The following redirection is often called a “here-document”.

           [n]<< delimiter
           here-doc-text
           ...
           delimiter

     All the text on successive lines up to the delimiter is saved away and
     made available to the command on standard input, or file descriptor n if
     it is specified.

And by the way: it works, just try it. But this does not answer my original question.
 
hruodr said:
Just see "Here Documents" in "An Introduction to the Unix Shell" of S. R. Bourne.
Click to expand...
What makes you think ! is a valid delimiter label for HERE?
hruodr said:
It should not surprise that the most elementary and old features of the original shell went to the posix standard that is followed by FreeBSD.
Click to expand...
FreeBSD's /bin/sh is actually the Almquist Shell, not the Bourne Shell.
 
SirDice said:
FreeBSD's /bin/sh is actually the Almquist Shell, not the Bourne Shell.
Click to expand...
Thanks for that, however this creates a bit of a problem. The handbook claims that /bin/sh is actually the Bourne shell (as seen here), which is also what I based myself on. To be honest I'm more inclined to follow the handbook than Wikipedia, but I'm well aware that mishaps sometimes definitely happen.

However, more research on my end so far definitely seems to back your comment. I'll check what more I can dig up.
 
hruodr said:
(3) It works with FreeBSD sh shell, just test it with ! (but not gpg2) and you will see.
Click to expand...
Please define "work"? Giving no errors for example doesn't really proof anything. Also: this comment totally contradicts the stuff you mentioned in the OP where you clearly stated that this doesn't work (and in my opinion for very good reasons).
 
ShelLuser said:
The handbook claims that /bin/sh is actually the Bourne shell (as seen here), which is also what I based myself on.
Click to expand...
I guess that's just sloppy texting in the handbook, but doesn't really hurt. AFAIK, there are only "Bourne shells" (as in: based on, or compatible to) out there, except for these strange C shells ;) These are the two major classes of Unix shells. ash is not the Bourne shell, but you could say it is a Bourne shell.
 
Zirias said:
Which is, like many other shells, Bourne compatible
Click to expand...

Then it should hold, what Bourne wrote:

In this example the shell takes the lines between << ! and ! as the standard input for grep.
The string ! is arbitrary, the document being terminated by a line that consists of the string
following <<.
Click to expand...

But try it, for example with ed -s.
 
ShelLuser said:
Also: this comment totally contradicts the stuff you mentioned in the OP where you clearly stated that this doesn't work
Click to expand...

I did not write that the redirection was not working.

The last lines of my original posting show with very high probability that the redirection was not the reason why it my script failed.
 
The "problem" with ! is that it's a reserved keyword. This may not have been the case when Bourne wrote the document.
 
This wasn't my point. But checking it, FreeBSD's /bin/sh indeed seems to accept a single !. So? If you just tried something more conventional, instead of insulting people, this would have been sorted out much more quickly without spamming your thread.
 
Well, I'm pretty convinced that the redirect is one of the causes for your problems, that and your obvious inexperience with shell scripting.

But ignoring all that for now let's get back to the actual issue at hand: what exactly do want that script to do, that's still totally unclear to me? For example echo "mypassword" | gpgpass?

Because you mention caching your password but how do you expect that to happen? gpg wouldn't do that, so do I assume right that you simply want to use the password within the script itself? If so, then why not simply use parameters?

Also noteworthy, in my opinion, are the --use-agent and --no-use-agent options for gpg, see also gpg(1). Why not use the agent for what it was made for?
 
The intention is to force gpg2 to start the agent, to read the password and cache it.

Just as in the quoted web page of gnu with
gpg --use-agent --sign < /dev/null > /dev/null.

Why not use the agent? For avoiding more complicated initialisation that is done automatically by gpg2.

That new versions of gpg2 ignore --use-agent and always start the agent does not deserve to be mentioned.

Perhaps the problem is, that not only gpg2 reads stdin with the file to be signed (in the here document as intended), but that it calls in some way pinentry that reads the pass from stdin.

And pinentry-gtk-2 port seems to be broken.
 
There are several problems with that reasoning. For example, as far as I know GPG doesn't accept sending of passwords through stdin, one of the reasons the agent exists. So trying to get that to work through a shell script seems futile to me. Ah, I stand (somewhat) corrected on that: --passphrase-fd.

Bottom line though: what you're trying above (I'm still not fully clear what that script is supposed to do) won't work. Trying to redirect both stdin and stdout to /dev/null is also pretty much bogus. Also: a fair warning seems to be in order here because all this messing around with passwords will definitely affect overall security.

Perhaps.... gpgpass mypassword?

Code: 
#!/bin/sh

gpg --sign --armor --passphrase $1
So if you wanted to encrypt a file like this you could use: echo filename | gpgpass mypassword > filename.gpg and you're done.

I also noticed that GPG2 always uses the agent so it doesn't need any specific arguments for that. How it then responds to the password and uses it depends on the rest of your configuration. This is what I'd do.
 
I want exactly the same as

https://www.gnu.org/software/emacs/manual/html_node/message/Passphrase-caching.html

with gpg --use-agent --sign < /dev/null > /dev/null

but with a more compact command. You do not need to read what I write, it is enough if you see the above web site I mentioned in the very first posting.

Normally, only experts give passwords in the command line. I avoid it. But yes, the password in the cache is also not secure.

If the problem were, that gpg2 and pinentry read from stdin, then the above solution should also not work (and in FreeBSD does not work, but perhaps in Linux?).

Typing gpg2 --sign --armor is also not a tragedy and has the wanted effect.
 
I'm pretty sure pinentry in the console flavour doesn't just use stdin, this would be very insecure. It will at least try to get hold of the controlling tty. Of course, a redirected stdin might cause problems anyways. Why don't you try some X11 based flavour of pinentry?
 
There's also security/pinentry-curses and pinentry-tty which seem somewhat more appropriate here. Or just set configure the main port appropriately. Even so I still fail to follow the point and I'm convinced you're merely over complicating things; the whole thing makes little sense to me.

gpg-agent is used by default when using gpg2, so there's nothing you need to do there. As such you also don't need to script anything: just add the command gpg2 --sign to a script and gpg2 will do the rest. No need for unsupported redirects, no need for manual redirects (as I said earlier: redirecting both stdin and stdout to /dev/null is bogus because it serves no purpose) and the password need will be handled by gpg2.

Which is another issue: you keep referring to --use-agent but that option is obsolete in gpg2 (as in: not being used anymore).

Even so... From that very same website (simple copy & paste):

Code: 
#!/bin/sh

eval `gpg-agent --daemon`
gpg2 --sign $1
That'll work, problem solved.

First run you'll be asked for your password, second run it'll rely on gpg-agent for that. I would definitely not recommend to actually use this but alas; this is what you wanted to achieve.
 
ShelLuser said:
this is what you wanted to achieve.
Click to expand...

No, it is not.

Zirias, with pinentry-gtk-2 my script works. I though pinentry-gtk-2 is broken. The reason not to use it, is, that I do use the console from time to time, but in that case it seems to use curses. Also I prefer simpler programs.

In any case, I have always the solution gpg2 --sign --armor.

Of course, this does not give an answer to the strange behaviour.
 
Last post because I strongly get the feeling to be wasting my time here.

My solution above works, plain and simple. If you insist on using gpg (so, GnuPG-1 (note that use of GPG2 is recommended on FreeBSD)) then all you'd have to do is point GPG to the gpg-agent, you can do that with the --gpg-agent-info option or the GPG_AGENT_INFO environment variable, see also gpg(1). Look in ~/.gnupg for the file(s) you'd need to use. Probably something like ~/.gnupg/S.gpg-agent:0:1.

You said you wanted to cache the password, this solution caches the password. On both GPG versions.
 
You must log in or register to reply here.
Back
Top