On Sat, Oct 31, 2020 at 09:40:12PM +0100, Daniel Gustafsson wrote:
> 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.
Thanks for updatng the patch. Applied.
--
Michael
signa
> On 31 Oct 2020, at 02:03, Michael Paquier 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. T
On Fri, Oct 30, 2020 at 11:23:27PM +0100, Daniel Gustafsson wrote:
> > On 30 Oct 2020, at 16:54, Georgios Kokolatos
> > 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 o
> On 30 Oct 2020, at 16:54, Georgios Kokolatos
> 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
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 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 wond
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 in
