Обсуждение: Consistent error reporting for encryption/decryption in pgcrypto

Commit b918bf86c65 added the errorcode PXE_DECRYPT_FAILED to the existing set
of PXE_ error codes.  When pgcrypto was changed to the EVP APIs in 5ff4a67f63,
no new error codes were added in favour of existing ones.  This results in
encryption failures returning PXE_ERR_GENERIC, which seems a bit inconsistent.

The attached introduce PXE_ENCRYPT_FAILED and use that for EVP_EncryptUpdate to
ideally be slightly clearer in case of errors.  Any reason not to do that
instead of using ERR_GENERIC?

cheers ./daniel

On Thu, Oct 29, 2020 at 10:26:54PM +0100, Daniel Gustafsson wrote:
> The attached introduce PXE_ENCRYPT_FAILED and use that for EVP_EncryptUpdate to
> ideally be slightly clearer in case of errors.  Any reason not to do that
> instead of using ERR_GENERIC?

+1.  While looking at that, I was wondering of the potential need of
this error code for other encryption code paths, but it happens that
this is only specific to OpenSSL.  Rijndael or Blowfish don't need
it.
--
Michael

Hi,

thank you for your contribution.

I did notice that the cfbot [1] is not failing for this patch.

Cheers,
//Georgios

[1] http://cfbot.cputube.org/daniel-gustafsson.html

> On 30 Oct 2020, at 16:54, Georgios Kokolatos <gkokolatos@protonmail.com> wrote:

> I did notice that the cfbot [1] is not failing for this patch.

I assume you mean s/failing/passing/?  I noticed the red Travis and Appveyor
runs, will fix over the weekend.  Thanks for the heads-up.

cheers ./daniel

> On 31 Oct 2020, at 02:03, Michael Paquier <michael@paquier.xyz> wrote:

> It seems to me that you are just missing to declare a new error number
> in px.h, so I would suggest to just use -19.

Ah yes, I accidentally fat-fingered the git add -p when splitting up the NSS
patch into bite size pieces. Sorry about that. The attached v2 has the error
declaration.

cheers ./daniel