Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Marko Kreen wrote: solaris openssl refuses to handle keys longer than 128bits. * aes will crash on longer keys * blowfish will silently cut the key which can result data corruption to fix it: - test errors from AES functions - bf errors cannot be tested, do test encryption - change aes compat macros to static function so they can return values Tested on Solaris Nevada and works fine. More general appriaches that also fix the problems are: - test all ciphers on first use and test fails then disable completely. This is nice as it could detect much braded range of errors. Problem with this approach is that its too big overhead for small gain, as it cannot still 100% guarantee that everything is working correctly. - Use EVP functions for encryption as they have better error handling. So crippled openssl can report via regular means that something is not supported. +1 for EVP solution. Thank you very much Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. Thanks. Zdenek ---(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: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Marko Kreen [EMAIL PROTECTED] writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. But I'm starting to think that the blowfish check should be #ifdef __solaris__ only. Has anyone good reasons why it should apply to everyone? As long as we've got to have the code, we may as well use it --- it's possible that Sun isn't the only vendor who got worried about the crypto export laws. Your caching of the result should be enough to ensure that the overhead is negligible. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto (v02)
There is updated version of patch. See comments bellow:
Marko Kreen wrote:
On 7/27/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
I attach pgcrypto patch which fix two problems on system without strong
crypto support (e.g. default Solaris 10 installation):
1) postgres crashes when AES cipher uses long key
2) Blowfish silently cut longer keys. It could bring problem when
crypted data are transfered from one server to another with strong keys
support.
Couple of style nitpicks:
* please use hex arrays, instead octal-quoted strings. easier on the eye.
fixed
* use memcmp() instead of for() loop.
fixed
* 16 byte bufs for 8 bytes is confusing.
I think it must be 16 because block size is 16 bytes. I'm not sure if 8
bytes could not cause buffer overflow.
This patch was discussed there:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00762.php
This patch is applicable also on 8.2, 8.1 (and maybe older) version of
postgresql.
OpenSSL autoconfiguration was added in 8.1, so patching older
versions is not that critical.
Zdenek
Index: contrib/pgcrypto/openssl.c
===
RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.30
diff -c -r1.30 openssl.c
*** contrib/pgcrypto/openssl.c 2006/10/04 00:29:46 1.30
--- contrib/pgcrypto/openssl.c 2007/08/07 10:35:24
***
*** 375,385
--- 375,424
/* Blowfish */
+ /* Check if strong crypto is supported. Some openssl installation could support only short keys
+ and unfortunatelly BF_sef_key does not return any error value. This function tests if is possible
+ use strong key.
+ */
+ static
+ int bf_check_supported_key_len()
+ {
+ static unsigned char key[] = {0xf0,0xe1,0xd2,0xc3,0xb4,0xa5,0x96,0x87,0x78,0x69,0x5a,0x4b,
+ 0x3c,0x2d,0x1e,0x0f,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,
+ 0x04,0x68,0x91,0x04,0xc2,0xfd,0x3b,0x2f,0x58,0x40,0x23,0x64,
+ 0x1a,0xba,0x61,0x76,0x1f,0x1f,0x1f,0x1f,0x0e,0x0e,0x0e,0x0e,
+ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
+
+ static unsigned char data[16] = {0xfe,0xdc,0xba,0x98,0x76,0x54,0x32,0x10};
+ static unsigned char res[] = {0xc0,0x45,0x04,0x01,0x2e,0x4e,0x1f,0x53};
+ static unsigned char out[16];
+ BF_KEY bf_key;
+ int n;
+
+ /* encrypt and th 448bits key and verify output */
+ BF_set_key(bf_key,56, key);
+ BF_ecb_encrypt( data, out, bf_key, BF_ENCRYPT);
+
+ if( memcmp(out, res, 8) != 0)
+ return 0; /* Output does not match - strong cipher is not supported */
+ return 1;
+ }
+
static int
bf_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
{
ossldata *od = c-ptr;
+ static int bf_is_strong = -1;
+
+ /* Test if key len is supported. BF_set_key silently cut large keys and it could be
+ be a problem when user transfer crypted data from one server to another. */
+
+ if( bf_is_strong == -1)
+ bf_is_strong = bf_check_supported_key_len();
+
+ if( !bf_is_strong klen16 )
+ return PXE_KEY_TOO_BIG;
+ /* Key len is supported. We can use it. */
BF_set_key(od-u.bf.key, klen, key);
if (iv)
memcpy(od-iv, iv, BF_BLOCK);
***
*** 692,705
return 0;
}
! static void
ossl_aes_key_init(ossldata * od, int type)
{
if (type == AES_ENCRYPT)
! AES_set_encrypt_key(od-key, od-klen * 8, od-u.aes_key);
else
! AES_set_decrypt_key(od-key, od-klen * 8, od-u.aes_key);
! od-init = 1;
}
static int
--- 731,755
return 0;
}
! static int
ossl_aes_key_init(ossldata * od, int type)
{
+ int err;
+ /* Strong key support could miss on some openssl installation, we must
+ check return value, from set key function.
+ */
if (type == AES_ENCRYPT)
! err = AES_set_encrypt_key(od-key, od-klen * 8, od-u.aes_key);
else
! err = AES_set_decrypt_key(od-key, od-klen * 8, od-u.aes_key);
!
! if (err == 0)
! {
! od-init = 1;
! return 0;
! }
! od-init = 0;
! return PXE_KEY_TOO_BIG;
}
static int
***
*** 709,717
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
if (!od-init)
! ossl_aes_key_init(od, AES_ENCRYPT);
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key, AES_ENCRYPT);
--- 759,769
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
+ int err;
if (!od-init)
! if( 0 != (err = ossl_aes_key_init(od, AES_ENCRYPT) ))
! return err;
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key, AES_ENCRYPT);
***
*** 725,733
unsigned bs = gen_ossl_block_size(c);
ossldata *od = c-ptr;
const uint8 *end = data + dlen - bs;
if (!od-init)
! ossl_aes_key_init(od, AES_DECRYPT);
for (; data = end; data += bs, res += bs)
AES_ecb_encrypt(data, res, od-u.aes_key,
Re: [PATCHES] pgcrypto
On 7/27/07, Zdenek Kotala [EMAIL PROTECTED] wrote: I attach pgcrypto patch which fix two problems on system without strong crypto support (e.g. default Solaris 10 installation): 1) postgres crashes when AES cipher uses long key 2) Blowfish silently cut longer keys. It could bring problem when crypted data are transfered from one server to another with strong keys support. Couple of style nitpicks: * please use hex arrays, instead octal-quoted strings. easier on the eye. * use memcmp() instead of for() loop. * 16 byte bufs for 8 bytes is confusing. This patch was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-07/msg00762.php This patch is applicable also on 8.2, 8.1 (and maybe older) version of postgresql. OpenSSL autoconfiguration was added in 8.1, so patching older versions is not that critical. -- marko ps. I looked into use of EVP, and I'm not that optimistic anymore. EVP has 3 differenct name for AES different keys, but only one for CAST5, which also supports different key lengths. Plus Blowfish is tagged as VARIABLE_LENGTH. So it seems per-algo support code cannot be avoided, which makes whole EVP usage rather pointless. The situation could be simplified by dropping encrypt()/decrypt() functions, which allow users to specify final keys. But that would be a nasty event, 8.4 is too early for that... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto merge cleanup
On Tue, 2006-07-18 at 16:06 +0300, Marko Kreen wrote: - Few README fixes - Keep imath Id string, put $PostgreSQL$ separately. Applied, thanks. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. And on 8.1 there is pgp_sym_encrypt that also does lots of resets on one context, like crypt-md5. In addition it does regular digest() in several places. So if compiled against OpenSSL, its leaking everywhere. The positive side is that only 8.1 has openssl autoconfiguration, older versions default to builtin algorithms that can be changed only by editing Makefile, thus most packages are hopefully safe. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
Marko Kreen [EMAIL PROTECTED] writes: On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. I'm confused --- does this mean that the patch you sent recently needs further work? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On 2/20/06, Tom Lane [EMAIL PROTECTED] wrote: Marko Kreen [EMAIL PROTECTED] writes: On 2/18/06, Marko Kreen [EMAIL PROTECTED] wrote: pgcrypto crypt()/md5 and hmac() leak memory when compiled against OpenSSL as openssl.c digest -reset will do two DigestInit calls against a context. This happened to work with OpenSSL 0.9.6 but not with 0.9.7+. Ugh, seems I read the old code slightly wrong. The leak happens also with regular digest(), although it will leak only 1 context instance, not the 1000+ as the crypt-md5 does. I'm confused --- does this mean that the patch you sent recently needs further work? No, it's fine. As I did not 'fix' old code but replaced it. It's just that I gave wrong answer to the question 'who is affected?' -- marko ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: fix memory leak in openssl.c
On Sat, 2006-02-18 at 02:23 +0200, Marko Kreen wrote: Attached are one patch for 7.3, 7.4, 8.0 branches and another for 8.1 and HEAD. Thanks, patches applied to the appropriate branches. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: bug in gen_salt (md5/xdes)
Marko Kreen [EMAIL PROTECTED] writes: There is a signedness bug in Openwall gen_salt code that pgcrypto uses. This makes the salt space for md5 and xdes algorithms a lot smaller. Salts for blowfish and standard des are unaffected. Attached is upstream fix for it. This applies all the way from 7.2 to 8.1 and HEAD. Please apply this to all active branches. Applied back to 7.3 ... we are not maintaining 7.2 anymore. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto doc polish
Marko Kreen marko@l-t.ee writes: Few small things: [ snip ] Applied, thanks. I also fixed a few small grammatical problems in the text. regards, tom lane ---(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
Re: [PATCHES] pgcrypto warnings for Sun's cc
Kris Jurka [EMAIL PROTECTED] writes: This patch removes a couple of warnings Sun's cc reports in contrib/pgcrypto. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto: OpenSSL/DES cleanup
Patch applied. Thanks. --- Marko Kreen wrote: As Kris Jurka found out, pgcrypto does not work with OpenSSL 0.9.6x. The DES functions use the older 'des_' API, but the newer 3DES functions use the 0.9.7x-only 'DES_' API. I think I just used /usr/include/openssl/des.h for reference when implementing them, and had upgraded OpenSSL in the meantime. Following patch converts DES also to newer API and provides compatibility functions for OpenSSL 0.9.7. I chose this route because: - openssl.c uses few DES functions. - compatibility for old 'des_' API is going away at some point of time from OpenSSL. - as seen from macros, new API is saner - Thus pgcrypto supports any OpenSSL version from 0.9.5 to 1.0 Tested with OpenSSL 0.9.6c and 0.9.7e. -- marko PS. It's nice to see that the 'autoconfiguration' already pays back. [ Attachment, skipping... ] ---(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 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgcrypto volatility and strictness changes
Michael Fuhr wrote: This patch updates the DDL for contrib/pgcrypto to create all functions as STRICT, and all functions except gen_salt() as IMMUTABLE. gen_salt() is VOLATILE. Barring any objections, I'll apply this tomorrow. -Neil ---(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: [PATCHES] pgcrypto: OpenSSL/DES cleanup
On Thu, Jul 07, 2005 at 12:25:53PM +0300, Marko Kreen wrote: Tested with OpenSSL 0.9.6c and 0.9.7e. I just applied this patch to my system running HEAD and OpenSSL 0.9.8; all regression tests passed. BTW, OpenSSL 0.9.8 has been released: http://www.mail-archive.com/openssl-announce@openssl.org/msg00063.html -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto volatility and strictness changes
Michael Fuhr wrote: This patch updates the DDL for contrib/pgcrypto to create all functions as STRICT, and all functions except gen_salt() as IMMUTABLE. gen_salt() is VOLATILE. Applied, thanks. -Neil ---(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: [PATCHES] pgcrypto: openssl digest fix
Marko Kreen wrote: Ah, ofcourse. The patch seems rather large to be applying to 7.3 and 7.2 -- but it's your contrib/ module, so I'll assume you're pretty confident this doesn't cause any regressions... I'll apply the patch to 7.3 and 7.2 stable branches tomorrow. -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pgcrypto: openssl digest fix
On Sun, Mar 13, 2005 at 09:43:02PM +1100, Neil Conway wrote: Marko Kreen wrote: Ah, ofcourse. The patch seems rather large to be applying to 7.3 and 7.2 -- but it's your contrib/ module, so I'll assume you're pretty confident this doesn't cause any regressions... The patch itself is simply cvs diff -r1.10 -r1.11 openssl.c, so there should not be any recent typos in it. Now I also tested it with both REL7_3_STABLE and REL7_2_STABLE and found no problems. So I think its fine. I'll apply the patch to 7.3 and 7.2 stable branches tomorrow. Cool. -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pgcrypto: openssl digest fix
On Sat, Mar 12, 2005 at 05:59:24PM +1100, Neil Conway wrote: Marko Kreen wrote: Please apply this also to stable branches (8.0 / 7.4). Should it be backpatched to 7.3 and 7.2 as well? It would be nice. I didn't know there are releases of those planned as well. Now looking into it, 7.3 and 7.2 branch are missing the OpenSSL EVP cipher functions removal patch - which is even more nasty as it does not crash but silently corrupts data. 'make installcheck' detects it, but if somebody forgets to run it... (Thankfully encrypt()/decrypt() are not used much.) Would you apply this one aswell? I see that the original patch (openssl.c r1.11) applies to both branches without problems. It is a bit larger than this one tho'. -- marko ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgcrypto: openssl digest fix
Marko Kreen wrote: Some builds (depends on crypto engine support?) of OpenSSL 0.9.7x have EVP_DigestFinal function which which clears all of EVP_MD_CTX. This makes pgcrypto crash in functions which re-use one digest context several times: hmac() and crypt() with md5 algorithm. Following patch fixes it by carring the digest info around EVP_DigestFinal and re-initializing cipher. Applied to HEAD, REL8_0_STABLE and REL7_4_STABLE. Thanks for the patch. Please apply this also to stable branches (8.0 / 7.4). Should it be backpatched to 7.3 and 7.2 as well? -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgcrypto: Makefile check
Neil Conway [EMAIL PROTECTED] writes: This patch makes the pgcrypto Makefile check that a recognized random source has been defined. If no such source is defined, pgcrypto will compile successfully but will be unusable. Oh? +$(error Unrecognized random source: $(random)) Doesn't look like a successful compile to me. What's worse, this would also cause maintenance operations (like make clean) to fail. (I see little point in this anyway given that the makefile defaults to random = silly further up.) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pgcrypto: Makefile check
Perhaps I wasn't clear: the *present* behavior of pgcrypto is to compile successfully but ... be unusable if an invalid random source is defined. This is prone to error. That patch changes this behavior to refuse to compile if an invalid random source has been defined. On Mon, 2004-11-22 at 10:46 -0500, Tom Lane wrote: +$(error Unrecognized random source: $(random)) Doesn't look like a successful compile to me. Right, that's the whole point. What's worse, this would also cause maintenance operations (like make clean) to fail. I don't think this is a problem (an invalid random source is effectively a misconfiguration and could only be the result of user error). But if you like I can change the patch so that we error out when attempting to compile random.c (I see little point in this anyway given that the makefile defaults to random = silly further up.) This patch was specifically motivated by a user who was confused when they edited the Makefile, compiled pgcrypto, and couldn't use it -- as it turned out the random source was defined with trailing whitespace. I think the Makefile syntax is sufficiently esoteric that some error checking would be helpful. -Neil ---(end of broadcast)--- TIP 3: 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
Re: [PATCHES] pgcrypto: Makefile check
Neil Conway [EMAIL PROTECTED] writes: Perhaps I wasn't clear: the *present* behavior of pgcrypto is to compile successfully but ... be unusable if an invalid random source is defined. This is prone to error. That patch changes this behavior to refuse to compile if an invalid random source has been defined. Ah, got it. I don't think this is a problem (an invalid random source is effectively a misconfiguration and could only be the result of user error). But if you like I can change the patch so that we error out when attempting to compile random.c Please do; I dislike makefiles that won't make clean ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] pgcrypto: Makefile check
On Mon, 2004-11-22 at 19:10 -0500, Tom Lane wrote: Please do; I dislike makefiles that won't make clean ... Attached is a revised patch. Will apply in a few hours barring any objections. -Neil # # patch contrib/pgcrypto/random.c # from [2815b119334369b864e6b39fe21832b299fd235c] #to [3c5f5c8fffc36fac3076296a3bab1a2bfdb7a20b] # --- contrib/pgcrypto/random.c +++ contrib/pgcrypto/random.c @@ -35,7 +35,7 @@ #include px.h -#ifdef RAND_DEV +#if defined(RAND_DEV) #include errno.h #include fcntl.h @@ -77,9 +77,8 @@ close(fd); return res; } -#endif /* RAND_DEV */ -#ifdef RAND_SILLY +#elif defined(RAND_SILLY) int px_get_random_bytes(uint8 *dst, unsigned count) @@ -90,9 +89,8 @@ *dst++ = random(); return i; } -#endif /* RAND_SILLY */ -#ifdef RAND_OPENSSL +#elif defined(RAND_OPENSSL) #include openssl/evp.h #include openssl/blowfish.h @@ -125,4 +123,6 @@ return -1; } +#else +#error Invalid random source +#endif -#endif /* RAND_OPENSSL */ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pgcrypto: make const array static
On Mon, 2004-10-04 at 15:23, Neil Conway wrote: This one-line patches merges a micro-opt from upstream (OpenBSD) sources: we can make a read-only local array static and reduce the size of the generated object file slightly. Patch applied. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
