Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Marko Kreen 
On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
 On Fri, 15 Jul 2005, Marko Kreen wrote:
 
  [buildfarm machine dragonfly]
  
  On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
   Well the buildfarm machine kudu is actually the same machine just 
   building 
   with the Sun compiler and it works fine.  It links all of libz.a into 
   libpgcrypto.so while gcc refuses to.
  
  I googled a bit and found two suggestions:
  
  1. http://curl.haxx.se/mail/lib-2002-01/0092.html
 (Use -mimpure-text on linking line)
  
  The attached patch does #1.  Could you try it and see if it fixes it?
  
 
 This patch works, pgcrypto links and passes its installcheck test now.
 
 Kris Jurka

Thanks.

Here is the patch with a little comment.

It should not break anything as it just disables a extra
argument -assert pure-text to linker.

Linking static libraries into shared one is bad idea, as the
static parts wont be shared between processes, but erroring
out is worse, especially if another compiler for a platform
allows it.

This makes gcc act same way as Sun's cc.

-- 
marko

Index: src/Makefile.shlib
===
RCS file: /opt/arc/cvs2/pgsql/src/Makefile.shlib,v
retrieving revision 1.95
diff -u -c -r1.95 Makefile.shlib
*** src/Makefile.shlib  13 Jul 2005 17:00:44 -  1.95
--- src/Makefile.shlib  16 Jul 2005 09:59:18 -
***
*** 188,194 
  
  ifeq ($(PORTNAME), solaris)
ifeq ($(GCC), yes)
! LINK.shared   = $(CC) -shared
else
  LINK.shared   = $(CC) -G
endif
--- 188,196 
  
  ifeq ($(PORTNAME), solaris)
ifeq ($(GCC), yes)
! # -mimpure-text disables passing '-assert pure-text' to linker,
! # to allow linking static library into shared one, like Sun's cc does.
! LINK.shared   = $(CC) -shared -mimpure-text
else
  LINK.shared   = $(CC) -G
endif

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
 Well the buildfarm machine kudu is actually the same machine just building 
 with the Sun compiler and it works fine.  It links all of libz.a into 
 libpgcrypto.so while gcc refuses to.
 
 I googled a bit and found two suggestions:
 
 1. http://curl.haxx.se/mail/lib-2002-01/0092.html
 (Use -mimpure-text on linking line)
 
 The attached patch does #1.  Could you try it and see if it fixes it?

This sure seems like a crude band-aid rather than an actual solution.
The bug as I see it is that gcc is choosing to link libz.a rather than
libz.so --- why is that happening?

regards, tom lane

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Kris Jurka 


On Sat, 16 Jul 2005, Tom Lane wrote:

 Marko Kreen marko@l-t.ee writes:
  I googled a bit and found two suggestions:
  
  1. http://curl.haxx.se/mail/lib-2002-01/0092.html
  (Use -mimpure-text on linking line)
  
 This sure seems like a crude band-aid rather than an actual solution.
 The bug as I see it is that gcc is choosing to link libz.a rather than
 libz.so --- why is that happening?
 

The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib 
while libz.so is in /usr/lib.

Kris Jurka

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Tom Lane 
Kris Jurka [EMAIL PROTECTED] writes:
 On Sat, 16 Jul 2005, Tom Lane wrote:
 This sure seems like a crude band-aid rather than an actual solution.
 The bug as I see it is that gcc is choosing to link libz.a rather than
 libz.so --- why is that happening?

 The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib 
 while libz.so is in /usr/lib.

Well, that is a flat-out configuration error on the local sysadmin's
part.  I can't think of any good reason for the .so and .a versions of a
library to live in different places.  We certainly shouldn't hack our
build process to build deliberately-inefficient object files in order to
accommodate such a setup.

regards, tom lane

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

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

Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Kris Jurka 


On Sat, 16 Jul 2005, Tom Lane wrote:

 Kris Jurka [EMAIL PROTECTED] writes:
 
  The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib 
  while libz.so is in /usr/lib.
 
 Well, that is a flat-out configuration error on the local sysadmin's
 part.  I can't think of any good reason for the .so and .a versions of a
 library to live in different places.  We certainly shouldn't hack our
 build process to build deliberately-inefficient object files in order to
 accommodate such a setup.
 

Well the OS only came with the shared library and I needed the static one
for some reason, so I installed it alone under /usr/local.  This works 
fine with Sun's cc and Marko's research indicates that this will also 
work fine using GNU ld instead of Sun's ld.  This is certainly an unusual 
thing to do, but I don't believe it is a flat-out configuration error, 
consider what would happen if the shared library didn't exist at all and 
only a static version were available.  Until this recent batch of pgcrypto 
changes everything built fine.

Kris Jurka

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

   http://archives.postgresql.org

Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-16 Thread Tom Lane 
Kris Jurka [EMAIL PROTECTED] writes:
 consider what would happen if the shared library didn't exist at all and 
 only a static version were available.  Until this recent batch of pgcrypto 
 changes everything built fine.

Well, the right answer to that really is that pgcrypto ought not try to
link to libz unless a shared libz is available (compare for instance the
situation with plperl and an unshared libperl).  However, I'm not sure
that we could reasonably expect to make a configuration test that would
detect a situation like this --- that is, if we did look for shared
libz, we would find it, and the fact that a nonshared libz in a
different place would cause the actual link to fail seems like something
that configure would be unlikely to be able to realize.

