9 Commits (fc564686a76ff045a4dba85a3b077de4fe4b64b6)

Author	SHA1	Message	Date
Tom Lane	f85f43dfb5	Backend support for autocommit removed, per recent discussions. The ... only remnant of this failed experiment is that the server will take SET AUTOCOMMIT TO ON. Still TODO: provide some client-side autocommit logic in libpq.	23 years ago
Bruce Momjian	aa4c702eac	Update /contrib for "autocommit TO 'on'". ... Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.	24 years ago
Tom Lane	6d6b3e911c	Add variants of digest() and hmac() that accept text inputs. ... Marko Kreen says: This is so obvious that I would like to make it 'official'. Seems like the theology around bytea<>text casting kept me from seeing the simple :)	24 years ago
Bruce Momjian	cff23429d6	I noticed that the contrib Makefiles were reorganized. ... Converted pgcrypto one too. * Changed default randomness source to libc random() That way pgcrypto does not have any external dependencies and should work everywhere. * Re-enabled pgcrypto build in contrib/makefile * contrib/README update - there is more stuff than only 'hash functions' * Noted the libc random fact in README.pgcrypto Marko Kreen	25 years ago
Bruce Momjian	ab56022864	Big thanks to Solar Designer who pointed out a bug in bcrypt ... salt generation code. He also urged using better random source and making possible to choose using bcrypt and xdes rounds more easily. So, here's patch: * For all salt generation, use Solar Designer's own code. This is mostly due fact that his code is more fit for get_random_bytes() style interface. * New function: gen_salt(type, rounds). This lets specify iteration count for algorithm. * random.c: px_get_random_bytes() function. Supported randomness soure: /dev/urandom, OpenSSL PRNG, libc random() Default: /dev/urandom. * Draft description of C API for pgcrypto functions. New files: API, crypt-gensalt.c, random.c Marko Kreen	25 years ago
Bruce Momjian	2518e27334	/contrib/pgcrypto: ... * remove support for encode() as it is in main tree now * remove krb5.c * new 'PX library' architecture * remove BSD license from my code to let the general PostgreSQL one to apply * md5, sha1: ANSIfy, use const where appropriate * various other formatting and clarity changes * hmac() * UN*X-like crypt() - system or internal crypt * Internal crypt: DES, Extended DES, MD5, Blowfish crypt-des.c, crypt-md5.c from FreeBSD crypt-blowfish.c from Solar Designer * gen_salt() for crypt() - Blowfish, MD5, DES, Extended DES * encrypt(), decrypt(), encrypt_iv(), decrypt_iv() * Cipher support in mhash.c, openssl.c * internal: Blowfish, Rijndael-128 ciphers * blf.[ch], rijndael.[ch] from OpenBSD * there will be generated file rijndael-tbl.inc. Marko Kreen	25 years ago
Bruce Momjian	cb5427ee47	I would like to do a interface change in pgcrypto. (Good ... timing, I know :)) At the moment the digest() function returns hexadecimal coded hash, but I want it to return pure binary. I have also included functions encode() and decode() which support 'base64' and 'hex' encodings, so if anyone needs digest() in hex he can do encode(digest(...), 'hex'). Main reason for it is "to do one thing and do it well" :) Another reason is if someone needs really lot of digesting, in the end he wants to store the binary not the hexadecimal result. It is really silly to convert it to hex then back to binary again. As I said if someone needs hex he can get it. Well, and the real reason that I am doing encrypt()/decrypt() functions and _they_ return binary. For testing I like to see it in hex occasionally, but it is really wrong to let them return hex. Only now it caught my eye that hex-coding in digest() is wrong. When doing digest() I thought about 'common case' but hacking with psql is probably _not_ the common case :) Marko Kreen	25 years ago
Tom Lane	5bb2300b59	Revise handling of oldstyle/newstyle functions per recent discussions ... in pghackers list. Support for oldstyle internal functions is gone (no longer needed, since conversion is complete) and pg_language entry 'internal' now implies newstyle call convention. pg_language entry 'newC' is gone; both old and newstyle dynamically loaded C functions are now called language 'C'. A newstyle function must be identified by an associated info routine. See src/backend/utils/fmgr/README.	25 years ago
Peter Eisentraut	0c0dde6176	Hashing functions from Marko Kreen <marko@l-t.ee>	26 years ago