Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Titus von Boxberg wrote: What do you mean by right syntax. There are hundreds of examples in programming languages where a small syntactic difference leads to totally different semantics. Well, I'm just not happy that foo.bar means something completely different than foo%bar -- foo%bar isn't even fetching something called bar from foo. Anyway, I can't see a better syntax, so I suppose this will do. Are there any general objections to implement this feature? Not from me. You missed the 8.1 freeze by about two weeks, so I'm not sure if this is a candidate for 8.1 though. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Neil Conway [EMAIL PROTECTED] writes: Not from me. You missed the 8.1 freeze by about two weeks, so I'm not sure if this is a candidate for 8.1 though. Not a chance. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
-Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED] Neil Conway [EMAIL PROTECTED] writes: Not from me. You missed the 8.1 freeze by about two weeks, so I'm not sure if this is a candidate for 8.1 though. Not a chance. regards, tom lane I'd like to participate in postgresql development on a time to time basis as I continue using it and as my knowledge (hopefully) grows. Having read the FAQ, it's not clear to me, where the patches go (and when) that I would send into this list. These are my open questions: Are the patches applied to HEAD? And only Very Important Patches are merged to the current or even an older release branch? Main background questions are: What else (besides creating and testing the patch myself) can I do to alleviate applying (or deciding to apply) the patches? Could I expect (and if so in what time frame) the patches to appear in HEAD? So at some time I would find my code in a cvs up? How do I know that? Thanks for answering newbie questions. Regards Titus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Titus von Boxberg wrote: Having read the FAQ, it's not clear to me, where the patches go (and when) that I would send into this list. These are my open questions: Are the patches applied to HEAD? It depends on the patch. New features are almost exclusively only applied to HEAD, whereas patches that fix bugs (with a low chance of introducing additional regressions) or fix typos in the documentation are applied to back branches. And only Very Important Patches are merged to the current or even an older release branch? Right. Main background questions are: What else (besides creating and testing the patch myself) can I do to alleviate applying (or deciding to apply) the patches? Could I expect (and if so in what time frame) the patches to appear in HEAD? So at some time I would find my code in a cvs up? Assuming the patch is accepted, it will eventually be reviewed and applied by one of the committers. The time frame for doing that depends on various factors: the size and complexity of the patch, the amount of review / fixing it needs, the workload of the committers, and the current stage of the release cycle (we just passed feature freeze for 8.1, so I think most committers are busy with work for the upcoming 8.1 beta release). Unfortunately we can be a bit tardy in applying patches at times, IMHO. How do I know that? It is standard practice to send email to patch submitters when their patch has been applied (or alternatively rejected, or a resubmission of the patch has been requested). You can also read the pgsql-committers mailing list, which logs all the CVS commits. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] fixing REL7_3_STABLE build issues
The attached (new) src/test/regress/expected/geometry_9.out, intended only for the 7.3 stable branch, allows a clean regression pass on my FC4 box. I called it that to avoid conflicts with other geometry_n files on later branches. The attached patch for contrib/seg/segparse.y allows a clean 7.3 contrib build. The latter fix looks like one that should be made on the 7.4 branch also - man 3 errno on my box says: errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. I'm not sure why 7.4 doesn't choke at the same place, but doing the Right Thing (tm) should not hurt. In later branches the declaration is gone altogether, so the problem has disappeared. cheers andrew -- -- GEOMETRY -- -- -- Points -- SELECT '' AS four, center(f1) AS center FROM BOX_TBL; four | center --+- | (1,1) | (2,2) | (2.5,3) | (3,3) (4 rows) SELECT '' AS four, (@@ f1) AS center FROM BOX_TBL; four | center --+- | (1,1) | (2,2) | (2.5,3) | (3,3) (4 rows) SELECT '' AS six, point(f1) AS center FROM CIRCLE_TBL; six | center -+--- | (0,0) | (1,2) | (1,3) | (1,2) | (100,200) | (100,0) (6 rows) SELECT '' AS six, (@@ f1) AS center FROM CIRCLE_TBL; six | center -+--- | (0,0) | (1,2) | (1,3) | (1,2) | (100,200) | (100,0) (6 rows) SELECT '' AS two, (@@ f1) AS center FROM POLYGON_TBL WHERE (# f1) 2; two | center -+- | (1.33,1.33) | (2.33,1.33) (2 rows) -- is horizontal function SELECT '' AS two, p1.f1 FROM POINT_TBL p1 WHERE ishorizontal(p1.f1, point '(0,0)'); two | f1 -+- | (0,0) | (-10,0) (2 rows) -- is horizontal operator SELECT '' AS two, p1.f1 FROM POINT_TBL p1 WHERE p1.f1 ?- point '(0,0)'; two | f1 -+- | (0,0) | (-10,0) (2 rows) -- is vertical function SELECT '' AS one, p1.f1 FROM POINT_TBL p1 WHERE isvertical(p1.f1, point '(5.1,34.5)'); one | f1 -+ | (5.1,34.5) (1 row) -- is vertical operator SELECT '' AS one, p1.f1 FROM POINT_TBL p1 WHERE p1.f1 ?| point '(5.1,34.5)'; one | f1 -+ | (5.1,34.5) (1 row) -- -- Line segments -- -- intersection SELECT '' AS count, p.f1, l.s, l.s # p.f1 AS intersection FROM LSEG_TBL l, POINT_TBL p; ERROR: Unable to identify an operator '#' for types 'lseg' and 'point' You will have to retype this query using an explicit cast -- closest point SELECT '' AS thirty, p.f1, l.s, p.f1 ## l.s AS closest FROM LSEG_TBL l, POINT_TBL p; thirty | f1 | s |closest ++---+--- | (0,0) | [(1,2),(3,4)] | (1,2) | (-10,0)| [(1,2),(3,4)] | (1,2) | (-3,4) | [(1,2),(3,4)] | (1,2) | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) | (-5,-12) | [(0,0),(6,6)] | (0,0) | (10,10)| [(0,0),(6,6)] | (6,6) | (0,0) | [(10,-10),(-3,-4)]| (-2.04878048780488,-4.4390243902439) | (-10,0)| [(10,-10),(-3,-4)]| (-3,-4) | (-3,4) | [(10,-10),(-3,-4)]| (-3,-4) | (5.1,34.5) | [(10,-10),(-3,-4)]| (-3,-4) | (-5,-12) | [(10,-10),(-3,-4)]| (-1.60487804878049,-4.64390243902439) | (10,10)| [(10,-10),(-3,-4)]| (2.39024390243902,-6.48780487804878) | (0,0) | [(-100,200),(30,-40)] | (0.0028402365895872,15.384614860264) | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140472) | (-3,4) | [(-100,200),(30,-40)] | (-2.99789812267519,15.3851688427303) | (5.1,34.5) | [(-100,200),(30,-40)] | (5.09647083221496,15.3836744976925) | (-5,-12) | [(-100,200),(30,-40)] | (-4.99494420845634,15.3855375281616) | (10,10)| [(-100,200),(30,-40)] | (10.000993741978,15.3827690473092) | (0,0) | [(11,22),(33,44)] | (11,22) | (-10,0)| [(11,22),(33,44)] | (11,22) | (-3,4) | [(11,22),(33,44)] | (11,22) |
[PATCHES] AIX FAQ Updates
I believe this change will apply equally to 7.4, 8.0, and CVS HEAD.
Index: FAQ_AIX
===
RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v
retrieving revision 1.11
diff -c -u -r1.11 FAQ_AIX
--- FAQ_AIX 12 Nov 2002 20:02:32 - 1.11
+++ FAQ_AIX 15 Jul 2005 15:51:10 -
@@ -18,3 +18,79 @@
You need libm.a that is in the fileset bos.adt.libm. (Try the
following command.)
$ lslpp -l bos.adt.libm
+
+
+---
+From: Christopher Browne [EMAIL PROTECTED]
+Date: 2005-07-15
+
+On AIX 5.3, there have been some problems getting PostgreSQL to
+compile and run using GCC.
+
+1. You will want to use a version of GCC subsequent to 3.3.2,
+particularly if you use a prepackaged version. We had good
+success with 4.0.1.
+
+Problems with earlier versions seem to have more to do with the
+way IBM packaged GCC than with actual issues with GCC, so that if
+you compile GCC yourself, you might well have success with an
+earlier version of GCC.
+
+2. AIX 5.3 has a problem where sockadr_storage is not defined to be
+large enough. In version 5.3, IBM increased the size of
+sockaddr_un, the address structure for UNIX Domain Sockets, but
+did not correspondingly increase the size of sockadr_storage.
+
+The result of this is that attempts to use UDS with PostgreSQL
+lead to libpq overflowing the data structure. TCP/IP connections
+work OK, but not UDS, which prevents the regression tests from
+working.
+
+ The nonconformance may be readily demonstrated by compiling and
+ running the following C program which calculates and compares the
+ sizes of the various structures:
+
+test_size.c
+
+
+-- snip here - test_size.c
+#include stdio.h
+#include sys/un.h
+#include sys/socket.h
+int main (int argc, char *argv[]) {
+struct sockaddr_storage a;
+struct sockaddr_un b;
+printf(Size of sockadr_storage: %d\n, sizeof(a));
+printf (Size of sockaddr_un:%d\n, sizeof(b));
+
+if (sizeof(a) = sizeof(b))
+printf (Conformant to RFC 3493\n);
+else
+printf (Non-conformant to RFC 3493\n);
+}
+-- snip here - test_size.c
+
+
+The problem was reported to IBM, and is recorded as bug report
+PMR29657.
+
+An immediate resolution is to alter _SS_MAXSIZE to = 1025 in
+/usr/include/sys/socket.h, which will resolve the immediate problem.
+
+It appears that the final resolution will be to alter _SS_MAXSIZE to
+1280, making the size nicely align with page boundaries.
+
+IBM will be providing a fix in the next maintenance release (expected
+in October 2005) with an updated socket.h.
+---
+From: Christopher Browne [EMAIL PROTECTED]
+Date: 2005-07-15
+
+Some of the AIX tools may be a little different from what you may be
+accustomed to on other platforms. If you are looking for a version of
+ldd, useful for determining what object code depends on what
+libraries, the following URLs may help you...
+
+http://www.faqs.org/faqs/aix-faq/part4/section-22.html
+
+http://www.han.de/~jum/aix/ldd.c
\ No newline at end of file
--
(format nil [EMAIL PROTECTED] cbbrowne acm.org)
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. I will not tell my Legions of Terror
And he must be taken alive! The command will be: ``And try to take
him alive if it is reasonably practical.''
http://www.eviloverlord.com/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] thousands comma numeric formatting in psql
Eugen Nedelcu wrote: The new code is broken. Please test it with resonably large tables. Do not test it with querys like: select -132323435.34343; If I use a query like: select * from my_table limit 100; I can't see anything on my screen until I hit CTRL^C If I use a pager (\pset pager less) strange things happened: I can't see anything on my screen, hit CTRL^C, then quit psql, reset xterm, then less is still running and eat lots of memory and cpu. I did: SELECT random() * 10 INTO test FROM generate_series(1,10); \pset numericsep SELECT * FROM test; and it seemed to work fine. Did you do a complete rebuild/install? -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Change Ownership Permission Checks
* Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Attached please find a patch to change how the permissions checking for alter-owner is done. With roles there can be more than one 'owner' of an object and therefore it becomes sensible to allow specific cases of ownership change for non-superusers. Applied with minor revisions. The patch as submitted suffered a certain amount of copy-and-paste-itis (eg, trying to use pg_type_ownercheck on an opclass), and I really disliked using ACLCHECK_NOT_OWNER as the way to report you can't assign ownership to that role because you are not a member of it. So I made a separate error message for that case. Great, thanks! Sorry about the copy-and-paste-itis... Must have been a case I wasn't sure about. The different error message makes perfect sense. I see you also did the superuser-in-every-role change that I had included, thanks. When writing this patch it occurred to me that we nuke our member-of-role cache for one-off lookups on occation. I don't particularly like that, especially when we *know* it's a one-off lookup, so I was considering adding a function for the one-off lookup case but I couldn't come up with a way to avoid a fair bit of mostly-the-same code as the current cache-regen code, without making the cache-regen code alot slower which would negate the point. Just some thoughts. Thanks again, Stephen signature.asc Description: Digital signature
Re: [PATCHES] Change Ownership Permission Checks
Stephen Frost [EMAIL PROTECTED] writes: When writing this patch it occurred to me that we nuke our member-of-role cache for one-off lookups on occation. I don't particularly like that, especially when we *know* it's a one-off lookup, Yeah. What I had been thinking about is that maybe it shouldn't be just a one-element cache. At the moment though we have no performance data to justify complicating matters (heck, not even any to prove we need a cache at all...) It'd be smart to try to profile some realistic cases before spending any time coding. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] [patch 0/3] last large update to pgcrypto
Those 3 patches hopefully end my pgcrypto patch-bombing. (Well, at least I am offline next couple weeks...) 1. Small fixes 2. Fortuna fixes 3. New README There are 3 important points about new readme: * It is formatted for use by asciidoc. To be able to generate html from it. As I consider the text version to be main target, I tried to as few formatting cruft as possible. Here are both versions online: http://grue.l-t.ee/~marko/src/pgcrypto/README.html http://grue.l-t.ee/~marko/src/pgcrypto/README.txt * I've seen people suggest to use MD5 for passwords. Now there is special section which compares crypt algorithms to md5 and sha1. * I announce the removal of (digest/cipher/hmac)_exists functions in 8.2. Reason for it is that they are useless: - The informational question can be answered by calling the main function and looking for error. - They are useless for user programs, as you cannot replace one algorithm with another on the run - missing algorithm will be always hard error. - The question 'does it exists' even should not be asked, user should rather use algorithms that are _always_ there. The situation would be different for functions that would return a _list_ of supported algorithms. But I doubt even the usefulness of such functions. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] [patch 1/3] small cleanups
- Fix couple comments.
- internal.c didnt clean hash contexts when freeing
- zero the system randomness buffer too
- Google tells that we can use /dev/urandom on Cygwin,
HPUX and AIX. Add them to random.c
- remove a debug reference from pgp.h
Index: pgsql/contrib/pgcrypto/fortuna.c
===
*** pgsql.orig/contrib/pgcrypto/fortuna.c
--- pgsql/contrib/pgcrypto/fortuna.c
*** static void init_state(FState *st)
*** 174,181
}
/*
! * Must not reseed more ofter than RESEED_PER_SEC
! * times per second.
*/
static int too_often(FState *st)
{
--- 174,181
}
/*
! * The time between reseed must be at least RESEED_INTERVAL
! * microseconds.
*/
static int too_often(FState *st)
{
*** static void reseed(FState *st)
*** 241,247
memset(key_md, 0, sizeof(key_md));
memset(buf, 0, BLOCK);
- n = k = 0;
}
/*
--- 241,246
Index: pgsql/contrib/pgcrypto/internal.c
===
*** pgsql.orig/contrib/pgcrypto/internal.c
--- pgsql/contrib/pgcrypto/internal.c
*** int_md5_free(PX_MD * h)
*** 127,132
--- 127,133
{
MD5_CTX*ctx = (MD5_CTX *) h-p.ptr;
+ memset(ctx, 0, sizeof(*ctx));
px_free(ctx);
px_free(h);
}
*** int_sha1_free(PX_MD * h)
*** 174,179
--- 175,181
{
SHA1_CTX *ctx = (SHA1_CTX *) h-p.ptr;
+ memset(ctx, 0, sizeof(*ctx));
px_free(ctx);
px_free(h);
}
*** int_sha256_free(PX_MD * h)
*** 221,226
--- 223,229
{
SHA256_CTX *ctx = (SHA256_CTX *) h-p.ptr;
+ memset(ctx, 0, sizeof(*ctx));
px_free(ctx);
px_free(h);
}
*** int_sha384_free(PX_MD * h)
*** 267,272
--- 270,276
{
SHA384_CTX *ctx = (SHA384_CTX *) h-p.ptr;
+ memset(ctx, 0, sizeof(*ctx));
px_free(ctx);
px_free(h);
}
*** int_sha512_free(PX_MD * h)
*** 314,319
--- 318,324
{
SHA512_CTX *ctx = (SHA512_CTX *) h-p.ptr;
+ memset(ctx, 0, sizeof(*ctx));
px_free(ctx);
px_free(h);
}
*** init_md5(PX_MD * md)
*** 326,331
--- 331,337
MD5_CTX*ctx;
ctx = px_alloc(sizeof(*ctx));
+ memset(ctx, 0, sizeof(*ctx));
md-p.ptr = ctx;
*** init_sha1(PX_MD * md)
*** 345,350
--- 351,357
SHA1_CTX *ctx;
ctx = px_alloc(sizeof(*ctx));
+ memset(ctx, 0, sizeof(*ctx));
md-p.ptr = ctx;
*** init_sha256(PX_MD * md)
*** 364,369
--- 371,377
SHA256_CTX *ctx;
ctx = px_alloc(sizeof(*ctx));
+ memset(ctx, 0, sizeof(*ctx));
md-p.ptr = ctx;
*** init_sha384(PX_MD * md)
*** 383,388
--- 391,397
SHA384_CTX *ctx;
ctx = px_alloc(sizeof(*ctx));
+ memset(ctx, 0, sizeof(*ctx));
md-p.ptr = ctx;
*** init_sha512(PX_MD * md)
*** 402,407
--- 411,417
SHA512_CTX *ctx;
ctx = px_alloc(sizeof(*ctx));
+ memset(ctx, 0, sizeof(*ctx));
md-p.ptr = ctx;
*** static void system_reseed(void)
*** 829,834
--- 839,845
fortuna_add_entropy(SYSTEM_ENTROPY, buf, n);
seed_time = t;
+ memset(buf, 0, sizeof(buf));
}
int
Index: pgsql/contrib/pgcrypto/pgp-compress.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-compress.c
--- pgsql/contrib/pgcrypto/pgp-compress.c
*** restart:
*** 270,276
dec-stream.avail_out = dec-buf_len;
dec-pos = dec-buf;
! // Z_NO_FLUSH, Z_SYNC_FLUSH,
flush = dec-stream.avail_in ? Z_SYNC_FLUSH : Z_FINISH;
res = inflate(dec-stream, flush);
if (res != Z_OK res != Z_STREAM_END)
--- 270,280
dec-stream.avail_out = dec-buf_len;
dec-pos = dec-buf;
! /*
!* Z_SYNC_FLUSH is tell zlib to output as much as possible.
!* It should do in anyway (Z_NO_FLUSH), but seems to reserve
!* the right not to. So lets follow the API.
!*/
flush = dec-stream.avail_in ? Z_SYNC_FLUSH : Z_FINISH;
res = inflate(dec-stream, flush);
if (res != Z_OK res != Z_STREAM_END)
Index: pgsql/contrib/pgcrypto/pgp-decrypt.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-decrypt.c
--- pgsql/contrib/pgcrypto/pgp-decrypt.c
*** static void mdc_free(void *priv)
*** 339,345
ctx-mdc_ctx = NULL;
}
- // fixme: clarify
static int mdc_finish(PGP_Context *ctx, PullFilter *src,
int len, uint8 **data_p)
{
--- 339,344
*** static int mdc_finish(PGP_Context *ctx,
*** 364,369
[PATCHES] [patch 3/3] new documentation
- reformat in asciidoc syntax
- clarify various parts
- add high-level description of PGP structure
- add a comparison of crypt vs. regular hashes
Index: pgsql/contrib/pgcrypto/README.pgcrypto
===
*** pgsql.orig/contrib/pgcrypto/README.pgcrypto
--- pgsql/contrib/pgcrypto/README.pgcrypto
***
*** 1,362
! pgcrypto 0.4 - cryptographic functions for PostgreSQL.
! ==
! by Marko Kreen marko@l-t.ee
! INSTALLATION
!
! Edit makefile, if you want to use any external library.
! NB! Default randomness source is libc random() function. This
! is so only to get pgcrypto build everywhere. Randomness is
! needed for gen_salt() and pgp_encrypt() functions. So if you plan
! using those, you should definitely change that by editing Makefile.
! You can should use urandom device if your OS supports it, otherwise
! link pgcrypto against OpenSSL library and use its PRNG.
! After editing Makefile:
- make
- make install
! To run regression tests, install both PostgreSQL and pgcrypto
! and then run
! make installcheck
! SQL FUNCTIONS
! =
! If any of arguments are NULL they return NULL.
! digest(data::bytea, type::text)::bytea
! Type is here the algorithm to use. E.g. 'md5', 'sha1', ...
! Returns binary hash.
! digest_exists(type::text)::bool
! Returns BOOL whether given hash exists.
! hmac(data::bytea, key::bytea, type::text)::bytea
- Calculates Hashed MAC over data. type is the same as
- in digest(). Returns binary hash. Similar to digest()
- but noone can alter data and re-calculate hash without
- knowing key. If the key is larger than hash blocksize
- it will first hashed and the hash will be used as key.
-
- [ HMAC is described in RFC2104. ]
! hmac_exists(type::text)::bool
! Returns BOOL. It is separate function because all hashes
! cannot be used in HMAC.
! crypt(password::text, salt::text)::text
- Calculates UN*X crypt(3) style hash. Useful for storing
- passwords. For generating salt you should use the
- gen_salt() function. Usage:
! New password:
!
! UPDATE .. SET pswhash = crypt(new_psw, gen_salt('md5'));
!
! Authentication:
! SELECT pswhash = crypt(given_psw, pswhash) WHERE .. ;
!
! returns BOOL whether the given_psw is correct. DES crypt
! has max key of 8 bytes, MD5 has max key at least 2^32-1
! bytes but may be larger on some platforms...
- Builtin crypt() supports DES, Extended DES, MD5 and Blowfish
- (variant 2a) algorithms.
! gen_salt(type::text)::text
! Generates a new random salt for usage in crypt(). Type
!
! 'des' - Old UNIX, not recommended
! 'md5' - md5-based crypt()
! 'xdes' - 'Extended DES'
! 'bf'- Blowfish-based, variant 2a
! When you use --enable-system-crypt then note that system
! libcrypt may not support them all.
! gen_salt(type::text, rounds::int4)::text
- same as above, but lets user specify iteration count
- for algorithm. Number is algorithm specific:
! typedefault min max
! -
! xdes725 1 16777215
! bf 6 4 31
! In case of xdes there is a additional limitation that the
! count must be a odd number.
! The higher the count, the more time it takes to calculate
! crypt and therefore the more time to break it. But beware!
! With too high count it takes a _very_long_ time to
! calculate it.
! For maximum security, you should choose the 'bf' crypt
! and use maximum number of rounds you can still tolerate.
! armor(bytea)::text
! dearmor(text)::bytea
! Those wrap/unwrap data into PGP Ascii Armor which
! is basically Base64 with CRC and additional formatting.
! pgp_sym_encrypt(data::text, key::text)::bytea
! pgp_sym_encrypt(data::text, key::text, arg::text)::bytea
! pgp_sym_encrypt_bytea(data::bytea, key::text)::bytea
! pgp_sym_encrypt_bytea(data::bytea, key::text, arg::text)::bytea
- pgp_sym_decrypt(data::bytea, key::text)::text
- pgp_sym_decrypt(data::bytea, key::text, arg::text)::text
- pgp_sym_decrypt_bytea(data::text, key::text)::bytea
- pgp_sym_decrypt_bytea(data::text, key::text, arg::text)::bytea
! Encrypt data into OpenPGP Symmetrically Encrypted Data
! message. And decrypt it from it.
! Note that the pgp_sym_encrypt_bytea functions tag the data
! as binary, as the pgp_sym_encrypt will tag the data as text.
! You can not decrypt the binary data as text. But you can
! decrypt text data as binary. This rule avoids having
! broken textual data in PostgreSQL.
! Both encrypt
[PATCHES] [patch 2/3] Fortuna fixes
After studying Fortuna more, I found out that I missed
some of the details.
- reseeding should happen only if pool #0 has aquired additional
entropy.
- a 'rekeying' operation should happend after each request and
also after 1M of extracted data. That means taking next two
blocks and using it as new key.
- Fortuna _really_ wants entropy sources to be somewhat unpredictible.
So roll dice when adding it and also add them to pools randomly,
not sequentially.
This hopefully makes harder for someone to doctor with the
internal state (as in our case user can directly control
what goes into it).
That also drops the idea of several sources - which really
fits more to hardware backed event sources.
- add a really obvious obfuscation: take the absolutely first
block be initial counter value. If Fortuna (AES to be exact)
is secure with known counter value, then it should be also
secure with unknown counter value. This does not go against
the important property of counter - that the bit-pattern repeat
period should be as long as possible.
- S2K functions should use px_get_pseudo_random_bytes not
px_get_random_bytes.
Index: pgsql/contrib/pgcrypto/fortuna.c
===
*** pgsql.orig/contrib/pgcrypto/fortuna.c
--- pgsql/contrib/pgcrypto/fortuna.c
***
*** 94,107
/* for one big request, reseed after this many bytes */
#define RESEED_BYTES (1024*1024)
/*
* Algorithm constants
*/
- /* max sources */
- #define MAX_SOURCES 8
-
/* Both cipher key size and hash result size */
#define BLOCK 32
--- 94,109
/* for one big request, reseed after this many bytes */
#define RESEED_BYTES (1024*1024)
+ /*
+ * Skip reseed if pool 0 has less than this many
+ * bytes added since last reseed.
+ */
+ #define POOL0_FILL(256/8)
/*
* Algorithm constants
*/
/* Both cipher key size and hash result size */
#define BLOCK 32
*** struct fortuna_state {
*** 118,126
uint8 key[BLOCK];
MD_CTX pool[NUM_POOLS];
CIPH_CTXciph;
- unsignedsource_pos[MAX_SOURCES];
unsignedreseed_count;
struct timeval last_reseed_time;
};
typedef struct fortuna_state FState;
--- 120,130
uint8 key[BLOCK];
MD_CTX pool[NUM_POOLS];
CIPH_CTXciph;
unsignedreseed_count;
struct timeval last_reseed_time;
+ unsignedpool0_bytes;
+ unsignedrnd_pos;
+ int counter_init;
};
typedef struct fortuna_state FState;
*** static void md_result(MD_CTX *ctx, uint8
*** 161,167
memset(tmp, 0, sizeof(tmp));
}
-
/*
* initialize state
*/
--- 165,170
*** static void init_state(FState *st)
*** 174,179
--- 177,208
}
/*
+ * Endianess does not matter.
+ * It just needs to change without repeating.
+ */
+ static void inc_counter(FState *st)
+ {
+ uint32 *val = (uint32*)st-counter;
+ if (++val[0])
+ return;
+ if (++val[1])
+ return;
+ if (++val[2])
+ return;
+ ++val[3];
+ }
+
+ /*
+ * This is called 'cipher in counter mode'.
+ */
+ static void encrypt_counter(FState *st, uint8 *dst)
+ {
+ ciph_encrypt(st-ciph, st-counter, dst);
+ inc_counter(st);
+ }
+
+
+ /*
* The time between reseed must be at least RESEED_INTERVAL
* microseconds.
*/
*** static void reseed(FState *st)
*** 207,215
MD_CTX key_md;
uint8 buf[BLOCK];
! /* check frequency */
! if (too_often(st))
! return;
/*
* Both #0 and #1 reseed would use only pool 0.
--- 236,243
MD_CTX key_md;
uint8 buf[BLOCK];
! /* set pool as empty */
! st-pool0_bytes = 0;
/*
* Both #0 and #1 reseed would use only pool 0.
*** static void reseed(FState *st)
*** 244,292
}
/*
* update pools
*/
! static void add_entropy(FState *st, unsigned src_id, const uint8 *data,
unsigned len)
{
unsigned pos;
uint8 hash[BLOCK];
MD_CTX md;
- /* just in case there's a bug somewhere */
- if (src_id = MAX_SOURCES)
- src_id = USER_ENTROPY;
-
/* hash given data */
md_init(md);
md_update(md, data, len);
md_result(md, hash);
! /* update pools round-robin manner */
! pos = st-source_pos[src_id];
md_update( st-pool[pos], hash, BLOCK);
! if (++pos = NUM_POOLS)
! pos = 0;
! st-source_pos[src_id] = pos;
memset(hash, 0, BLOCK);
Re: [PATCHES] backslashes in pgindent
Bruce,
I found that parentheses in gawk regular expressions require backslashes
so they are not treated as regex groupings:
$ echo '('|awk '$0 ~ /(/ {print $0}'
awk: cmd. line:1: fatal: Unmatched ( or \(: /(/
$ echo '('|awk '$0 ~ /\(/ {print $0}'
(
Now, it seems closing parentheses are OK because there is no open group,
but I think I should use backslashes there too:
$ echo ')'|awk '$0 ~ /)/ {print $0}'
)
$ echo ')'|awk '$0 ~ /\)/ {print $0}'
Does your awk produce different results? What version is it? Mine is GNU Awk
3.0.6.
Yes - on the last test, mine emits the ) and yours apparently does not.
The version I ran with is 3.1.4.
The escaped parenthesis in the unpatched pgindent causes the following
warning:
$ pgindent test.c
Hope you installed /src/tools/pgindent/indent.bsd.patch.
awk: cmd. line:12: warning: escape sequence `\)' treated as plain `)'
Which implies an unnecessary escaping, which appears to function correctly
without the escape.
Cheers,
- Luke
---(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] backslashes in pgindent
Luke Lonergan wrote:
Bruce,
I found that parentheses in gawk regular expressions require backslashes
so they are not treated as regex groupings:
$ echo '('|awk '$0 ~ /(/ {print $0}'
awk: cmd. line:1: fatal: Unmatched ( or \(: /(/
$ echo '('|awk '$0 ~ /\(/ {print $0}'
(
Now, it seems closing parentheses are OK because there is no open group,
but I think I should use backslashes there too:
$ echo ')'|awk '$0 ~ /)/ {print $0}'
)
$ echo ')'|awk '$0 ~ /\)/ {print $0}'
Does your awk produce different results? What version is it? Mine is GNU
Awk
3.0.6.
Yes - on the last test, mine emits the ) and yours apparently does not.
The version I ran with is 3.1.4.
Actually, mine returns ')' too for the last command. I didn't copy
that into the email. How about the top tests? Notice I get an error on
the first one without the backslash. Are you OK escaping '(' but not
')'? That might be a solution.
The escaped parenthesis in the unpatched pgindent causes the following
warning:
$ pgindent test.c
Hope you installed /src/tools/pgindent/indent.bsd.patch.
awk: cmd. line:12: warning: escape sequence `\)' treated as plain `)'
Which implies an unnecessary escaping, which appears to function correctly
without the escape.
Cheers,
- Luke
--
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 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] backslashes in pgindent
Bruce,
On 7/15/05 9:59 PM, Bruce Momjian pgman@candle.pha.pa.us wrote:
Actually, mine returns ')' too for the last command. I didn't copy
that into the email. How about the top tests? Notice I get an error on
the first one without the backslash. Are you OK escaping '(' but not
')'? That might be a solution.
You know, I'm not sure - I don't know the intended meaning of this line:
awk ' BEGIN {line1 = ; line2 = }
{
line2 = $0;
if (NR = 2)
print line1;
if (NR = 2
line2 ~ ^{[]*$
line1 !~ ^struct
line1 !~ ^enum
line1 !~ ^typedef
line1 !~ ^extern[ ][ ]*\C\
line1 !~ =
= line1 ~ \))
print int pgindent_func_no_var_fix;;
line1 = line2;
}
END
Is the escaped paren within meant to be a literal?
- Luke
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