I'm still of the opinion that your libz installation is broken; the fact
that some other products chance not to fail with it is not evidence that
it's OK.  You could for instance have installed both libz.a and libz.so
from the same build in /usr/local/lib, and that would work fine,
independently of the existence of a version in /usr/lib.

Come to think of it, are you sure that the versions in /usr/lib and
/usr/local/lib are even ABI-compatible?  If they are from different zlib
releases, I think you're risking trouble regardless.  Really the right
way to deal with this sort of thing is that you put libz.a and libz.so
in /usr/local/lib and corresponding headers in /usr/local/include, and
then you don't need to sweat whether they are exactly compatible with
what appears in /usr/lib and /usr/include.

regards, tom lane

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-15 Thread Marko Kreen 
[buildfarm machine dragonfly]

On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
 Well the buildfarm machine kudu is actually the same machine just building 
 with the Sun compiler and it works fine.  It links all of libz.a into 
 libpgcrypto.so while gcc refuses to.

I googled a bit and found two suggestions:

1. http://curl.haxx.se/mail/lib-2002-01/0092.html
   (Use -mimpure-text on linking line)

2. http://www.filibeto.org/pipermail/solaris-users/2004-March/000662.html
   (that using GNU ld not Sun's fixes it)

The attached patch does #1.  Could you try it and see if it fixes it?

-- 
marko

Index: src/Makefile.shlib
===
RCS file: /opt/arc/cvs2/pgsql/src/Makefile.shlib,v
retrieving revision 1.95
diff -u -c -r1.95 Makefile.shlib
*** src/Makefile.shlib  13 Jul 2005 17:00:44 -  1.95
--- src/Makefile.shlib  15 Jul 2005 17:11:57 -
***
*** 188,194 
  
  ifeq ($(PORTNAME), solaris)
ifeq ($(GCC), yes)
! LINK.shared   = $(CC) -shared
else
  LINK.shared   = $(CC) -G
endif
--- 188,194 
  
  ifeq ($(PORTNAME), solaris)
ifeq ($(GCC), yes)
! LINK.shared   = $(CC) -shared -mimpure-text
else
  LINK.shared   = $(CC) -G
endif

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

   http://archives.postgresql.org

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-15 Thread Kris Jurka 


On Fri, 15 Jul 2005, Marko Kreen wrote:

 [buildfarm machine dragonfly]
 
 On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
  Well the buildfarm machine kudu is actually the same machine just building 
  with the Sun compiler and it works fine.  It links all of libz.a into 
  libpgcrypto.so while gcc refuses to.
 
 I googled a bit and found two suggestions:
 
 1. http://curl.haxx.se/mail/lib-2002-01/0092.html
(Use -mimpure-text on linking line)
 
 The attached patch does #1.  Could you try it and see if it fixes it?
 

This patch works, pgcrypto links and passes its installcheck test now.

Kris Jurka


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-12 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote:
 Marko Kreen wrote:
 
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
 
 Linking problem with zlib on Solaris 9/x86.  I am clueless about
 this.  I can anyone look into it?
 
 
 It appears to be finding the static /usr/local/lib/libz.a instead of the 
 dynamic /usr/lib/libz.so.

So it is a local problem?  I see that the configure line contains:
--with-includes=/usr/local/include --with-libs=/usr/local/lib
explicitly.

-- 
marko


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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-12 Thread Kris Jurka 


On Tue, 12 Jul 2005, Marko Kreen wrote:

 On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote:
  Marko Kreen wrote:
  
  http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
  
  Linking problem with zlib on Solaris 9/x86.  I am clueless about
  this.  I can anyone look into it?
  
  
  It appears to be finding the static /usr/local/lib/libz.a instead of the 
  dynamic /usr/lib/libz.so.
 
 So it is a local problem?  I see that the configure line contains:
 --with-includes=/usr/local/include --with-libs=/usr/local/lib
 explicitly.
 

Well the buildfarm machine kudu is actually the same machine just building 
with the Sun compiler and it works fine.  It links all of libz.a into 
libpgcrypto.so while gcc refuses to.

Kris Jurka


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

   http://archives.postgresql.org

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-12 Thread Marko Kreen 
Seems like down mail server ate first mail.

Here it is again.

On Tue, Jul 12, 2005 at 12:51:44PM +0300, Marko Kreen wrote:
 
 Hopefully the last regression failure.
 
 - openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
   constants for buffers, which are small in case of
   OpenSSL 0.9.6x and internal AES.  (I tested it with
   0.9.7 only, so I didn't notice...)
 - Also I noticed that the wrapper macros for CBC mode
   do not update IV buffer.
 - As the previous mistake was not picked up by current
   regression tests, I added a 'longer than a block'
   test to all ciphers.
 
 -- 
 marko
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.24
diff -u -c -r1.24 openssl.c
*** contrib/pgcrypto/openssl.c  11 Jul 2005 15:07:59 -  1.24
--- contrib/pgcrypto/openssl.c  12 Jul 2005 09:27:59 -
***
*** 40,45 
--- 40,50 
  #include openssl/rand.h
  #include openssl/err.h
  
+ /*
+  * Max lengths we might want to handle.
+  */
+ #define MAX_KEY   (512/8)
+ #define MAX_IV(128/8)
  
  /*
   * Does OpenSSL support AES? 
***
*** 78,87 
  #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
!   if (enc) \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
!   else \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
} while (0)
  
  #endif/* old OPENSSL */
--- 83,95 
  #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
!   if (enc) { \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
!   memcpy((iv), (dst) + (len) - 16, 16); \
!   } else { \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+   memcpy(iv, (src) + (len) - 16, 16); \
+   } \
} while (0)
  
  #endif/* old OPENSSL */
***
*** 243,250 
CAST_KEYcast_key;
AES_KEY aes_key;
}   u;
!   uint8   key[EVP_MAX_KEY_LENGTH];
!   uint8   iv[EVP_MAX_IV_LENGTH];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
--- 251,258 
CAST_KEYcast_key;
AES_KEY aes_key;
}   u;
!   uint8   key[MAX_KEY];
!   uint8   iv[MAX_IV];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
Index: contrib/pgcrypto/expected/3des.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/3des.out,v
retrieving revision 1.2
diff -u -c -r1.2 3des.out
*** contrib/pgcrypto/expected/3des.out  5 Jul 2005 18:15:36 -   1.2
--- contrib/pgcrypto/expected/3des.out  12 Jul 2005 09:41:16 -
***
*** 54,56 
--- 54,69 
   foo
  (1 row)
  
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789012345678901', 
'3des'), 'hex');
+   encode  
+ --
+  b71e3422269d0ded19468f33d65cd663c28e0871984792a7b3ba0ddcecec8d2c
+ (1 row)
+ 
+ select decrypt(encrypt('Lets try a longer message.', 
'0123456789012345678901', '3des'), '0123456789012345678901', '3des');
+   decrypt   
+ 
+  Lets try a longer message.
+ (1 row)
+ 
Index: contrib/pgcrypto/expected/blowfish.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/blowfish.out,v
retrieving revision 1.4
diff -u -c -r1.4 blowfish.out
*** contrib/pgcrypto/expected/blowfish.out  21 Mar 2005 05:24:51 -  
1.4
--- contrib/pgcrypto/expected/blowfish.out  12 Jul 2005 09:32:13 -
***
*** 158,160 
--- 158,173 
   foo
  (1 row)
  
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789', 'bf'), 
'hex');
+   encode  
+ --
+  a76059f7a1b627b5b84080d9beb337714c7a7f8b70300023e5feb6dfa6813536
+ (1 row)
+ 
+ select decrypt(encrypt('Lets try a longer message.', '0123456789', 'bf'), 
'0123456789', 'bf');
+   decrypt   
+ 
+  Lets try a longer message.
+ (1 row)
+ 
Index: contrib/pgcrypto/expected/cast5.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/cast5.out,v
retrieving revision

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-12 Thread Marko Kreen 

