postgres

Commit Graph

Author	SHA1	Message	Date
Tom Lane	38a4c35116	Persuade new pgcrypto stuff to compile.	25 years ago
Bruce Momjian	fe786448e7	Remove krb.c.	25 years ago
Bruce Momjian	18529514b1	Remove encode.*. Not needed anymore.	25 years ago
Bruce Momjian	62d19bd1d2	Remove object file.	25 years ago
Bruce Momjian	df24cb73f6	Add missing pgcrypto file.	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() * UNX-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	558fae16e3	The attached patch enables the contrib subtree to build cleanly under Cygwin with the possible exception of mSQL-interface. Since I don't have mSQL installed, I skipped this tool. Except for dealing with a missing getopt.h (oid2name) and HUGE (seg), the bulk of the patch uses the standard PostgreSQL approach to deal with Windows DLL issues. I tested the build aspect of this patch under Cygwin and Linux without any ill affects. Note that I did not actually attempt to test the code for functionality. The procedure to apply the patch is as follows: $ # save the attachment as /tmp/contrib.patch $ # change directory to the top of the PostgreSQL source tree $ patch -p0 </tmp/contrib.patch Jason	25 years ago
Bruce Momjian	fdbfe1c68e	Well, the correct code - that corresponds to current encode - is below. I even got the linefeed stuff wrong. -- marko	25 years ago
Bruce Momjian	5ee76ac8c0	> I've been experimenting with pgcrypto 0.3 (distributed with > Postgres 7.1.0), and I think I've found a bug. > > I compiled Pgcrypto with OpenSSL, using gcc 2.95.4 and > OpenSSL 0.9.6a (the latest Debian 'unstable' packages). > web=> select encode(digest('blah', 'sha1'), 'base64'); > FATAL 1: pg_encode: overflow, encode estimate too small > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Succeeded. > Is this a bug? Can it be fixed? This is a bug alright. And a silly one :) Marko Kreen	25 years ago
Bruce Momjian	9e1552607a	pgindent run. Make it all clean.	25 years ago
Tom Lane	10a4e0c2eb	Documentation update from Marko Kreen.	25 years ago
Bruce Momjian	60ea34b046	Changes: * reverse the change #include <> -> "" in krb.c. It _must not_ include files in "." * Makefile update. Inconsistent var usage and SHLIB was not set. Now it should work with all external libs. arko Kreen	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	7a4cc54e58	Eliminate some of the more blatant platform-dependencies ... it builds here now, anyway ...	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

19 Commits (e30b283f30c39648abc17e14b709ad93f53aac95)