Re: initdb recommendations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb recommendations
Date
Msg-id 12115.1563822921@sss.pgh.pa.us
Whole thread Raw
In response to Re: initdb recommendations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: initdb recommendations  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: initdb recommendations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> BTW, it looks like the Windows buildfarm critters have a
> separate problem: they're failing with
> initdb: error: must specify a password for the superuser to enable md5 authentication

I tried doing a run on gaur (old HPUX, so no "peer" auth) before the
revert happened.  It got as far as initdb-check [1], which failed quite
thoroughly with lots of the same error as above.  Depressingly, a lot of
the test cases that expected some type of error "succeeded", indicating
they're not actually checking to see which error they got.  Boo hiss.

Presumably Noah's AIX menagerie would have failed in about the
same way if it had run.

So we've got a *lot* of buildfarm work to do before we can think about
changing this.

Frankly, this episode makes me wonder whether changing the default is
even a good idea at this point.  People who care about security have
already set up their processes to select a useful-to-them auth option,
while people who do not care are unlikely to be happy about having
security rammed down their throats, especially if it results in the
sort of push-ups we're looking at having to do in the buildfarm.
I think this has effectively destroyed the argument that only
trivial adjustments will be required.

            regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2019-07-22%2017%3A08%3A27



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Broken defenses against dropping a partitioning column
Next
From: Andrew Dunstan
Date:
Subject: Re: initdb recommendations