Hopefully the last regression failure.

- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
  constants for buffers, which are small in case of
  OpenSSL 0.9.6x and internal AES.  (I tested it with
  0.9.7 only, so I didn't notice...)
- Also I noticed that the wrapper macros for CBC mode
  do not update IV buffer.
- As the previous mistake was not picked up by current
  regression tests, I added a 'longer than a block'
  test to all ciphers.

-- 
marko

Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.24
diff -u -c -r1.24 openssl.c
*** contrib/pgcrypto/openssl.c  11 Jul 2005 15:07:59 -  1.24
--- contrib/pgcrypto/openssl.c  12 Jul 2005 09:27:59 -
***
*** 40,45 
--- 40,50 
  #include openssl/rand.h
  #include openssl/err.h
  
+ /*
+  * Max lengths we might want to handle.
+  */
+ #define MAX_KEY   (512/8)
+ #define MAX_IV(128/8)
  
  /*
   * Does OpenSSL support AES? 
***
*** 78,87 
  #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
!   if (enc) \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
!   else \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
} while (0)
  
  #endif/* old OPENSSL */
--- 83,95 
  #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
!   if (enc) { \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
!   memcpy((iv), (dst) + (len) - 16, 16); \
!   } else { \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+   memcpy(iv, (src) + (len) - 16, 16); \
+   } \
} while (0)
  
  #endif/* old OPENSSL */
