- 06 Sep, 2002 1 commit
-
-
Bruce Momjian authored
-
- 05 Sep, 2002 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
Cleanup up memory allocation for $HOME in related psql places. Update mention of $HOME/.pgpass in the docs; add mention in pg_dumpall.
-
- 04 Sep, 2002 1 commit
-
-
Bruce Momjian authored
-
- 30 Aug, 2002 1 commit
-
-
Tom Lane authored
-
- 29 Aug, 2002 2 commits
-
-
Bruce Momjian authored
> > > > where is the code to verify that PGPASSWORDFILE points at a > > > > non-world-readable file? That needs to be there now, not later, or > > > > we'll have people moaning about backward compatibility when we finally > > > > do plug that hole. Alvaro Herrera
-
Tatsuo Ishii authored
-
- 27 Aug, 2002 3 commits
-
-
Bruce Momjian authored
(using an elog(LOG) ), as well as includes a few more comment fixes. Neil Conway
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 18 Aug, 2002 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 17 Aug, 2002 1 commit
-
-
Bruce Momjian authored
Denis A Ustimenko
-
- 15 Aug, 2002 1 commit
-
-
Bruce Momjian authored
PGPASSWORDFILE environment variable. I have modified libpq to make use of this variable. I present the first cut here. Currently the format for the file should be host:port:database:user:password Alvaro Herrera
-
- 20 Jul, 2002 1 commit
-
-
Bruce Momjian authored
. So i took the opportunity to fix some stuff: 1. Made the thing compile (typos & needed definitions) with the new pqsecure_* s tuff, and added fe-secure.c to the win32.mak makefile. 2. Fixed some MULTIBYTE compile errors (when building without MB support). 3. Made it do that you can build with debug info: "nmake -f win32.mak DEBUG=1". 4. Misc small compiler speedup changes. The resulting .dll has been tested in production, and everything seems ok. I CC:ed -hackers because i'm not sure about two things: 1. In libpq-int.h I typedef ssize_t as an int because Visual C (v6.0) doesn't de fine ssize_t. Is that ok, or is there any standard about what type should be use d for ssize_t? 2. To keep the .dll api consistent regarding MULTIBYTE I just return -1 in fe-connect.c:PQsetClientEncoding() instead of taking away the whole function. I wonder if i should do any compares with the conn->client_encoding and return 0 if not hing would have changed (if so how do i check that?). Regards Magnus Naeslund
-
- 18 Jul, 2002 1 commit
-
-
Tatsuo Ishii authored
conversion procs and conversions are added in initdb. Currently supported conversions are: UTF-8(UNICODE) <--> SQL_ASCII, ISO-8859-1 to 16, EUC_JP, EUC_KR, EUC_CN, EUC_TW, SJIS, BIG5, GBK, GB18030, UHC, JOHAB, TCVN EUC_JP <--> SJIS EUC_TW <--> BIG5 MULE_INTERNAL <--> EUC_JP, SJIS, EUC_TW, BIG5 Note that initial contents of pg_conversion system catalog are created in the initdb process. So doing initdb required is ideal, it's possible to add them to your databases by hand, however. To accomplish this: psql -f your_postgresql_install_path/share/conversion_create.sql your_database So I did not bump up the version in cataversion.h. TODO: Add more conversion procs Add [CASCADE|RESTRICT] to DROP CONVERSION Add tuples to pg_depend Add regression tests Write docs Add SQL99 CONVERT command? -- Tatsuo Ishii
-
- 20 Jun, 2002 1 commit
-
-
Bruce Momjian authored
-
- 15 Jun, 2002 1 commit
-
-
Tom Lane authored
files rather than a header file where they belong. Pay some modicum of attention to picking global routine names that aren't likely to conflict with surrounding applications.
-
- 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
-
- 15 Apr, 2002 1 commit
-
-
Bruce Momjian authored
In summary, if a software writer implements timer events or other events which generate a signal with a timing fast enough to occur while libpq is inside connect(), then connect returns -EINTR. The code following the connect call does not handle this and generates an error message. The sum result is that the pg_connect() fails. If the timer or other event is right on the window of the connect() completion time, the pg_connect() may appear to work sporadically. If the event is too slow, pg_connect() will appear to always work and if the event is too fast, pg_connect() will always fail. David Ford
-
- 02 Mar, 2002 1 commit
-
-
Tom Lane authored
postmaster won't accept the request anyway. (If your kernel can't be trusted, SSL will not help you.)
-
- 11 Nov, 2001 1 commit
-
-
Tom Lane authored
a NULL pointer. Per report from Stephen Pillinger 8-Nov-01.
-
- 05 Nov, 2001 1 commit
-
-
Bruce Momjian authored
initdb/regression tests pass.
-
- 28 Oct, 2001 1 commit
-
-
Bruce Momjian authored
spacing. Also adds space for one-line comments.
-
- 25 Oct, 2001 1 commit
-
-
Bruce Momjian authored
tests pass.
-
- 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
-
- 21 Aug, 2001 1 commit
-
-
Bruce Momjian authored
> It seems that win9x doesn't have the "netmsg.dll" so it defaults to "normal" > FormatMessage. > I wonder if one could load wsock32.dll or winsock.dll on those systems > instead of netmsg.dll. > > Mikhail, could you please test this code on your nt4 system? > Could someone else test this code on a win98/95 system? > > It works on win2k over here. It works on win2k here too but not on win98/95 or winNT. Anyway, attached is the patch which uses Magnus's my_sock_strerror function (renamed to winsock_strerror). The only difference is that I put the code to load and unload netmsg.dll in the libpqdll.c (is this OK Magnus?). Mikhail Terekhov
-
- 17 Aug, 2001 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 15 Aug, 2001 1 commit
-
-
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.
-
- 03 Aug, 2001 1 commit
-
-
Tom Lane authored
that should use regular errno, not WSAGetLastError(), now do so again.
-
- 31 Jul, 2001 1 commit
-
-
Tom Lane authored
anymore.
-
- 21 Jul, 2001 1 commit
-
-
Bruce Momjian authored
changes on this new source to make non-blocking connection work. I tested it, and PQSendQuery and PQGetResult are working fine. In win32.h I added one line: #define snprintf _snprintf Darko Prenosil
-
- 20 Jul, 2001 1 commit
-
-
Bruce Momjian authored
functions do not set errno, so some normal conditions are treated as fatal errors. e.g. fetching large tuples fails, as at some point recv() returns EWOULDBLOCK. here's a patch, which replaces errno with WSAGetLastError(). i've tried to to affect non-win32 code. Dmitry Yurtaev
-
- 16 Jul, 2001 1 commit
-
-
Peter Eisentraut authored
-
- 15 Jul, 2001 1 commit
-
-
Peter Eisentraut authored
accordingly.
-
- 06 Jul, 2001 2 commits
-
-
Peter Eisentraut authored
-
Peter Eisentraut authored
the startup exchange is complete. Also make sure that packets defined as single bytes aren't sent with a trailing '\0'.
-