I recently changed locale in my machine and PostgreSQL build broke.
The reason is that Gen_fmgrtab.sh uses [^A-Z] expression to sed
and the GNU people in their infinite wisdom made that locale-dependant.
As the script uses the complicated pipeline only for fmgroids.h -> FMGROIDS_H
conversion, it
On 9/5/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, the line of code is
> cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`
> so it ought to be pretty obvious what the correct solution fo
Oct 2006 15:24:56 - 1.473
--- doc/src/sgml/release.sgml 16 Oct 2006 13:52:35 -
***
*** 2314,2319
--- 2314,2349
pgcrypto now has all planned functionality (Marko Kreen)
+
+
+
+ Include iMath library in
On 1/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
This patch fixes vcbuild so you can build without OpenSSL and libz
should you want to. This disables the sslinfo and pgcrypto modules
because they require the libraries to build at all.
Both openssl and zlib are optional for pgcrypto. Pleas
On 1/14/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
Is there any reason why the check is "backwards" in pgcrypto compared to
the rest of the system? All the other places check for HAVE_ZLIB from
what I can tell.
Eh, just an oversight from my part. I was so focused on Makefile
hacking so I f
Let's be decent.
--
marko
pg13.diff
Description: Binary data
---(end of broadcast)---
TIP 6: explain analyze is your friend
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Currently PgPool solves the situation by parsing all queries
and keeping l
On 3/27/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Marko Kreen wrote:
>> When pooling connections where prepared statements are in use,
>> it is hard to give new client totally clean connection as
>> there may be allo
On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Neil Conway escribió:
> As to the implementation, calling hash_remove() in a loop seems a pretty
> unfortunate way to clear a hash table -- adding a hash_reset() function
> to the dynahash API would be cleaner and faster.
I wonder why hash_d
This is draft version, for discussion.
New commands:
CLOSE ALL
DEALLOCATE ALL
RESET PLANS
RESET TEMPS-- please suggest better name
RESET SESSION
So in the end RESET SESSION basically executes following commands:
ABORT;
DEALLOCATE ALL;
CLOSE ALL;
RESET ALL;
SET SESSION AUTHORIZATIO
On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
If by destruction you mean something different than pfree, then maybe
hash_remove in a loop is the best solution, the other idea being passing
a function pointer to hash_destroy_deep to call on each element, which
is probably too messy an API.
New commands:
CLOSE ALL -- close all cursors
DEALLOCATE ALL -- close all prepared stmts
RESET PLANS-- drop all plans
RESET TEMP | TEMPORARY -- drop all temp tables
RESET SESSION -- drop/close/free everything
So in
Changes in v3:
* DEALLOCATE PREPARE ALL
* RESET PLANS wont check for ACL_CREATE_TEMP anymore.
* Add prepare.h and portal.h to guc.c.
On 4/7/07, Neil Conway <[EMAIL PROTECTED]> wrote:
> * RESET SESSION does not ABORT anymore, instead fails if in transaction.
I think it's quite bizarre to hav
On 4/12/07, Neil Conway <[EMAIL PROTECTED]> wrote:
On Sun, 2007-04-08 at 11:08 +0300, Marko Kreen wrote:
> I think implicit ABORT would annoy various tools that
> partially parse user sql and expect to know what transaction
> state currently is. For them a new tranaction co
On 6/29/07, Jacob Rief <[EMAIL PROTECTED]> wrote:
On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
> Sure, but we don't break them just on a whim. The bottom line here is
> whether we are going to make a real commitment to making C++ usable as
> a backend extension language --- and for the rea
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 proble
On 8/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ken Colson" <[EMAIL PROTECTED]> writes:
> > this statement:
> > select decrypt(''::bytea,'password','bf')
> > causes the postgresql backend to crash:
> > This seems to be a 64bit problem.
>
> Reproduced here in HEAD. The problem is here:
> 293
On 9/3/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Florian G. Pflug wrote:
> > Since we didn't really reach an agreement on how xid_age should behave,
> > I've reverted it back to the original version. So with this patch,
> > xid_age will just force assignment of a xid.
>
> Is this really a goo
On 9/3/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Marko Kreen escribió:
> > On 9/3/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > Florian G. Pflug wrote:
> > > > Since we didn't really reach an agreement on how xid_age should behave,
> &
o pgp_mpi_free: Accept NULLs
o pgp_mpi_cksum: result should be 16bit
o Remove function name from error messages - to be similar to other
SQL functions, and it does not match anyway the called function
o remove couple junk lines
Index: pgsql/contrib/pgcrypto/pgp-mpi.c
=
I was bit hasty making the random exponent 'k' a prime. Further researh
shows that Elgamal encryption has no specific needs in respect to k,
any random number is fine.
It is bit different for signing, there it needs to be 'relatively prime'
to p - 1, that means GCD(k, p-1) == 1, which is also a
o Tom stuck a CVS id into file. I doubt the usefulness of it,
but if it needs to be in the file then rather at the end.
Also tag it as comment for asciidoc.
o Mention bytea vs. text difference
o Couple clarifications
Index: pgsql/contrib/pgcrypto/README.pgcrypto
The SHLIB section was copy-pasted from somewhere and contains
several unnecessary libs. This cleans it up a bit.
-lcrypt
we don't use system crypt()
-lssl, -lssleay32
no SSL here
-lz in win32 section
already added on previous line
-ldes
The chance anybody has it is pretty low.
Here are couple of small and one large patch for pgcrypto.
The large one adds support for RSA keys and reorganizes
the pubkey functions a bit. The actual RSA-specific code
there is tiny, most of the patch consists of reorg of the
pubkey code, as lots of it was written as elgamal-only.
--
marko
o Support for RSA encryption
o Big reorg to better separate generic and algorithm-specific code.
o Regression tests for RSA.
Index: pgsql/contrib/pgcrypto/pgp-mpi-openssl.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-mpi-openssl.c
---
There is a choice whether to update it with pgp functions or
remove it. I decided to remove it, updating is pointless.
I've tried to keep the core of pgcrypto relatively independent
from main PostgreSQL, to make it easy to use externally if needed,
and that is good. Eg. that made development of
It is already disabled in Makefile, remove code too.
Index: pgsql/contrib/pgcrypto/px-crypt.c
===
*** pgsql.orig/contrib/pgcrypto/px-crypt.c
--- pgsql/contrib/pgcrypto/px-crypt.c
***
*** 35,42
#include "px-crypt.h"
On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote:
> Thanks. All seven applied.
Good, but you missed one step: 'cvs remove API'
--
marko
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Sat, Aug 13, 2005 at 11:12:18AM -0400, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote:
> > > Thanks. All seven applied.
> >
> > Good, but you missed one step: 'cvs remove API'
>
> U
-c -r1.13 README.pgcrypto
*** contrib/pgcrypto/README.pgcrypto13 Aug 2005 02:06:20 - 1.13
--- contrib/pgcrypto/README.pgcrypto1 Nov 2005 22:56:42 -
***
*** 3,8
--- 3,10
=
Marko Kreen
+ // Note: this
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
On 1/6/06, Bruce Momjian wrote:
> Bruno Wolff III wrote:
> > It might be nice to split nextval and currval access as well. nextval access
> > corresponds to INSERT and currval access to SELECT.
>
> Uh, that is already in the code. nextval()/setval() is UPDATE, and
> currval() is SELECT.
This see
On 1/6/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On 1/6/06, Bruce Momjian wrote:
> > > Bruno Wolff III wrote:
> > > > It might be nice to split nextval and currval access as well. nextval
> > > > access
> > > > corresponds to INSERT
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > On 1/6/06, Bruce Momjian wrote:
> >> Uh, logically, yes, but practially currval just reads/SELECTs, while
> >> nextval modifies/UPDATEs.
>
> > Yeah, thats
On 1/6/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 06, 2006 at 19:11:27 +0200,
> Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 1/6/06, Bruce Momjian wrote:
> >
> > Considering there's no currval() without nextval(), what point
> >
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > But my question is rather - is there any scenario where setval() should
> > go with nextval()?
>
> > It seems that their pairing is an accident and should be fixed.
&
On 1/6/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > I found SQL2003 pdf's too ... from my reading it has only USAGE.
> >
> > 5WD-02-Foundation-2003-09.pdf:
> > page 724 -> General Rules -> #2
> > page 740 -> Syntax rules -> #3
>
> I
On 1/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian writes:
> > FYI, we could support USAGE just on sequences, and have it map to
> > UPDATE, but pg_dump it out as USAGE.
>
> It seems the spec doesn't cover setval() and currval(), which is not
> too surprising given those aren't standar
On 1/7/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > The above table seem bit messy, but I see it as much easier to explain
> > to somebody.
>
> I am confused about your list above, so I can't see how that would be
> easy to explain.
Easy as in "use GRANT U
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+.
Reason for the messy code was that I tried to avoid creating
wrapper structure to tra
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,
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 a
On 5/4/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Martijn van Oosterhout writes:
> Currently, configure ignores unknown --enable/disable/with/without
> options.
The autoconf people consider that a feature, not a bug. I'm
disinclined to second-guess the designers of the tool, especially
with a pat
On 5/9/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> 1. Provide an escape option they can add
> 2. Package systems can usually apply patches prior to compiling, they can
> always remove the offending line if they like.
> 3. Try and
On 5/8/06, Martijn van Oosterhout wrote:
This implements a proposal made last november:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00578.php
All it requires is to include the header "pgmagic.h" and to put
somewhere in their source:
PG_MODULE_MAGIC
Could you serve this as spec
On 5/31/06, Martijn van Oosterhout wrote:
On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
> On 5/8/06, Martijn van Oosterhout wrote:
> >All it requires is to include the header "pgmagic.h" and to put
> >somewhere in their source:
> >
> >PG_MOD
On 5/31/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> Could you serve this as special docstring instead? Eg:
>>> PG_MODULE(foomodule)
I have no objection to that, and see no real implementation problem with
it: w
misc.c annoys me and creates unnecesary inter-dependencies just
for sharing a couple of bytes. This patch splits it out
to crypt-md5.c and crypt-des.c
Please do 'cvs remove misc.c' after applying this patch.
Index: pgsql/contrib/pgcrypto/Makefile
=
Uninstall script for pgcrypto.
Index: pgsql/contrib/pgcrypto/Makefile
===
*** pgsql.orig/contrib/pgcrypto/Makefile
--- pgsql/contrib/pgcrypto/Makefile
*** MODULE_big = pgcrypto
*** 35,40
--- 35,41
OBJS
I happened to compile entab once again and found couple problems:
- halt.c did not include stdlib.h, thus missed exit() prototype
- Makefile ignores BINDIR for install.
- Makefile calls install with user/group args, thus failing for regular user.
this fixes them.
--
marko
Index: src/tools/entab
* Use Fortuna for pseudo-random bytes too, as those need to
be high-quality also. OpenSSL internally acts same way.
* Clarify add_entropy logic - before first reseed get_rand_pool()
will return only 0, so make it explicit.
* On reseeding on first request, don't check if the pool#0 is
fille
**
*** 0
--- 1,317
+ /*
+ * internal.c
+ *Wrapper for builtin functions
+ *
+ * Copyright (c) 2001 Marko Kreen
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provide
Few cleanups and couple of new things:
- add SHA2 algorithm to older OpenSSL
- add BIGNUM math to have public-key cryptography work
on non-OpenSSL build.
- gen_random_bytes() function
The status of SHA2 algoritms and public-key encryption
can now be changed to 'always available.'
That make
Function DES_ecb3_encrypt has unstable signature in OpenSSL.
Different versions of OpenSSL have different argument types
and it is not possible to pick right types by OpenSSL version.
Following patch silents compiler by forcing argument to (void *).
Index: pgsql/contrib/pgcrypto/openssl.c
==
Following patch provides function gen_random_bytes() to SQL-level,
that uses internal strong random number generator to generate
a bytea value.
I've looked at server-managed-encryption-keys that seems new trend
in commercial databases. I don't think such functionality has a
place in pgcrypto, but
SHA224 is cut-down SHA256 with different init vector,
let the sha2.c provide it also.
New revision of DSA standard includes SHA224, thus also upcoming
update to RFC2440 (OpenPGP).
Therefore, it is good to have it available.
Index: pgsql/contrib/pgcrypto/sha2.c
==
In PGP public key tests, the password-encrypted secret
key happened to be encrypted with CAST5 instead of AES.
As OpenSSL has CAST5 always available I did not notice
it before.
Re-encrypt the key with AES.
Index: pgsql/contrib/pgcrypto/expected/pgp-pubkey-decrypt.out
On 7/13/06, Neil Conway <[EMAIL PROTECTED]> wrote:
Marko, can you take a look at what is causing this regression test
failure? The failing machine is kudu:
Seems you have skipped the CAST5 patch. Could you recheck?
--
marko
---(end of broadcast)---
- Few README fixes
- Keep imath Id string, put $PostgreSQL$ separately.
--
marko
Index: contrib/pgcrypto/README.pgcrypto
===
RCS file: /opt/cvs/pgsql/contrib/pgcrypto/README.pgcrypto,v
retrieving revision 1.15
diff -u -c -r1.15 READM
}
+
Index: pgsql/src/backend/utils/adt/txid.c
===
*** /dev/null
--- pgsql/src/backend/utils/adt/txid.c
***
*** 0
--- 1,507
+ /*-
+ * txid.c
+ *
+ *Safe handli
On 7/27/06, Darcy Buskermolen <[EMAIL PROTECTED]> wrote:
In one of those 3am lightbulbs I belive I have a way to make use of the 64-bit
XID counter and still maintain the ability to have backwards compatibility.
Is there any chance you could break this patch up into the 2 separate
componenets tha
On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (I wouldn't do it like this though --- TransactionIdAdvance itself is
>> the place to bump the secondary counter.)
> Agreed.
I reconsidered after trying to do it that way --- although
On Mon, Dec 06, 2004 at 12:51:28AM +0900, Korea PostgreSQL Users' Group wrote:
> I found that function gen_salt() in contrib/pgcrypto had bug on win32.
>
> I patched contrib/pgcrypto/random.c file.
Could you describe the bug bit more?
As for srandom, src/backend/postmaster/postmaster.c does it
a
On Sun, Dec 05, 2004 at 06:36:38PM -0500, Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > I would not object to just sticking '& 255' there,
>
> The patch actually says '% 255' which is a whole different animal;
> it still requires exp
On Tue, Dec 07, 2004 at 01:18:41AM +0900, Korea PostgreSQL Users' Group wrote:
> this bug is only for win32 system.
>
> On mingw32 random() function have to be initialized by srandom().
> so, I put srandom(time(NULL)) line.
> and,
> Because random() function return integer (2byte), this return int
entab did not compile for me (cvs head), as
gcc 3.3.5 #error's on .
This patch includes and also converts
arg declaration to ANSI style, because K&R varargs
are mystery to me.
--
marko
Index: src/tools/entab/entab.c
===
RCS file
On Linux/ARM PostgreSQL may encounter 2 types of floating point emulation:
1) standard precision: Linux/NWFPE, GCC soft-float
2) reduced precision: Linux/FastFPE
Currently pg_regress allows only unconditional alternatives - thus
different results are accepted on all platforms. This should be
On Fri, Feb 11, 2005 at 12:08:22PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Linux/ARM PostgreSQL may encounter 2 types of floating point emulation:
> > 1) standard precision: Linux/NWFPE, GCC soft-float
> > 2) reduced precision: Linux/FastFPE
>
> I don
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 th
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
On Sun, Mar 13, 2005 at 11:12:42AM +1100, Neil Conway wrote:
> Marko Kreen wrote:
> >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'.
>
>
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 c
Here are various updates for pgcrypto that
I've been sitting on for some time now.
They should be applied in order, but otherwise
they stand alone - code should in working state
after each one.
Next update is hopefully pgp_encrypt, which I
have already working, only some final polishing
is missin
* construct "struct {} list [] = {}" confuses pgindent - split those.
It was a bad style to begin with, and now several loops can be clearer.
* pgcrypto.c: Fix function comments
* crypt-gensalt.c, crypt-blowfish.c: stop messing with errno
* openssl.c: use px_free instead pfree
* px.h: make redefi
* Use error codes instead of -1
* px_strerror for new error codes
* calling convention change for px_gen_salt - return error code
* use px_strerror in pgcrypto.c
Index: pgsql/contrib/pgcrypto/px.c
===
*** pgsql.orig/contrib/pgcrypto/
//mhash.sourceforge.org/
-
CREDITS
===
--- 186,191
Index: pgsql/contrib/pgcrypto/mhash.c
===
*** pgsql.orig/contrib/pgcrypto/mhash.c
--- /dev/null
***
*** 1,356 ****
- /*
- * mhash.c
- *
* test error handling
* add tests for des, 3des, cast5
* add some tests to blowfish, rijndael
* Makefile: ability to specify different tests for different crypto
libraries, so we can skip des, 3des and cast5 for builtin.
Index: pgsql/contrib/pgcrypto/sql/blowfish.sql
===
* openssl.c: Add 3des and AES support
* README.pgcrypto: list only supported ciphers for openssl
OpenSSL has pre-processor symbol OPENSSL_NO_AES, which
isn't that helpful for detecting if it _does_ exist.
Thus the hack with AES_ENCRYPT.
Index: pgsql/contrib/pgcrypto/openssl.c
===
Reserve px_get_random_bytes() for strong randomness,
add new function px_get_pseudo_random_bytes() for
weak randomness and use it in gen_salt().
On openssl case, use RAND_pseudo_bytes() for
px_get_pseudo_random_bytes().
Final result is that is user has not configured random
souce but kept the 'si
There was a patch applied against entab/halt.c that converts
it away from K&R varargs. But it's buggy, its makes halt()
use second argment as format string, not first.
Following patch fixes it, but also converts entab/entab.c away
from K&R.
That is from my own patch against entab for the same
pr
On Fri, May 06, 2005 at 11:49:43AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and ap
Finally, here is pgp_encrypt()/pgp_decrypt() - implementation
of password-based encryption from RFC2440 (OpenPGP).
The goal of this code is to be more featureful encryption solution
than current encrypt(), which only functionality is running cipher
over data.
Compared to encrypt(), pgp_encrypt()
On Mon, Jun 27, 2005 at 09:08:05PM -0400, Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
Please u
On Sat, Jul 02, 2005 at 10:33:05PM -0400, Bruce Momjian wrote:
> Patch applied. Thanks.
> ---
> Michael Fuhr wrote:
> > This patch allows contrib/pgcrypto to build with OpenSSL 0.9.8
> > (currently in beta) when cryptolib = op
On Mon, Jul 04, 2005 at 12:22:03PM +1000, Neil Conway wrote:
> Bruce Momjian wrote:
> >Patch applied. Thanks.
>
> Should either or both of these patches be applied to back branches?
That would be a good idea.
--
marko
---(end of broadcast)---
T
On Mon, Jul 04, 2005 at 04:59:58PM +1000, Neil Conway wrote:
> Marko Kreen wrote:
> >Please use following updated patch instead.
> >
> >It implements utf8 conversion, fixes couple of bugs and has
> >many code and comment cleanups.
>
> The regression tests don&#
On Mon, Jul 04, 2005 at 10:31:21AM -0400, Bruce Momjian wrote:
> OK, I have applied the last two diffs for pgcrypto includes to 8.0.X,
> attached.
> *** contrib/pgcrypto/openssl.c12 Mar 2005 06:54:31 - 1.13.4.1
> --- contrib/pgcrypto/openssl.c4 Jul 2005 14:30:12 -
> **
On Tue, Jul 05, 2005 at 10:20:17AM +1000, Neil Conway wrote:
> Bruce Momjian wrote:
> >Your patch has been added to the PostgreSQL unapplied patches list
>
> That is not the latest version of Marko's patch.
Bruce got v3, thats indeed the latest.
Also, http://momjian.postgresql.org/cgi-bin/pgpatc
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
meanti
+ *Fortuna-like PRNG.
+ *
+ * Copyright (c) 2005 Marko Kreen
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code
Following two patches add Fortuna PRNG to pgcrypto. I think
this is needed to really complete the 'no hand-config' direction
of pgcrypto.
Patch #1 adds implementation of SHA2 hashes (SHA256/384/512).
They are required for Fortuna. As they are replacements
for SHA1 (which was replacement for MD5)
This patch adds implementation of SHA2 to pgcrypto.
New hashes: SHA256, SHA384, SHA512.
Code from OpenBSD.
Index: pgsql/contrib/pgcrypto/Makefile
===
*** pgsql.orig/contrib/pgcrypto/Makefile
--- pgsql/contrib/pgcrypto/Makefile
*
On Fri, Jul 08, 2005 at 02:10:47PM -0500, Bruno Wolff III wrote:
> On Fri, Jul 08, 2005 at 20:54:40 +0300,
> Marko Kreen wrote:
> >
> > The idea is to initially seed Fortuna with randomness from
> > system and later feed SHA1 of user data into it too. Just
> >
On Fri, Jul 08, 2005 at 03:12:59PM -0500, Bruno Wolff III wrote:
> On Fri, Jul 08, 2005 at 23:03:49 +0300,
> Marko Kreen wrote:
> >
> > Well, those OS'es that already have urandom/random, don't need
> > it. And those that don't - I really don't feel
On Sat, Jul 09, 2005 at 11:58:14PM -0400, Bruce Momjian wrote:
> Patch applied. Thanks.
Great!
Small problem with the 3 patches: you forgot to 'cvs add' new files?
--
marko
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Recently was uncovered that pgcrypto does not include
right header file to get BYTE_ORDER define on Cygwin
and MINGW, and the missing define does not result in
build failures, but random combinations of little and
big-endian code sections.
This patch adds missing sys/param.h include for md5.c,
sha
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 t
- 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
===
/README.pgcrypto
--- pgsql/contrib/pgcrypto/README.pgcrypto
***
*** 1,362
! pgcrypto 0.4 - cryptographic functions for PostgreSQL.
! ==
! by Marko Kreen
! INSTALLATION
!
! Edit makefile, if you want to use any
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
1 - 100 of 126 matches
Mail list logo