***
*** 243,250 
CAST_KEYcast_key;
AES_KEY aes_key;
}   u;
!   uint8   key[EVP_MAX_KEY_LENGTH];
!   uint8   iv[EVP_MAX_IV_LENGTH];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
--- 251,258 
CAST_KEYcast_key;
AES_KEY aes_key;
}   u;
!   uint8   key[MAX_KEY];
!   uint8   iv[MAX_IV];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
Index: contrib/pgcrypto/expected/3des.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/3des.out,v
retrieving revision 1.2
diff -u -c -r1.2 3des.out
*** contrib/pgcrypto/expected/3des.out  5 Jul 2005 18:15:36 -   1.2
--- contrib/pgcrypto/expected/3des.out  12 Jul 2005 09:41:16 -
***
*** 54,56 
--- 54,69 
   foo
  (1 row)
  
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789012345678901', 
'3des'), 'hex');
+   encode  
+ --
+  b71e3422269d0ded19468f33d65cd663c28e0871984792a7b3ba0ddcecec8d2c
+ (1 row)
+ 
+ select decrypt(encrypt('Lets try a longer message.', 
'0123456789012345678901', '3des'), '0123456789012345678901', '3des');
+   decrypt   
+ 
+  Lets try a longer message.
+ (1 row)
+ 
Index: contrib/pgcrypto/expected/blowfish.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/blowfish.out,v
retrieving revision 1.4
diff -u -c -r1.4 blowfish.out
*** contrib/pgcrypto/expected/blowfish.out  21 Mar 2005 05:24:51 -  
1.4
--- contrib/pgcrypto/expected/blowfish.out  12 Jul 2005 09:32:13 -
***
*** 158,160 
--- 158,173 
   foo
  (1 row)
  
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789', 'bf'), 
'hex');
+   encode  
+ --
+  a76059f7a1b627b5b84080d9beb337714c7a7f8b70300023e5feb6dfa6813536
+ (1 row)
+ 
+ select decrypt(encrypt('Lets try a longer message.', '0123456789', 'bf'), 
'0123456789', 'bf');
+   decrypt   
+ 
+  Lets try a longer message.
+ (1 row)
+ 
Index: contrib/pgcrypto/expected/cast5.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/cast5.out,v
retrieving revision 1.1
diff -u -c -r1.1 cast5.out
*** contrib/pgcrypto/expected/cast5.out 21 Mar 2005 05:24:51 -  1.1
---

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-12 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 Hopefully the last regression failure.

 - openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
   constants for buffers, which are small in case of
   OpenSSL 0.9.6x and internal AES.  (I tested it with
   0.9.7 only, so I didn't notice...)
 - Also I noticed that the wrapper macros for CBC mode
   do not update IV buffer.
 - As the previous mistake was not picked up by current
   regression tests, I added a 'longer than a block'
   test to all ciphers.

Applied, thanks.

regards, tom lane

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

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

[HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=potorooodt=2005-07-10%2022:30:03

New sha2 code on Solaris 2.8 / SPARC.  Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.

Attached patch fixes it by simplifying the _Final code and
getting rid of the pointer.

(I redefined bzero and bcopy but now I think they should be
replaced directly - patch later.)



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=goosedt=2005-07-11%2006:00:04
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ferretdt=2005-07-10%2018:25:11

The new sha2.c checks not only whether BYTE_ENDIAN is
LITTLE_ENDIAN or BIG_ENDIAN but also whether it is set.
And the test fails on both Cygwin and MINGW.

As gcc evaluates #if UNDEF1 == UNDEF2 as true and there
were no compile failures reported with current code, that
means currently internal AES, SHA1 and MD5 used randomly
big-endian, little-endian or both variants of code.

If there was no regression failures on those platforms,
it must be only by dumb luck.

Attached patch includes sys/param.h, where I found them on
MINGW, and puts stricter checks into all files.

After I see successful run in pgbuildfarm, I send it for
stable branches too.



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00

NetBSD 1.6 with older OpenSSL.  OpenSSL  0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
And the AES tests fails anyway.  I guess it can stay as expected
failure.



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04

Linking problem with zlib on Solaris 9/x86.  I am clueless about
this.  I can anyone look into it?

Error message:
ld: fatal: relocations remain against allocatable but non-writable sections


-- 
marko

Index: pgsql/contrib/pgcrypto/sha2.c
===
*** pgsql.orig/contrib/pgcrypto/sha2.c
--- pgsql/contrib/pgcrypto/sha2.c
*** SHA256_Update(SHA256_CTX *context, const
*** 496,502 
  void
  SHA256_Final(uint8 digest[], SHA256_CTX *context)
  {
-   uint32  *d = (uint32 *)digest;
unsigned intusedspace;
  
/* If no digest buffer is passed, we don't bother doing this: */
--- 496,501 
*** SHA256_Final(uint8 digest[], SHA256_CTX 
*** 542,553 
int j;
for (j = 0; j  8; j++) {
REVERSE32(context-state[j],context-state[j]);
-   *d++ = context-state[j];
}
}
- #else
-   bcopy(context-state, d, SHA256_DIGEST_LENGTH);
  #endif
}
  
/* Clean up state data: */
--- 541,550 
int j;
for (j = 0; j  8; j++) {
REVERSE32(context-state[j],context-state[j]);
}
}
  #endif
+   bcopy(context-state, digest, SHA256_DIGEST_LENGTH);
}
  
/* Clean up state data: */
*** SHA512_Last(SHA512_CTX *context)
*** 823,830 
  void
  SHA512_Final(uint8 digest[], SHA512_CTX *context)
  {
-   uint64  *d = (uint64 *)digest;
- 
/* If no digest buffer is passed, we don't bother doing this: */
if (digest != NULL) {
SHA512_Last(context);
--- 820,825 
*** SHA512_Final(uint8 digest[], SHA512_CTX 
*** 836,847 
int j;
for (j = 0; j  8; j++) {
REVERSE64(context-state[j],context-state[j]);
-   *d++ = context-state[j];
}
}
- #else
-   bcopy(context-state, d, SHA512_DIGEST_LENGTH);
  #endif
}
  
/* Zero out state data */
--- 831,840 
int j;
for (j = 0; j  8; j++) {
REVERSE64(context-state[j],context-state[j]);
}
}
  #endif
+   bcopy(context-state, digest, SHA512_DIGEST_LENGTH);
}
  
