8 Commits (e30b283f30c39648abc17e14b709ad93f53aac95)

Author	SHA1	Message	Date
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	9e1552607a	pgindent run. Make it all clean.	25 years ago
Tom Lane	d08741eab5	Restructure the key include files per recent pghackers discussion: there ... are now separate files "postgres.h" and "postgres_fe.h", which are meant to be the primary include files for backend .c files and frontend .c files respectively. By default, only include files meant for frontend use are installed into the installation include directory. There is a new make target 'make install-all-headers' that adds the whole content of the src/include tree to the installed fileset, for use by people who want to develop server-side code without keeping the complete source tree on hand. Cleaned up a whole lot of crufty and inconsistent header inclusions.	25 years ago
Bruce Momjian	659a1d65c6	Well, learned the hard way... ... 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
Bruce Momjian	e586026d10	The KAME files md5.* and sha1.* have the following changelog ... entry: ---------------------------- revision 1.2 date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18 Eliminate some of the more blatant platform-dependencies ... it builds here now, anyway ... ---------------------------- Which basically changes u_int*_t -> uint*_t, so now it does not compile neither under Debian 2.2 nor under NetBSD 1.5 which is platform independent<B8> all right. Also it replaces $KAME$ with $Id$ which is Bad Thing. PostgreSQL Id should be added as a separate line so the file history could be seen. So here is patch: * changes uint*_t -> uint*. I guess that was the original intention * adds uint64 type to include/c.h because its needed [somebody should check if I did it right] * adds back KAME Id, because KAME is the master repository * removes stupid c++ comments in pgcrypto.c * removes <sys/types.h> from the code, its not needed -- marko 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