Re: [HACKERS] Possible SSL improvements for a newcomer to tackle
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
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)
On Nov 1, 2015 5:04 PM, "Marko Tiikkaja" 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)
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 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)
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