/* Zero out state data */
*** SHA384_Update(SHA384_CTX *context, const
*** 869,876 
  void
  SHA384_Final(uint8 digest[], SHA384_CTX *context)
  {
-   uint64  *d = (uint64 *)digest;
- 
/* If no digest buffer is passed, we don't bother doing this: */
if (digest != NULL) {
SHA512_Last((SHA512_CTX *)context);
--- 862,867 
*** SHA384_Final(uint8 digest[], SHA384_CTX 
*** 882,893 
int j;
for (j = 0; j  6; j++) {
REVERSE64(context-state[j],context-state[j]);
-   *d++ = context-state[j];
}
}
- #else
-   bcopy(context-state, d, SHA384_DIGEST_LENGTH);
  #endif
}

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Andrew Dunstan 
Marko Kreen said:




http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
 NetBSD 1.6 with older OpenSSL.  OpenSSL  0.9.7 does not have
 AES, but most of PGP tests use it as it is the preferred cipher.
 And the AES tests fails anyway.  I guess it can stay as expected
 failure.


Please try to avoid expected failures if possible. If you must have them,
move them into a test file of their own. Consider the possibility of using
alternative .out files.

This doesn't matter to Buildfarm quite so much for contrib as it does for
main or PL regression sets, as contrib is the last thing checked, so a
failure there doesn't block any other steps in the checking process. Still,
a contrib failure will show up as yellow rather than green.

Buildfarm does not currently have a way of knowing what failure is expected
and what is not - it currently treats any regression failure as unexpected.
Changing that is on my TODO list, but it's not going to happen any time soon.

cheers

andrew



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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
 Marko Kreen said:
 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
  NetBSD 1.6 with older OpenSSL.  OpenSSL  0.9.7 does not have
  AES, but most of PGP tests use it as it is the preferred cipher.
  And the AES tests fails anyway.  I guess it can stay as expected
  failure.
 
 Please try to avoid expected failures if possible. If you must have them,
 move them into a test file of their own. Consider the possibility of using
 alternative .out files.

I need either to use included rijndael.c for AES with older
OpenSSL or rerun all tests to be Blowfish-only.

I want to standardise on AES so the former is preferred.

Now there's a choice:

1. Check OpenSSL version in main configure
2. #include rijndael.c in openssl.c

I guess 1. is nicer.  I try to hack something together.

-- 
marko


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 02:59:54PM +0300, Marko Kreen wrote:
 On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
  Marko Kreen said:
  http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
   NetBSD 1.6 with older OpenSSL.  OpenSSL  0.9.7 does not have
   AES, but most of PGP tests use it as it is the preferred cipher.
   And the AES tests fails anyway.  I guess it can stay as expected
   failure.
  
  Please try to avoid expected failures if possible. If you must have them,
  move them into a test file of their own. Consider the possibility of using
  alternative .out files.
 
 I need either to use included rijndael.c for AES with older
 OpenSSL or rerun all tests to be Blowfish-only.
 
 I want to standardise on AES so the former is preferred.
 
 Now there's a choice:
 
 1. Check OpenSSL version in main configure
 2. #include rijndael.c in openssl.c
 
 I guess 1. is nicer.  I try to hack something together.

I tried 1. but that was messing with main build system for no
good reason.  As the openssl.c would still be mess, so I went
with 2.

Result is - it's not so bad.  As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.

-- 
marko

Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.22
diff -u -c -r1.22 openssl.c
*** contrib/pgcrypto/openssl.c  10 Jul 2005 13:54:34 -  1.22
--- contrib/pgcrypto/openssl.c  11 Jul 2005 13:02:00 -
***
*** 44,53 
  /*
   * Does OpenSSL support AES? 
   */
- #undef GOT_AES
  #if OPENSSL_VERSION_NUMBER = 0x00907000L
! #define GOT_AES
  #include openssl/aes.h
  #endif
  
  /*
--- 44,89 
  /*
   * Does OpenSSL support AES? 
   */
  #if OPENSSL_VERSION_NUMBER = 0x00907000L
! 
! /* Yes, it does. */
  #include openssl/aes.h
+ 
+ #else
+ 
+ /*
+  * No, it does not.  So use included rijndael code to emulate it.
+  */
+ #include rijndael.c
+ 
+ #define AES_ENCRYPT 1
+ #define AES_DECRYPT 0
+ #define AES_KEY   rijndael_ctx
+ 
+ #define AES_set_encrypt_key(key, kbits, ctx) \
+   aes_set_key((ctx), (key), (kbits), 1)
+ 
+ #define AES_set_decrypt_key(key, kbits, ctx) \
+   aes_set_key((ctx), (key), (kbits), 0)
+ 
+ #define AES_ecb_encrypt(src, dst, ctx, enc) \
+   do { \
+   memcpy((dst), (src), 16); \
+   if (enc) \
+   aes_ecb_encrypt((ctx), (dst), 16); \
+   else \
+   aes_ecb_decrypt((ctx), (dst), 16); \
+   } while (0)
+ 
+ #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
+   do { \
+   memcpy((dst), (src), (len)); \
+   if (enc) \
+   aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
+   else \
+   aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+   } while (0)
+ 
  #endif
  
  /*
***
*** 205,213 
DES_key_schedule k1, k2, k3;
}   des3;
CAST_KEYcast_key;
- #ifdef GOT_AES
AES_KEY aes_key;
- #endif
}   u;
uint8   key[EVP_MAX_KEY_LENGTH];
uint8   iv[EVP_MAX_IV_LENGTH];
--- 241,247 
***
*** 549,556 
  
  /* AES */
  
- #ifdef GOT_AES
- 
  static int
  ossl_aes_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
  {
--- 583,588 
***
*** 642,648 
AES_cbc_encrypt(data, res, dlen, od-u.aes_key, od-iv, AES_DECRYPT);
return 0;
  }
- #endif
  
  /*
   * aliases
--- 674,679 
***
*** 711,717 
64 / 8, 128 / 8, 0
  };
  
- #ifdef GOT_AES
  static const struct ossl_cipher ossl_aes_ecb = {
ossl_aes_init, ossl_aes_ecb_encrypt, ossl_aes_ecb_decrypt,
128 / 8, 256 / 8, 0
--- 742,747 
***
*** 721,727 
ossl_aes_init, ossl_aes_cbc_encrypt, ossl_aes_cbc_decrypt,
128 / 8, 256 / 8, 0
  };
- #endif
  
  /*
   * Special handlers
--- 751,756 
***
*** 742,751 
{des3-cbc, ossl_des3_cbc},
{cast5-ecb, ossl_cast_ecb},
{cast5-cbc, ossl_cast_cbc},
- #ifdef GOT_AES
{aes-ecb, ossl_aes_ecb},
{aes-cbc, ossl_aes_cbc},
- #endif
{NULL}
  };
  
--- 771,778 

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 Result is - it's not so bad.  As I used rijndael.c to provide
 OpenSSL's own interface, I even got rid of all the ifdefs inside
 the code.

Looks good, but I'm still getting these compile warnings:

openssl.c: In function `ossl_des3_ecb_encrypt':
openssl.c:484: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible 
pointer type
openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible 
pointer type
openssl.c: In function `ossl_des3_ecb_decrypt':
openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible 
pointer type
openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible 
pointer type

The following addition to the patch shuts up gcc with openssl 0.9.7a,
but I'm not sure if it will break anything with older openssl ---
comments?

regards, tom lane


*** /home/postgres/pgsql/contrib/pgcrypto/openssl.c Sun Jul 10 12:35:38 2005
--- new/openssl.c   Mon Jul 11 10:06:30 2005
***
*** 446,452 
ossldata   *od = c-ptr;
  
for (i = 0; i  dlen / bs; i++)
!   DES_ecb3_encrypt(data + i * bs, res + i * bs,
 od-u.des3.k1, 
od-u.des3.k2, od-u.des3.k3, 1);
return 0;
  }
--- 480,487 
ossldata   *od = c-ptr;
  
for (i = 0; i  dlen / bs; i++)
!   DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
!(DES_cblock *) (res + i * bs),
 od-u.des3.k1, 
od-u.des3.k2, od-u.des3.k3, 1);
return 0;
  }
***
*** 460,466 
ossldata   *od = c-ptr;
  
for (i = 0; i  dlen / bs; i++)
!   DES_ecb3_encrypt(data + i * bs, res + i * bs,
 od-u.des3.k1, 
od-u.des3.k2, od-u.des3.k3, 0);
return 0;
  }
--- 495,502 
ossldata   *od = c-ptr;
  
for (i = 0; i  dlen / bs; i++)
!   DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
!(DES_cblock *) (res + i * bs),
 od-u.des3.k1, 
od-u.des3.k2, od-u.des3.k3, 0);
return 0;
  }

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 (I redefined bzero and bcopy but now I think they should be
 replaced directly - patch later.)

Please.  We do not use those old functions in the Postgres code;
memcpy, memmove, memset, etc are the project standard.

regards, tom lane

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
 Marko Kreen marko@l-t.ee writes:
  Result is - it's not so bad.  As I used rijndael.c to provide
  OpenSSL's own interface, I even got rid of all the ifdefs inside
  the code.
 
 Looks good, but I'm still getting these compile warnings:
 
 openssl.c: In function `ossl_des3_ecb_encrypt':
 openssl.c:484: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible 
 pointer type
 openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible 
 pointer type
 openssl.c: In function `ossl_des3_ecb_decrypt':
 openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible 
 pointer type
 openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible 
 pointer type
 
 The following addition to the patch shuts up gcc with openssl 0.9.7a,
 but I'm not sure if it will break anything with older openssl ---
 comments?

They won't matter on older OpenSSL, as the macros will recast
again.  But on 0.9.7e the signature is:

void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
  DES_key_schedule *ks1,DES_key_schedule *ks2,
  DES_key_schedule *ks3, int enc);

so it seems to me that with your patch the warnings will appear
on newer OpenSSL.  (Confirmed)

-- 
marko


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 10:13:22AM -0400, Tom Lane wrote:
 Marko Kreen marko@l-t.ee writes:
  (I redefined bzero and bcopy but now I think they should be
  replaced directly - patch later.)
 
 Please.  We do not use those old functions in the Postgres code;
 memcpy, memmove, memset, etc are the project standard.

Indeed.  But I'll wait until the previous sha2 patch is applied
as they would conflict.

-- 
marko


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

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
 The following addition to the patch shuts up gcc with openssl 0.9.7a,
 but I'm not sure if it will break anything with older openssl ---
 comments?

 They won't matter on older OpenSSL, as the macros will recast
 again.  But on 0.9.7e the signature is:

 void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
   DES_key_schedule *ks1,DES_key_schedule *ks2,
   DES_key_schedule *ks3, int enc);

 so it seems to me that with your patch the warnings will appear
 on newer OpenSSL.  (Confirmed)

Grumble --- you're right.  It's probably not worth ifdef'ing the code to
suppress the warnings on 0.9.7a ...

regards, tom lane

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

   http://archives.postgresql.org

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 New sha2 code on Solaris 2.8 / SPARC.  Seems like it has
 problems memcpy'ing to a non-8-byte-aligned uint64 *.
 ...
 Attached patch includes sys/param.h, where I found them on
 MINGW, and puts stricter checks into all files.

Applied.

regards, tom lane

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

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Michael Fuhr 
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
 Marko Kreen marko@l-t.ee writes:
  They won't matter on older OpenSSL, as the macros will recast
  again.  But on 0.9.7e the signature is:
 
  void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);
 
  so it seems to me that with your patch the warnings will appear
  on newer OpenSSL.  (Confirmed)
 
 Grumble --- you're right.  It's probably not worth ifdef'ing the code to
 suppress the warnings on 0.9.7a ...

Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:

void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
  DES_key_schedule *ks1,DES_key_schedule *ks2,
  DES_key_schedule *ks3, int enc);

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

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

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 11:09:06AM -0400, Tom Lane wrote:
 Marko Kreen marko@l-t.ee writes:
  New sha2 code on Solaris 2.8 / SPARC.  Seems like it has
  problems memcpy'ing to a non-8-byte-aligned uint64 *.
  ...
  Attached patch includes sys/param.h, where I found them on
  MINGW, and puts stricter checks into all files.
 
 Applied.

I see you also cleaned the includes.  Thanks.

Here is the bcopy, bzero removal patch.

-- 
marko


Index: contrib/pgcrypto/sha2.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/sha2.c,v
retrieving revision 1.2
diff -u -c -r1.2 sha2.c
*** contrib/pgcrypto/sha2.c 11 Jul 2005 15:07:59 -  1.2
--- contrib/pgcrypto/sha2.c 11 Jul 2005 15:20:33 -
***
*** 42,52 
  
  #include sha2.h
  
- #undef bcopy
- #undef bzero
- #define bcopy(src, dst, len)  memcpy((dst), (src), (len))
- #define bzero(ptr, len)   memset((ptr), 0, (len))
- 
  /*
   * UNROLLED TRANSFORM LOOP NOTE:
   * You can define SHA2_UNROLL_TRANSFORM to use the unrolled transform
--- 42,47 
***
*** 281,288 
  {
if (context == NULL)
return;
!   bcopy(sha256_initial_hash_value, context-state, SHA256_DIGEST_LENGTH);
!   bzero(context-buffer, SHA256_BLOCK_LENGTH);
context-bitcount = 0;
  }
  
--- 276,283 
  {
if (context == NULL)
return;
!   memcpy(context-state, sha256_initial_hash_value, SHA256_DIGEST_LENGTH);
!   memset(context-buffer, 0, SHA256_BLOCK_LENGTH);
context-bitcount = 0;
  }
  
***
*** 466,479 
  
if (len = freespace) {
/* Fill the buffer completely and process it */
!   bcopy(data, context-buffer[usedspace], freespace);
context-bitcount += freespace  3;
len -= freespace;
data += freespace;
SHA256_Transform(context, context-buffer);
} else {
/* The buffer is not yet full */
!   bcopy(data, context-buffer[usedspace], len);
context-bitcount += len  3;
/* Clean up: */
usedspace = freespace = 0;
--- 461,474 
  
if (len = freespace) {
/* Fill the buffer completely and process it */
!   memcpy(context-buffer[usedspace], data, freespace);
context-bitcount += freespace  3;
len -= freespace;
data += freespace;
SHA256_Transform(context, context-buffer);
} else {
/* The buffer is not yet full */
!   memcpy(context-buffer[usedspace], data, len);
context-bitcount += len  3;
/* Clean up: */
usedspace = freespace = 0;
***
*** 489,495 
}
if (len  0) {
/* There's left-overs, so save 'em */
!   bcopy(data, context-buffer, len);
context-bitcount += len  3;
}
/* Clean up: */
--- 484,490 
}
if (len  0) {
/* There's left-overs, so save 'em */
!   memcpy(context-buffer, data, len);
context-bitcount += len  3;
}
/* Clean up: */
***
*** 514,533 
  
if (usedspace = SHA256_SHORT_BLOCK_LENGTH) {
/* Set-up for the last transform: */
!   bzero(context-buffer[usedspace], 
SHA256_SHORT_BLOCK_LENGTH - usedspace);
} else {
if (usedspace  SHA256_BLOCK_LENGTH) {
!   bzero(context-buffer[usedspace], 
SHA256_BLOCK_LENGTH - usedspace);
}
/* Do second-to-last transform: */
SHA256_Transform(context, context-buffer);
  
/* And set-up for the last transform: */
!   bzero(context-buffer, 
SHA256_SHORT_BLOCK_LENGTH);
}
} else {
/* Set-up for the last transform: */
!   bzero(context-buffer, SHA256_SHORT_BLOCK_LENGTH);
  
/* Begin padding with a 1 bit: */
*context-buffer = 0x80;
--- 509,528 
  
if (usedspace = SHA256_SHORT_BLOCK_LENGTH) {
/* Set-up for the last transform: */
!   memset(context-buffer[usedspace], 0, 
SHA256_SHORT_BLOCK_LENGTH - usedspace);
} else {
if

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 09:19:37AM -0600, Michael Fuhr wrote:
 On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
  Marko Kreen marko@l-t.ee writes:
   They won't matter on older OpenSSL, as the macros will recast
   again.  But on 0.9.7e the signature is:
  
   void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
 DES_key_schedule *ks1,DES_key_schedule *ks2,
 DES_key_schedule *ks3, int enc);
  
   so it seems to me that with your patch the warnings will appear
   on newer OpenSSL.  (Confirmed)
  
  Grumble --- you're right.  It's probably not worth ifdef'ing the code to
  suppress the warnings on 0.9.7a ...
 
 Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:
 
 void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
   DES_key_schedule *ks1,DES_key_schedule *ks2,
   DES_key_schedule *ks3, int enc);

