Remove notes from the frontend SSL source that are incorrect or

end-user documentation that lives in the actual documentation.

diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 2f72b0a5de4d8b8bd99296b36207e138acf3779d..af85257a86bcb2b07b43e4e45d24186268b76e64 100644 (file)
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -11,64 +11,9 @@
  *
  *
  * IDENTIFICATION
- *   $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.105 2008/05/16 18:30:53 mha Exp $
+ *   $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.106 2008/10/24 12:29:11 mha Exp $
  *
  * NOTES
- *   [ Most of these notes are wrong/obsolete, but perhaps not all ]
- *
- *   The client *requires* a valid server certificate.  Since
- *   SSH tunnels provide anonymous confidentiality, the presumption
- *   is that sites that want endpoint authentication will use the
- *   direct SSL support, while sites that are comfortable with
- *   anonymous connections will use SSH tunnels.
- *
- *   This code verifies the server certificate, to detect simple
- *   "man-in-the-middle" and "impersonation" attacks.  The
- *   server certificate, or better yet the CA certificate used
- *   to sign the server certificate, should be present in the
- *   "~/.postgresql/root.crt" file.  If this file isn't
- *   readable, or the server certificate can't be validated,
- *   pqsecure_open_client() will return an error code.
- *
- *   Additionally, the server certificate's "common name" must
- *   resolve to the other end of the socket.  This makes it
- *   substantially harder to pull off a "man-in-the-middle" or
- *   "impersonation" attack even if the server's private key
- *   has been stolen.  This check limits acceptable network
- *   layers to Unix sockets (weird, but legal), TCPv4 and TCPv6.
- *
- *   Unfortunately neither the current front- or back-end handle
- *   failure gracefully, resulting in the backend hiccupping.
- *   This points out problems in each (the frontend shouldn't even
- *   try to do SSL if pqsecure_initialize() fails, and the backend
- *   shouldn't crash/recover if an SSH negotiation fails.  The
- *   backend definitely needs to be fixed, to prevent a "denial
- *   of service" attack, but I don't know enough about how the
- *   backend works (especially that pre-SSL negotiation) to identify
- *   a fix.
- *
- *   ...
- *
- *   Unlike the server's static private key, the client's
- *   static private key (~/.postgresql/postgresql.key)
- *   should normally be stored encrypted.  However we still
- *   support EPH since it's useful for other reasons.
- *
- *   ...
- *
- *   Client certificates are supported, if the server requests
- *   or requires them.  Client certificates can be used for
- *   authentication, to prevent sessions from being hijacked,
- *   or to allow "road warriors" to access the database while
- *   keeping it closed to everyone else.
- *
- *   The user's certificate and private key are located in
- *     ~/.postgresql/postgresql.crt
- *   and
- *     ~/.postgresql/postgresql.key
- *   respectively.
- *
- *   ...
  *
  *   We don't provide informational callbacks here (like
  *   info_cb() in be-secure.c), since there's mechanism to