On Sat, Mar 01, 2014 at 12:29:38PM -0500, Tom Lane wrote: > There are two big problems with the lets-generate-a-random-password > approach. Noah acknowledged the portability issue of possibly not having > a strong entropy source available. The other issue though is whether > doing this doesn't introduce enough crypto dependency into the core code > to create an export-restrictions hazard. We've kept contrib/pgcrypto > out of core all these years in order to give people a relatively > straightforward solution if they are worried about export laws: just omit > contrib/pgcrypto. But "just omit regression testing" isn't palatable.
If pgrand.c poses an export control problem, then be-secure.c poses a greater one. pgrand.c is just glue to an OS-provided CSPRNG. > In the case of Unix systems, there is a *far* simpler and more portable > solution technique, which is to tell the test postmaster to put its socket > in some non-world-accessible directory created by the test scaffolding. > > Of course that doesn't work for Windows, which is why we looked at the > random-password solution. But I wonder whether we shouldn't use the > nonstandard-socket-location approach everywhere else, and only use random > passwords on Windows. That would greatly reduce the number of cases to > worry about for portability of the password-generation code; Further worrying about systems lacking /dev/urandom is a waste of time. They will only get less common, and they are already rare enough that we have zero of them on the buildfarm. I provided them with a straightforward workaround: point the PGTESTPWFILE environment variable to a file containing a password. Having that said, I can appreciate the value of tightening the socket mode for a bit of *extra* safety: --- a/src/test/regress/pg_regress.c +++ b/src/test/regress/pg_regress.c @@ -2299,4 +2299,5 @@ regression_main(int argc, char *argv, init_function ifunc, test_function tfunc fputs("\n# Configuration added by pg_regress\n\n", pg_conf); fputs("max_prepared_transactions = 2\n", pg_conf); + fputs("unix_socket_permissions = 0700\n", pg_conf); Taking the further step of retaining trust authentication on Unix would make it easier to commit tests guaranteed to fail on Windows. I see no benefit cancelling that out. > and perhaps > we could also push the crypto issue into reliance on some Windows-supplied > functionality (though I'm just speculating about that part). Every version of the patch has done it that way. It has used OS-supplied cryptography on every platform. nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers