Marko Kreen writes:
> On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
>> I think we should fix and back-patch these two specific bugs. The
>> openssl.c change sounds like it might be something for HEAD only.
> Now I looked more in-depth and seems my comments were off - error
> detectio
On Fri, Jan 27, 2012 at 8:10 PM, Stefan Kaltenbrunner
wrote:
> On 01/27/2012 07:06 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
>>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
wrote:
>
On 01/27/2012 07:06 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
>>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>>> wrote:
On 01/27/2012 04:20 PM, Marko Kreen wrote:
> On Fri, Jan 27, 201
On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander wrote:
> On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>> wrote:
>>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
Yeah,
On Fri, Jan 27, 2012 at 18:54, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
> wrote:
>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>>> Yeah, it should be fixed. But note that "random data" is part of
>>>
On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
wrote:
> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Yeah, it should be fixed. But note that "random data" is part of
>> decrypt() spec - the validation it can do is a joke.
>>
>>
On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > pgcrypto.c is easily fixable and internal.c has proper checks.
> > But openssl.c does not. And I have a bigger openssl.c cleanup
> > pending. So I would prefer to add missing checks to cleaned-up
> > openssl.c an
On 01/27/2012 04:20 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Stefan Kaltenbrunner writes:
>>> from some looking at the code in pgcrypto.c it seems to me that the
>>> coding pattern in most functions there only checks for errors from the
>>> correspondin
Marko Kreen writes:
> pgcrypto.c is easily fixable and internal.c has proper checks.
> But openssl.c does not. And I have a bigger openssl.c cleanup
> pending. So I would prefer to add missing checks to cleaned-up
> openssl.c and post them together (soonish).
> But I'm bit unclear about fate of
On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > from some looking at the code in pgcrypto.c it seems to me that the
> > coding pattern in most functions there only checks for errors from the
> > corresponding initialization function, in the case of say
Stefan Kaltenbrunner writes:
> from some looking at the code in pgcrypto.c it seems to me that the
> coding pattern in most functions there only checks for errors from the
> corresponding initialization function, in the case of say decrypt_iv()
> that means only the IV and the key are actually "va
On 01/23/2012 08:40 PM, Stefan Kaltenbrunner wrote:
> We are using the raw decryption features of contrib/pgcrypto here to
> decode certain AES128 encrypted data. However depending on the data to
> decode and what statements have been executed in the same session before
> we are seeing different (a
We are using the raw decryption features of contrib/pgcrypto here to
decode certain AES128 encrypted data. However depending on the data to
decode and what statements have been executed in the same session before
we are seeing different (and sometimes completely wrong) answers
this is 9.1.2 on Deb
13 matches
Mail list logo
