- 08 Aug, 2003 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 17 Jun, 2003 1 commit
-
-
Peter Eisentraut authored
-
- 14 Jun, 2003 1 commit
-
-
Bruce Momjian authored
-
- 12 Jun, 2003 1 commit
-
-
Bruce Momjian authored
-
- 08 Jun, 2003 1 commit
-
-
Tom Lane authored
protocol 3, then falls back to 2 if postmaster rejects the startup packet with an old-format error message. A side benefit of the rewrite is that SSL-encrypted connections can now be made without blocking. (I think, anyway, but do not have a good way to test.)
-
- 10 May, 2003 1 commit
-
-
Bruce Momjian authored
for rint prototype.
-
- 09 May, 2003 1 commit
-
-
Bruce Momjian authored
-
- 22 Apr, 2003 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 14 Apr, 2003 1 commit
-
-
Tom Lane authored
-
- 29 Mar, 2003 1 commit
-
-
Peter Eisentraut authored
function if the OS doesn't provide one.
-
- 03 Feb, 2003 1 commit
-
-
Bruce Momjian authored
-
- 10 Jan, 2003 1 commit
-
-
Peter Eisentraut authored
-
- 06 Jan, 2003 1 commit
-
-
Bruce Momjian authored
if the OS supports it. Code will still compile on non-IPv6-aware machines (feature added by Bruce). Nigel Kukard
-
- 13 Dec, 2002 1 commit
-
-
Bruce Momjian authored
-
- 11 Dec, 2002 1 commit
-
-
Bruce Momjian authored
-
- 06 Dec, 2002 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
postgresql version 7.3, but yea... this patch adds full IPv6 support to postgres. I've tested it out on 7.2.3 and has been running perfectly stable. CREDITS: The KAME Project (Initial patch) Nigel Kukard <nkukard@lbsd.net> Johan Jordaan <johanj@lando.co.za>
-
- 04 Dec, 2002 1 commit
-
-
Bruce Momjian authored
-
- 03 Sep, 2002 1 commit
-
-
Peter Eisentraut authored
referring to "multibyte" where it really means character encoding.
-
- 27 Jul, 2002 1 commit
-
-
Peter Eisentraut authored
Some makefile simplifications.
-
- 18 Jul, 2002 1 commit
-
-
Bruce Momjian authored
-
- 14 Jun, 2002 3 commits
-
-
Bruce Momjian authored
Attached are a revised set of SSL patches. Many of these patches are motivated by security concerns, it's not just bug fixes. The key differences (from stock 7.2.1) are: *) almost all code that directly uses the OpenSSL library is in two new files, src/interfaces/libpq/fe-ssl.c src/backend/postmaster/be-ssl.c in the long run, it would be nice to merge these two files. *) the legacy code to read and write network data have been encapsulated into read_SSL() and write_SSL(). These functions should probably be renamed - they handle both SSL and non-SSL cases. the remaining code should eliminate the problems identified earlier, albeit not very cleanly. *) both front- and back-ends will send a SSL shutdown via the new close_SSL() function. This is necessary for sessions to work properly. (Sessions are not yet fully supported, but by cleanly closing the SSL connection instead of just sending a TCP FIN packet other SSL tools will be much happier.) *) The client certificate and key are now expected in a subdirectory of the user's home directory. Specifically, - the directory .postgresql must be owned by the user, and allow no access by 'group' or 'other.' - the file .postgresql/postgresql.crt must be a regular file owned by the user. - the file .postgresql/postgresql.key must be a regular file owned by the user, and allow no access by 'group' or 'other'. At the current time encrypted private keys are not supported. There should also be a way to support multiple client certs/keys. *) the front-end performs minimal validation of the back-end cert. Self-signed certs are permitted, but the common name *must* match the hostname used by the front-end. (The cert itself should always use a fully qualified domain name (FDQN) in its common name field.) This means that psql -h eris db will fail, but psql -h eris.example.com db will succeed. At the current time this must be an exact match; future patches may support any FQDN that resolves to the address returned by getpeername(2). Another common "problem" is expiring certs. For now, it may be a good idea to use a very-long-lived self-signed cert. As a compile-time option, the front-end can specify a file containing valid root certificates, but it is not yet required. *) the back-end performs minimal validation of the client cert. It allows self-signed certs. It checks for expiration. It supports a compile-time option specifying a file containing valid root certificates. *) both front- and back-ends default to TLSv1, not SSLv3/SSLv2. *) both front- and back-ends support DSA keys. DSA keys are moderately more expensive on startup, but many people consider them preferable than RSA keys. (E.g., SSH2 prefers DSA keys.) *) if /dev/urandom exists, both client and server will read 16k of randomization data from it. *) the server can read empheral DH parameters from the files $DataDir/dh512.pem $DataDir/dh1024.pem $DataDir/dh2048.pem $DataDir/dh4096.pem if none are provided, the server will default to hardcoded parameter files provided by the OpenSSL project. Remaining tasks: *) the select() clauses need to be revisited - the SSL abstraction layer may need to absorb more of the current code to avoid rare deadlock conditions. This also touches on a true solution to the pg_eof() problem. *) the SIGPIPE signal handler may need to be revisited. *) support encrypted private keys. *) sessions are not yet fully supported. (SSL sessions can span multiple "connections," and allow the client and server to avoid costly renegotiations.) *) makecert - a script that creates back-end certs. *) pgkeygen - a tool that creates front-end certs. *) the whole protocol issue, SASL, etc. *) certs are fully validated - valid root certs must be available. This is a hassle, but it means that you *can* trust the identity of the server. *) the client library can handle hardcoded root certificates, to avoid the need to copy these files. *) host name of server cert must resolve to IP address, or be a recognized alias. This is more liberal than the previous iteration. *) the number of bytes transferred is tracked, and the session key is periodically renegotiated. *) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The configuration files have reasonable defaults for each type of use. Bear Giles
-
Bruce Momjian authored
-
Bruce Momjian authored
are motivated by security concerns, it's not just bug fixes. The key differences (from stock 7.2.1) are: *) almost all code that directly uses the OpenSSL library is in two new files, src/interfaces/libpq/fe-ssl.c src/backend/postmaster/be-ssl.c in the long run, it would be nice to merge these two files. *) the legacy code to read and write network data have been encapsulated into read_SSL() and write_SSL(). These functions should probably be renamed - they handle both SSL and non-SSL cases. the remaining code should eliminate the problems identified earlier, albeit not very cleanly. *) both front- and back-ends will send a SSL shutdown via the new close_SSL() function. This is necessary for sessions to work properly. (Sessions are not yet fully supported, but by cleanly closing the SSL connection instead of just sending a TCP FIN packet other SSL tools will be much happier.) *) The client certificate and key are now expected in a subdirectory of the user's home directory. Specifically, - the directory .postgresql must be owned by the user, and allow no access by 'group' or 'other.' - the file .postgresql/postgresql.crt must be a regular file owned by the user. - the file .postgresql/postgresql.key must be a regular file owned by the user, and allow no access by 'group' or 'other'. At the current time encrypted private keys are not supported. There should also be a way to support multiple client certs/keys. *) the front-end performs minimal validation of the back-end cert. Self-signed certs are permitted, but the common name *must* match the hostname used by the front-end. (The cert itself should always use a fully qualified domain name (FDQN) in its common name field.) This means that psql -h eris db will fail, but psql -h eris.example.com db will succeed. At the current time this must be an exact match; future patches may support any FQDN that resolves to the address returned by getpeername(2). Another common "problem" is expiring certs. For now, it may be a good idea to use a very-long-lived self-signed cert. As a compile-time option, the front-end can specify a file containing valid root certificates, but it is not yet required. *) the back-end performs minimal validation of the client cert. It allows self-signed certs. It checks for expiration. It supports a compile-time option specifying a file containing valid root certificates. *) both front- and back-ends default to TLSv1, not SSLv3/SSLv2. *) both front- and back-ends support DSA keys. DSA keys are moderately more expensive on startup, but many people consider them preferable than RSA keys. (E.g., SSH2 prefers DSA keys.) *) if /dev/urandom exists, both client and server will read 16k of randomization data from it. *) the server can read empheral DH parameters from the files $DataDir/dh512.pem $DataDir/dh1024.pem $DataDir/dh2048.pem $DataDir/dh4096.pem if none are provided, the server will default to hardcoded parameter files provided by the OpenSSL project. Remaining tasks: *) the select() clauses need to be revisited - the SSL abstraction layer may need to absorb more of the current code to avoid rare deadlock conditions. This also touches on a true solution to the pg_eof() problem. *) the SIGPIPE signal handler may need to be revisited. *) support encrypted private keys. *) sessions are not yet fully supported. (SSL sessions can span multiple "connections," and allow the client and server to avoid costly renegotiations.) *) makecert - a script that creates back-end certs. *) pgkeygen - a tool that creates front-end certs. *) the whole protocol issue, SASL, etc. *) certs are fully validated - valid root certs must be available. This is a hassle, but it means that you *can* trust the identity of the server. *) the client library can handle hardcoded root certificates, to avoid the need to copy these files. *) host name of server cert must resolve to IP address, or be a recognized alias. This is more liberal than the previous iteration. *) the number of bytes transferred is tracked, and the session key is periodically renegotiated. *) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The configuration files have reasonable defaults for each type of use. Bear Giles
-
- 22 Sep, 2001 1 commit
-
-
Peter Eisentraut authored
an already installed iODBC or unixODBC driver manager. In particular, use the include files provided by the driver manager over our own, and use the odbcinst library of the driver manager rather than gpps.c. Migrate portability sections common to several files into psqlodbc.h.
-
- 21 Sep, 2001 1 commit
-
-
Tom Lane authored
(salts were always zero!?), add much missing documentation.
-
- 06 Sep, 2001 1 commit
-
-
Tatsuo Ishii authored
------------------------------------------------------------------- Subject: Re: [PATCHES] encoding names From: Karel Zak <zakkr@zf.jcu.cz> To: Peter Eisentraut <peter_e@gmx.net> Cc: pgsql-patches <pgsql-patches@postgresql.org> Date: Fri, 31 Aug 2001 17:24:38 +0200 On Thu, Aug 30, 2001 at 01:30:40AM +0200, Peter Eisentraut wrote: > > - convert encoding 'name' to 'id' > > I thought we decided not to add functions returning "new" names until we > know exactly what the new names should be, and pending schema Ok, the patch not to add functions. > better > > ...(): encoding name too long Fixed. I found new bug in command/variable.c in parse_client_encoding(), nobody probably never see this error: if (pg_set_client_encoding(encoding)) { elog(ERROR, "Conversion between %s and %s is not supported", value, GetDatabaseEncodingName()); } because pg_set_client_encoding() returns -1 for error and 0 as true. It's fixed too. IMHO it can be apply. Karel PS: * following files are renamed: src/utils/mb/Unicode/KOI8_to_utf8.map --> src/utils/mb/Unicode/koi8r_to_utf8.map src/utils/mb/Unicode/WIN_to_utf8.map --> src/utils/mb/Unicode/win1251_to_utf8.map src/utils/mb/Unicode/utf8_to_KOI8.map --> src/utils/mb/Unicode/utf8_to_koi8r.map src/utils/mb/Unicode/utf8_to_WIN.map --> src/utils/mb/Unicode/utf8_to_win1251.map * new file: src/utils/mb/encname.c * removed file: src/utils/mb/common.c -- Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
-
- 28 Aug, 2001 1 commit
-
-
Peter Eisentraut authored
Client headers are no longer in a subdirectory, since they have been made namespace-clean. Internal libpq headers are in a private subdirectory. Server headers are in a private subdirectory. pg_config has a new option to point there.
-
- 15 Aug, 2001 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
Allow pg_shadow to be MD5 encrypted. Add ENCRYPTED/UNENCRYPTED option to CREATE/ALTER user. Add password_encryption postgresql.conf option. Update wire protocol version to 2.1.
-
- 15 Jul, 2001 1 commit
-
-
Peter Eisentraut authored
accordingly.
-
- 11 May, 2001 1 commit
-
-
Bruce Momjian authored
time to do it, not during beta because people are using this stuff in production sometimes.
-
- 20 Feb, 2001 1 commit
-
-
Peter Eisentraut authored
or library directories on the command line.
-
- 11 Feb, 2001 1 commit
-
-
Tatsuo Ishii authored
Now only wchar.c is shared by fronetnd/backend.
-
- 04 Feb, 2001 1 commit
-
-
Peter Eisentraut authored
-
- 20 Jan, 2001 1 commit
-
-
Tom Lane authored
implementation in backend/port/strerror.c if configure finds no strerror in libc, same as we do for snprintf and inet_aton.
-
- 30 Oct, 2000 1 commit
-
-
Tatsuo Ishii authored
Now frontend/libpq has its own version of pg_encoding_to_char and pg_char_to_encoding.
-
- 25 Oct, 2000 1 commit
-
-
Peter Eisentraut authored
the -l options. (This was not the case when using the OpenSSL or Kerberos options.) Also make sure that shared library links get to see all the -L options. Get Kerberos 5 support to compile on Redhat 7.0. Add OpenSSL and -lsocket (if used/found) to libpq link.
-