Ugh.  As I see the old signature goes up to 0.9.7d, and only
0.9.7[e,f,g] have the new signature.

0.9.7e is released on Oct 2004.  There is a chance that the 0.9.8 serie
was branched before that and later 0.9.8x releases will also
change signature.  Or the change was mistake, and it was
reversed in 0.9.8 - but then why release 0.9.7[f,g] with new
signature?

When I saw that only 0.9.7[efg] have new signature I even
considered macrofying that.  But now with 0.9.8 again different
I really would like to not to touch it, as I have no idea which
one will be the stable signature.

Comments?

-- 
marko


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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 Here is the bcopy, bzero removal patch.

Applied.

I'm seeing the following build failure on HPUX:

/usr/ccs/bin/ld +h libpgcrypto.sl.0 -b +b /home/postgres/testversion/lib  
pgcrypto.o px.o px-hmac.o px-crypt.o misc.o crypt-gensalt.o crypt-blowfish.o 
crypt-des.o crypt-md5.o  md5.o sha1.o sha2.o internal.o blf.o rijndael.o 
fortuna.o random.o pgp-mpi-internal.o mbuf.o pgp.o pgp-armor.o pgp-cfb.o 
pgp-compress.o pgp-decrypt.o pgp-encrypt.o pgp-info.o pgp-mpi.o pgp-pubdec.o 
pgp-pubenc.o pgp-pubkey.o pgp-s2k.o pgp-pgsql.o -L../../src/port  `gcc 
-L../../src/port  -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib 
-print-libgcc-file-name`  -lz -o libpgcrypto.sl.0
/usr/ccs/bin/ld: Can't find library for -lz
make: *** [libpgcrypto.sl.0] Error 1

