Cancel operation does not return error code
kloecker at kde.org
Fri Mar 11 22:21:57 CET 2022
On Freitag, 11. März 2022 17:05:44 CET Schultschik, Sven via Gnupg-users
> > -----Ursprüngliche Nachricht-----
> > Von: Gnupg-users <gnupg-users-bounces at gnupg.org> Im Auftrag von Ingo
> > Klöcker Gesendet: Freitag, 11. März 2022 11:18
> > An: gnupg-users at gnupg.org
> > Betreff: Re: Cancel operation does not return error code
> > [It would be great, if you wouldn't top-post even if this isn't easy with
> > Outlook or Office 365 or whatever email client you are using.]>
> > > 3. Ctrl+C does not cancel the gpgme passphrase entry. See screenshot 2
> > Pressing Ctrl+C while t-encrypt-sym is running and pinentry-curses is
> > asking for the password quits pinentry-curses and t-encrypt-sym without
> > further output. That's common behavior for command line programs.
> The problem is not that it quits without any further ouput. The problem is,
> that the command line is broken after a ctrl+c and the pinentry-curse is
> somehow still alife. You can't type or it is not visible. If you hit enter
> you get back to the pinentry saying that you don't inserted any passwort.
Hmm, I didn't observe this problem with t-encrypt-sym. Maybe using pinentry-
tty is an option. It's not as fancy as the curses one, but hopefully it
doesn't mess up the terminal on Ctrl+C.
> Is there a proper way or example how to cancel all operations on a ctrl-c
There is gpgme_cancel and gpgme_cancel_async:
But I don't know how to use them to cancel all operations on Ctrl+C.
> > My conclusion is that gpgme_op_encrypt() is working as expected as my
> > experiments with the official test t-encrypt-sym proves. I suspect that
> > there is something wrong with your program. Please have a look at the
> > official test t-encrypt-sym (in tests/gpg > of gpgme's source code) and
> > check what you are doing differently.
> > I'm using gpgme 1.17.1.
> I tested now in a docker container with Arch:latest and gpgme 1.17 and the
> Canceloperation err returned as expected. It really seems to be a bug in
> the 1.14.
Yes. Could have been fixed by the following commit:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users