Upgraded gpg from 1.4.18 to 2.1.18: --default-recipient-self no longer works

[gnupg at raf.org]

Werner Koch wrote:

> On Wed, 13 Dec 2017 02:17, gnupg at raf.org said:
> 
> > The gpg command is something like:
> >
> >   cmd... | gpg --default-recipient-self --encrypt --output filename.gpg
> 
> For all unattended use you need to add --batch (in all versions of gpg
> since he very beginning).

Hi Werner, thanks for the response.

It always worked for me in the past without --batch and now,
it works without --batch if I use --recipient or --default-recipient
instead of --default-recipient-self.

> >   gpg: cannot open '/dev/tty': No such device or address
> 
> Batch will also handle this.
> 
> > So I ran it manually and it turned out that --default-recipient-self
> > no longer works:
> 
> There have been a couple of internal changes in the last years which may
> have affected this option.

I just tried using --default-recipient-self --batch and it worked.
That surprised me. I wouldn't expect --batch to change the ability
of --default-recipient-self to find the key (See below for probable
explanation).

> > I can specify the ID explicitly (i.e. name at domain.com) and
> > then it works but I shouldn't have to, should I?
> 
> It is always better to make it explict.  To debug your failure, please
> run the encryption command agian but add 
> 
>   --verbose  --debug lookup
> 
> to the invocation

I just tried that and it found the key. Then I tried just
--default-recipient-self without the debugging and it worked!

I think I know what happened. I now have a ~/.gnupg/.gpg-v21-migrated
file and ~/.gnupg/private-keys-v1.d/ directory that I wouldn't have had
when the --default-recipient-self first started failing via cron.
But after I poked around a bit (e.g. gpg --list-secret-keys), the keyring
migration took place and it's all working again. Does that make sense?

It's a pity the keyring migration didn't take place during the cronjob.
Then the upgrade would have been seamless. It's all good now though.

Of course, you're right about it being better to be explicit but
I wonder if --recipient would have also failed via cron
immediately after the upgrade with the old keyring.

> > (1) The documentation for --default-key says:
> >
> >   Use name as the default key to sign with.
> >
> > But the documentation for --default-recipient-self
> > implies that it is also for encryption, not just signing.
> 
> Both commands are basically the same; they just differ in how the
> default key is determined.  So, right the man page is wrong.
> 
> 
> > (2) The documentation for --no-tty says:
> >
> >   Make sure that the TTY (terminal) is never used for any output...
> >
> > But it also makes sure that the TTY is not used for input as well.
> 
> Right.  But in practise you don't need it.  --batch is sufficient.
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Thanks again and again.

cheers,
raf