I believe the issue is that libz.sl is in /usr/local/lib/, which is not
searched by default by HP's linker.  It *is* searched by default by gcc,
which is why -lz works without any explicit -L in the pg_dump/pg_restore
builds.  But here we are invoking a different tool with a different
default search path.

Possibly there's something similar happening on that Solaris buildfarm
machine?

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Michael Fuhr 
On Mon, Jul 11, 2005 at 06:41:35PM +0300, Marko Kreen wrote:
 When I saw that only 0.9.7[efg] have new signature I even
 considered macrofying that.  But now with 0.9.8 again different
 I really would like to not to touch it, as I have no idea which
 one will be the stable signature.
 
 Comments?

Sounds like a question for the OpenSSL developers.  If a search
through their list archives or CVS repository doesn't yield the
answer, then maybe asking the question on one of their lists will.

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

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

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
On Mon, Jul 11, 2005 at 11:46:29AM -0400, Tom Lane wrote:
 Marko Kreen marko@l-t.ee writes:
  Here is the bcopy, bzero removal patch.
 
 Applied.
 
 I'm seeing the following build failure on HPUX:
 
 /usr/ccs/bin/ld +h libpgcrypto.sl.0 -b +b /home/postgres/testversion/lib  
 pgcrypto.o px.o px-hmac.o px-crypt.o misc.o crypt-gensalt.o crypt-blowfish.o 
 crypt-des.o crypt-md5.o  md5.o sha1.o sha2.o internal.o blf.o rijndael.o 
 fortuna.o random.o pgp-mpi-internal.o mbuf.o pgp.o pgp-armor.o pgp-cfb.o 
 pgp-compress.o pgp-decrypt.o pgp-encrypt.o pgp-info.o pgp-mpi.o pgp-pubdec.o 
 pgp-pubenc.o pgp-pubkey.o pgp-s2k.o pgp-pgsql.o -L../../src/port  `gcc 
 -L../../src/port  -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib 
 -print-libgcc-file-name`  -lz -o libpgcrypto.sl.0
 /usr/ccs/bin/ld: Can't find library for -lz
 make: *** [libpgcrypto.sl.0] Error 1
 
 I believe the issue is that libz.sl is in /usr/local/lib/, which is not
 searched by default by HP's linker.  It *is* searched by default by gcc,
 which is why -lz works without any explicit -L in the pg_dump/pg_restore
 builds.  But here we are invoking a different tool with a different
 default search path.
 
 Possibly there's something similar happening on that Solaris buildfarm
 machine?

