# gpg2 strange behaviour



## hruodr (May 23, 2018)

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


```
#!/bin/sh
gpg2 --sign --armor <<!
Nonsense
!
```

Well, the script does not work, I get:


```
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


----------



## ShelLuser (May 23, 2018)

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 (May 23, 2018)

ShelLuser said:


> What is that <<! supposed to do?



You are really a ShelL*user! *

Just see "Here Documents" in "An Introduction to the Unix Shell" of S. R. Bourne.

Page 7 here: https://sites.fas.harvard.edu/~lib113/reference/unix/bourne_shell.pdf
Or here: https://9p.io/7thEdMan/vol2/shell.bun

And that this was not the problem, should be clear from the last lines of my original posting.


----------



## ShelLuser (May 23, 2018)

hruodr said:


> Just see "Here Documents" in "An Introduction to the Unix Shell" of S. R. Bourne.


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.


----------



## hruodr (May 23, 2018)

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`:


```
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.


----------



## SirDice (May 23, 2018)

hruodr said:


> Just see "Here Documents" in "An Introduction to the Unix Shell" of S. R. Bourne.


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.


FreeBSD's /bin/sh is actually the Almquist Shell, not the Bourne Shell.


----------



## hruodr (May 23, 2018)

SirDice said:


> What makes you think ! is a valid delimiter label for HERE?



(1) Bourne uses it in his introduction.

(2) From your source: "Initially a clone of the System V.4 variant of the Bourne shell."

(3) It works with FreeBSD `sh` shell, just test it with ! (but not gpg2) and you will see.


----------



## zirias@ (May 23, 2018)

SirDice said:


> FreeBSD's /bin/sh is actually the Almquist Shell, not the Bourne Shell.


Which is, like many other shells, Bourne compatible. But yes, using ! for a heredoc looks ... suspicious


----------



## ShelLuser (May 23, 2018)

SirDice said:


> FreeBSD's /bin/sh is actually the Almquist Shell, not the Bourne Shell.


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.


----------



## ShelLuser (May 23, 2018)

hruodr said:


> (3) It works with FreeBSD `sh` shell, just test it with ! (but not gpg2) and you will see.


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).


----------



## zirias@ (May 23, 2018)

ShelLuser said:


> The handbook claims that /bin/sh is actually the Bourne shell (as seen here), which is also what I based myself on.


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.


----------



## hruodr (May 23, 2018)

Zirias said:


> Which is, like many other shells, Bourne compatible



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 <<.



But try it, for example with `ed -s`.


----------



## hruodr (May 23, 2018)

ShelLuser said:


> Also: this comment totally contradicts the stuff you mentioned in the OP where you clearly stated that this doesn't work



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.


----------



## SirDice (May 23, 2018)

The "problem" with ! is that it's a reserved keyword. This may not have been the case when Bourne wrote the document.


----------



## zirias@ (May 23, 2018)

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.


----------



## hruodr (May 23, 2018)

Could you please, Zirias, quote where I insulted someone?


----------



## ShelLuser (May 23, 2018)

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?


----------



## hruodr (May 23, 2018)

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.


----------



## ShelLuser (May 23, 2018)

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`?


```
#!/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.


----------



## hruodr (May 23, 2018)

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.


----------



## zirias@ (May 23, 2018)

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`?


----------



## ShelLuser (May 23, 2018)

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):


```
#!/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.


----------



## hruodr (May 23, 2018)

ShelLuser said:


> this is what you wanted to achieve.



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.


----------



## ShelLuser (May 23, 2018)

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.


----------

