On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.

I haven't dug into the pgcrypto code yet -- is it doing anything
that might be platform-specific? Or is this more likely a problem
with OpenSSL?

regression.diffs attached.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Michael Fuhr <mike@fuhr.org> writes:
> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> regression tests fail the 3des test. I haven't checked against
> older versions of OpenSSL; I'll do so when I get a chance.

> I haven't dug into the pgcrypto code yet -- is it doing anything
> that might be platform-specific? Or is this more likely a problem
> with OpenSSL?

I don't see a problem with the pgcrypto regression tests in CVS HEAD,
either locally or on the buildfarm board. However probably none of
these machines are running a beta version of OpenSSL ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> regression tests fail the 3des test. I haven't checked against
> older versions of OpenSSL; I'll do so when I get a chance.
>
> I haven't dug into the pgcrypto code yet -- is it doing anything
> that might be platform-specific? Or is this more likely a problem
> with OpenSSL?

It is a bug in pgcrypto. I can only excuse it with my strong antipathy
towards 3des.

Could you test it with newer OpenSSL?

--
marko




---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
>
> It is a bug in pgcrypto. I can only excuse it with my strong antipathy
> towards 3des.
>
> Could you test it with newer OpenSSL?

Looks good. After applying the patch, all pgcrypto regression tests
pass on my box running Solaris 9/sparc, OpenSSL 0.9.8-beta6, and HEAD.

I expect you'll need to submit the patch to pgsql-patches so it'll
get put in the queue.

Thanks.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Michael Fuhr <mike@fuhr.org> writes:
> On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
>> It is a bug in pgcrypto. I can only excuse it with my strong antipathy
>> towards 3des.

> Looks good. After applying the patch, all pgcrypto regression tests
> pass on my box running Solaris 9/sparc, OpenSSL 0.9.8-beta6, and HEAD.

> I expect you'll need to submit the patch to pgsql-patches so it'll
> get put in the queue.

No need, we'll apply it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Marko Kreen <marko@l-t.ee> writes:
> On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
>> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
>> regression tests fail the 3des test. I haven't checked against
>> older versions of OpenSSL; I'll do so when I get a chance.

> It is a bug in pgcrypto. I can only excuse it with my strong antipathy
> towards 3des.

Patch applied.

Now that I look, the reason the buildfarm failed to find this is of
course that the pgcrypto Makefile is configured to never build or test
this code. Would it be reasonable to fix the makefile to follow the
toplevel --with-openssl choice?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Tom Lane wrote:

>
>Now that I look, the reason the buildfarm failed to find this is of
>course that the pgcrypto Makefile is configured to never build or test
>this code. Would it be reasonable to fix the makefile to follow the
>toplevel --with-openssl choice?
>
>
>

Yes, please! good catch!

andrew

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Tue, Jul 05, 2005 at 02:18:00PM -0400, Tom Lane wrote:
> Marko Kreen <marko@l-t.ee> writes:
> > On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
> >> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> >> regression tests fail the 3des test. I haven't checked against
> >> older versions of OpenSSL; I'll do so when I get a chance.
>
> > It is a bug in pgcrypto. I can only excuse it with my strong antipathy
> > towards 3des.
>
> Patch applied.
>
> Now that I look, the reason the buildfarm failed to find this is of
> course that the pgcrypto Makefile is configured to never build or test
> this code. Would it be reasonable to fix the makefile to follow the
> toplevel --with-openssl choice?

Heh. As it happens, I just researched the same thing. This
will be especially imortant with the new PGP code, which simply
does not work without OpenSSL.

I see 2 variants:

1) put @with_openssl@ and @with_zlib@ variables into
contrib/pgcrypto/Makefile.in and let configure process it.
2) put them in some other makefile fragment under src/
and let pgcrypto include it.

First I did the simple thing and put them into Makefile.global.in,
but this does not work, as it needs to be included _after_ all
module variables are set. So 2) needs a new file.


--
marko


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Marko Kreen <marko@l-t.ee> writes:
> I see 2 variants:

> 1) put @with_openssl@ and @with_zlib@ variables into
> contrib/pgcrypto/Makefile.in and let configure process it.
> 2) put them in some other makefile fragment under src/
> and let pgcrypto include it.

> First I did the simple thing and put them into Makefile.global.in,
> but this does not work, as it needs to be included _after_ all
> module variables are set. So 2) needs a new file.

Hm ... libpq manages to build code that requires openssl without
needing a generated Makefile, so why do we need it here?

I'd prefer #1 of these two, but seeing that no other contrib module
has a Makefile.in, not having to do either would be even better.
This is particularly true if you aren't going to completely eliminate
the hand-configuration options in the Makefile, because having to edit
a generated Makefile or having to edit Makefile.in and then remember
to reconfigure both suck.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
> Marko Kreen <marko@l-t.ee> writes:
> > I see 2 variants:
>
> > 1) put @with_openssl@ and @with_zlib@ variables into
> > contrib/pgcrypto/Makefile.in and let configure process it.
> > 2) put them in some other makefile fragment under src/
> > and let pgcrypto include it.
>
> > First I did the simple thing and put them into Makefile.global.in,
> > but this does not work, as it needs to be included _after_ all
> > module variables are set. So 2) needs a new file.
>
> Hm ... libpq manages to build code that requires openssl without
> needing a generated Makefile, so why do we need it here?

Now, looking more into it, it indeed does work.

But it breaks pgcrypto build for USE_PGXS case.

> I'd prefer #1 of these two, but seeing that no other contrib module
> has a Makefile.in, not having to do either would be even better.

Can I break USE_PGXS? Otherwise I need pre-processed
Makefile.in.

> This is particularly true if you aren't going to completely eliminate
> the hand-configuration options in the Makefile, because having to edit
> a generated Makefile or having to edit Makefile.in and then remember
> to reconfigure both suck.

I'd like to eliminate hand-config. Current code does not need
hand-config - you will miss only couple of algorithms without
OpenSSL. And there is no code that needs strong randomness.

With new PGP code, if you dont have OpenSSL you won't have
public-key code anyway - you can't configure bignum support.
That leaves randomness for pgp_sym_encrypt - which can be
solved with including a strong PRNG with pgcrypto. I think
this can be done in 8.1 timeframe, as it will be pretty
small piece of code.

There is also zlib - no need to configure it if I can get
it from main config.

--
marko


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster