Re: [HACKERS] Possible SSL improvements for a newcomer to tackle

2017-10-04 Thread Zeus Kronion
On Tue, Oct 3, 2017 at 11:39 AM, Nico Williams 
wrote:

> On Tue, Oct 03, 2017 at 12:33:00AM -0400, Tom Lane wrote:
> > So to default to verification would be to default to failing to
> > connect at all until user has created a ~/.postgresql/root.crt file with
> > valid, relevant entries.  That seems like a nonstarter.
> >
> > It's possible that we could adopt some policy like "if the root.crt file
> > exists then default to verify" ... but that seems messy and unreliable,
> > so I'm not sure it would really add any security.
>
> Still, it would be safer to refuse to connect until the lack of trust
> anchors is rectified than to connect without warning about the inability
> to verify a server.  By forcing the user (admins) to take action to
> remediate the problem, the problem then gets fixed, whereas plowing on
> creates an invisible (for many users) security problem.


I agree with Nico. If the server certificate can't be validated, the client
should fail to connect unless specifically opting out of MITM protection.
Why not change DefaultSSLMode from "prefer," even if it isn't backwards
compatible? Is there a policy for deprecating default settings?


[HACKERS] Possible SSL improvements for a newcomer to tackle

2017-10-02 Thread Zeus Kronion
I previously made one minuscule contribution to the project two years ago.
I'm interested in doing some more, and I'm trying to figure out what to
focus on. Two SSL-related projects caught my attention:
1) Allow automatic selection of SSL client certificates from a certificate
store (https://www.postgresql.org/message-id/8766.1241799...@sss.pgh.pa.us).
It seems relatively straightforward to support an additional file format
for key-value pairs in postgresql.crt/.key, and I think this is something I
could take on if it's still desired.
2) I was surprised to learn the following from the docs:

> By default, PostgreSQL will not perform any verification of the server
certificate. This means that it is possible to spoof the server identity
(for example by modifying a DNS record or by taking over the server IP
address) without the client knowing. In order to prevent spoofing, SSL
certificate
verification must be used.

Is there a technical reason to perform no verification by default? Wouldn't
a safer default be desirable?


Re: [HACKERS] WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)

2015-11-05 Thread Zeus Kronion
On Nov 1, 2015 5:04 PM, "Marko Tiikkaja" <ma...@joh.to> wrote:
>
> On 10/25/15 10:55 PM, Zeus Kronion wrote:
>>
>> Parallel workers were failing to connect to the database when running
>> pg_dump with a connection string. The first of the following two commands
>> runs without errors, while the second one fails:
>> pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd
-f
>> my-dump
>> pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd
>> --jobs=9 -f my-dump
>>
>> The error message:
>> pg_dump: [parallel archiver] connection to database "my-db" failed:
>> fe_sendauth: no password supplied
>>
>> The password is not being stored correctly in the PGconn object when
>> connecting with a connection string.
>
>
> Yeah, the current code is definitely broken for this case.  However, I
don't feel like this patch is quite there yet, either.  _connectDB has
similar logic in it which might be hit in case e.g. a a user's HBA is
changed from a non-password-requiring method to a password-requiring one
after the one or more connections has been initiated.  That one needs
changing as well.

I wasn't aware of that case. Should be an easy fix to make this weekend.

> However, I don't quite like the way the password cache is kept up to date
in the old *or* the new code.  It seems to me that it should instead look
like:
>
>if (PQconnectionUsedPassword(AH->connection))
>AH->savedPassword = PQpass(AH->connection);
>
> What do you think?

I don't understand why this logic is preferable. Is your concern that
AH->savedPassword may contain a password even when none is needed? Or is
the change simply meant to give the reader a better sense of what is
actually going on?

-CS


Re: [HACKERS] WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)

2015-10-30 Thread Zeus Kronion
I'm still unclear on how to write regression tests for a connectivity bug.
Are they necessary in this case?

On Sun, Oct 25, 2015 at 5:55 PM, Zeus Kronion <zkron...@gmail.com> wrote:

> Parallel workers were failing to connect to the database when running
> pg_dump with a connection string. The first of the following two commands
> runs without errors, while the second one fails:
> pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd
> -f my-dump
> pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd
> --jobs=9 -f my-dump
>
> The error message:
> pg_dump: [parallel archiver] connection to database "my-db" failed:
> fe_sendauth: no password supplied
>
> The password is not being stored correctly in the PGconn object when
> connecting with a connection string.
>
> This is my first time contributing to Postgres, so I tried to stick to the
> instructions from the "Submitting a Patch" wiki. This submission is for
> discussion because I haven't figured out how to write regression tests for
> this patch yet (and I would appreciate guidance).
>
> Target branch: master
> Compiles and tests successfully: true
> Platform-specific items: none
> Regression tests: still needed
> Documentation: N/A
> Performance implications: none
>


[HACKERS] WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)

2015-10-26 Thread Zeus Kronion
Parallel workers were failing to connect to the database when running
pg_dump with a connection string. The first of the following two commands
runs without errors, while the second one fails:
pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd -f
my-dump
pg_dump "postgres://my-user:my-passw...@my.hostname.com:5432/my-db" -Fd
--jobs=9 -f my-dump

The error message:
pg_dump: [parallel archiver] connection to database "my-db" failed:
fe_sendauth: no password supplied

The password is not being stored correctly in the PGconn object when
connecting with a connection string.

This is my first time contributing to Postgres, so I tried to stick to the
instructions from the "Submitting a Patch" wiki. This submission is for
discussion because I haven't figured out how to write regression tests for
this patch yet (and I would appreciate guidance).

Target branch: master
Compiles and tests successfully: true
Platform-specific items: none
Regression tests: still needed
Documentation: N/A
Performance implications: none


pworker-connection-fix-v1.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers