| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Bear Giles <bgiles(at)coyotesong(dot)com> |
| Cc: | pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: 2nd revision of SSL patches |
| Date: | 2002-05-22 00:25:50 |
| Message-ID: | Pine.LNX.4.44.0205211415270.1230-100000@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Bear Giles writes:
> *) 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.
I'm confused. We currently don't have SSL-based authentication, so why do
we have certificates at all?
> *) the client library can handle hardcoded root certificates, to
> avoid the need to copy these files.
Hardcoding is evil.
> *) host name of server cert must resolve to IP address, or be a
> recognized alias. This is more liberal than the previous
> iteration.
Which is the standard/recommended practice?
> *) the number of bytes transferred is tracked, and the session
> key is periodically renegotiated.
Define "periodically".
> *) basic cert generation scripts (mkcert.sh, pgkeygen.sh). The
> configuration files have reasonable defaults for each type
> of use.
Again, what are these certificate management tools for if we don't have
any need for certificates?
About the code:
* no // comments
* no fprintf(stderr, ...) in library functions
* read_SSL/write_SSL -- If you think these functions are misnamed, rename
them.
* Isn't there an automated way to generated error message from error codes
in OpenSSL?
--
Peter Eisentraut peter_e(at)gmx(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2002-05-22 18:28:49 | Re: libpq++ fixes |
| Previous Message | Bear Giles | 2002-05-21 07:36:09 | 2nd revision of SSL patches |