No, there it finds the libz (in /usr/local/lib - the link command
is gcc with -L/usr/local/lib), but in not satisfied with .. something.

-- 
marko


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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Marko Kreen 
Another build failure from buildfarm.  Seems like
I forgot to update win32 code when doing a renaming
in random.c

-- 
marko

Index: contrib/pgcrypto/random.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/random.c,v
retrieving revision 1.12
diff -u -c -r1.12 random.c
*** contrib/pgcrypto/random.c   11 Jul 2005 15:07:59 -  1.12
--- contrib/pgcrypto/random.c   11 Jul 2005 16:40:16 -
***
*** 126,132 
if (!res)
return dst;

!   res = CryptGenRandom(h, NUM_BYTES, dst);
if (res == TRUE)
dst += len;
  
--- 126,132 
if (!res)
return dst;

!   res = CryptGenRandom(h, RND_BYTES, dst);
if (res == TRUE)
dst += len;
  

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

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

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Tom Lane 
Marko Kreen marko@l-t.ee writes:
 Another build failure from buildfarm.  Seems like
 I forgot to update win32 code when doing a renaming
 in random.c

Applied.

regards, tom lane

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

   http://archives.postgresql.org

Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

2005-07-11 Thread Kris Jurka 

Marko Kreen wrote:


http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04

Linking problem with zlib on Solaris 9/x86.  I am clueless about
this.  I can anyone look into it?



It appears to be finding the static /usr/local/lib/libz.a instead of the 
dynamic /usr/lib/libz.so.


Kris Jurka

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly