1. 06 Sep, 2002 1 commit
  2. 05 Sep, 2002 2 commits
  3. 04 Sep, 2002 1 commit
  4. 30 Aug, 2002 1 commit
  5. 29 Aug, 2002 2 commits
  6. 27 Aug, 2002 3 commits
  7. 18 Aug, 2002 2 commits
  8. 17 Aug, 2002 1 commit
  9. 15 Aug, 2002 1 commit
  10. 20 Jul, 2002 1 commit
    • Bruce Momjian's avatar
      Hello, i noticed that win32 native stopped working/compiling after the SSL merge · b6d2faaf
      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
      b6d2faaf
  11. 18 Jul, 2002 1 commit
    • Tatsuo Ishii's avatar
      I have committed many support files for CREATE CONVERSION. Default · eb335a03
      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
      eb335a03
  12. 20 Jun, 2002 1 commit
  13. 15 Jun, 2002 1 commit
  14. 14 Jun, 2002 3 commits
    • Bruce Momjian's avatar
      UPDATED PATCH: · 19570420
      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
      19570420
    • Bruce Momjian's avatar
      eb43af32
    • Bruce Momjian's avatar
      Attached are a revised set of SSL patches. Many of these patches · a9bd1761
      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
      a9bd1761
  15. 15 Apr, 2002 1 commit
    • Bruce Momjian's avatar
      Fix for EINTR returns from Win9X socket operations: · 394eec10
      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
      394eec10
  16. 02 Mar, 2002 1 commit
  17. 11 Nov, 2001 1 commit
  18. 05 Nov, 2001 1 commit
  19. 28 Oct, 2001 1 commit
  20. 25 Oct, 2001 1 commit
  21. 06 Sep, 2001 1 commit
    • Tatsuo Ishii's avatar
      Commit Karel's patch. · 22776711
      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
      22776711
  22. 21 Aug, 2001 1 commit
    • Bruce Momjian's avatar
      > Ok, where's a "system dependent hack" :) · 5db5c2db
      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
      5db5c2db
  23. 17 Aug, 2001 2 commits
  24. 15 Aug, 2001 1 commit
  25. 03 Aug, 2001 1 commit
  26. 31 Jul, 2001 1 commit
  27. 21 Jul, 2001 1 commit
  28. 20 Jul, 2001 1 commit
    • Bruce Momjian's avatar
      i've spotted a following problem using DBD::Pg under win32. winsock · 8c79f3c4
      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
      8c79f3c4
  29. 16 Jul, 2001 1 commit
  30. 15 Jul, 2001 1 commit
  31. 06 Jul, 2001 2 commits