1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-25 12:03:53 +03:00
Files
postgres/src/backend/libpq
Peter Eisentraut 611806cd72 Add trailing commas to enum definitions
Since C99, there can be a trailing comma after the last value in an
enum definition.  A lot of new code has been introducing this style on
the fly.  Some new patches are now taking an inconsistent approach to
this.  Some add the last comma on the fly if they add a new last
value, some are trying to preserve the existing style in each place,
some are even dropping the last comma if there was one.  We could
nudge this all in a consistent direction if we just add the trailing
commas everywhere once.

I omitted a few places where there was a fixed "last" value that will
always stay last.  I also skipped the header files of libpq and ecpg,
in case people want to use those with older compilers.  There were
also a small number of cases where the enum type wasn't used anywhere
(but the enum values were), which ended up confusing pgindent a bit,
so I left those alone.

Discussion: https://www.postgresql.org/message-id/flat/386f8c45-c8ac-4681-8add-e3b0852c1620%40eisentraut.org
2023-10-26 09:20:54 +02:00
..
2023-01-02 15:00:37 -05:00
2023-01-02 15:00:37 -05:00
2023-01-02 15:00:37 -05:00
2023-01-02 15:00:37 -05:00
2023-10-05 15:05:25 +03:00
2018-01-23 07:11:38 -05:00

src/backend/libpq/README.SSL

SSL
===

>From the servers perspective:


  Receives StartupPacket
           |
           |
 (Is SSL_NEGOTIATE_CODE?) -----------  Normal startup
           |                  No
           |
           | Yes
           |
           |
 (Server compiled with USE_SSL?) ------- Send 'N'
           |                       No        |
           |                                 |
           | Yes                         Normal startup
           |
           |
        Send 'S'
           |
           |
      Establish SSL
           |
           |
      Normal startup





>From the clients perspective (v6.6 client _with_ SSL):


      Connect
         |
         |
  Send packet with SSL_NEGOTIATE_CODE
         |
         |
  Receive single char  ------- 'S' -------- Establish SSL
         |                                       |
         | '<else>'                              |
         |                                  Normal startup
         |
         |
   Is it 'E' for error  ------------------- Retry connection
         |                  Yes             without SSL
         | No
         |
   Is it 'N' for normal ------------------- Normal startup
         |                  Yes
         |
   Fail with unknown

---------------------------------------------------------------------------

Ephemeral DH
============

Since the server static private key ($DataDir/server.key) will
normally be stored unencrypted so that the database backend can
restart automatically, it is important that we select an algorithm
that continues to provide confidentiality even if the attacker has the
server's private key.  Ephemeral DH (EDH) keys provide this and more
(Perfect Forward Secrecy aka PFS).

N.B., the static private key should still be protected to the largest
extent possible, to minimize the risk of impersonations.

Another benefit of EDH is that it allows the backend and clients to
use DSA keys.  DSA keys can only provide digital signatures, not
encryption, and are often acceptable in jurisdictions where RSA keys
are unacceptable.

The downside to EDH is that it makes it impossible to use ssldump(1)
if there's a problem establishing an SSL session.  In this case you'll
need to temporarily disable EDH (see initialize_dh()).