Change Details

`Cancel` UI should have well-defined semantics. Let us consider a scenario of decryption (with multiple methods). Current situation: - gpg supports cancelling one method. Canceled -> it tries another method. - gpgme considers that single `GPG_ERR_CANCELED` means cancelling the whole process of decryption. - pinentry-tty and pinentry-curses support `GPG_ERR_FULLY_CANCELED` by `Ctrl-C`. But other pinentry implementations have no support (only `GPG_ERR_CANCELED`). We could have clear definition like: - `GPG_ERR_CANCELED` means cancelling one method - `GPG_ERR_FULLY_CANCELED` means cancelling all (cancelling the whole process of decryption) - meaning of empty input depends on the context (for symmetric encryption, meaning "skip", for example) If this definition is OK, then we will do: - Enhance other pinentry implementations to raise `GPG_ERR_FULLY_CANCELED` (for example, offering another button or new semantics of closing the dialog forcibly). - Modify gpgme state-machine - not raise an error by a single `GPG_ERR_CANCELED`, just record it. - raise an error by `GPG_ERR_FULLY_CANCELED` - at the `EOF`, recorded `GPG_ERR_CANCELED` raise an error - observing new pinentry invocation, clears the cancel record - Modify gpg - `GPG_ERR_FULLY_CANCELED` cancel all methods

`Cancel` UI should have well-defined semantics. Let us consider a scenario of decryption (with multiple methods). Current situation: - gpg supports cancelling one method. Canceled -> it tries another method. - gpgme considers that single `GPG_ERR_CANCELED` means cancelling the whole process of decryption. - pinentry-tty and pinentry-curses support `GPG_ERR_FULLY_CANCELED` by `Ctrl-C`. But other pinentry implementations have no support (only `GPG_ERR_CANCELED`). We could have clear definition like: - `GPG_ERR_CANCELED` means cancelling one method - `GPG_ERR_FULLY_CANCELED` means cancelling all (cancelling the whole process of decryption) - meaning of empty input depends on the context (for symmetric encryption, meaning "skip", for example) If this definition is OK, then we will do: - Enhance other pinentry implementations to raise `GPG_ERR_FULLY_CANCELED` (for example, offering another button or new semantics of closing the dialog forcibly). - Modify gpgme state-machine - not raise an error by a single `GPG_ERR_CANCELED`, just record it. - raise an error by `GPG_ERR_FULLY_CANCELED` - at the `EOF`, recorded `GPG_ERR_CANCELED` raise an error - observing new pinentry invocation, clears the cancel record - Modify gpg - When pinentry returns `GPG_ERR_FULLY_CANCELED`, cancel all methods

`Cancel` UI should have well-defined semantics. Let us consider a scenario of decryption (with multiple methods). Current situation: - gpg supports cancelling one method. Canceled -> it tries another method. - gpgme considers that single `GPG_ERR_CANCELED` means cancelling the whole process of decryption. - pinentry-tty and pinentry-curses support `GPG_ERR_FULLY_CANCELED` by `Ctrl-C`. But other pinentry implementations have no support (only `GPG_ERR_CANCELED`). We could have clear definition like: - `GPG_ERR_CANCELED` means cancelling one method - `GPG_ERR_FULLY_CANCELED` means cancelling all (cancelling the whole process of decryption) - meaning of empty input depends on the context (for symmetric encryption, meaning "skip", for example) If this definition is OK, then we will do: - Enhance other pinentry implementations to raise `GPG_ERR_FULLY_CANCELED` (for example, offering another button or new semantics of closing the dialog forcibly). - Modify gpgme state-machine - not raise an error by a single `GPG_ERR_CANCELED`, just record it. - raise an error by `GPG_ERR_FULLY_CANCELED` - at the `EOF`, recorded `GPG_ERR_CANCELED` raise an error - observing new pinentry invocation, clears the cancel record - Modify gpg -- When pinentry returns `GPG_ERR_FULLY_CANCELED`, cancel all methods