From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: initdb recommendations |
Date: | 2019-07-22 19:15:21 |
Message-ID: | 12115.1563822921@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-07-22 19:16:32 | Re: initdb recommendations |
Previous Message | Andres Freund | 2019-07-22 17:40:42 | Re: initdb recommendations |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-07-22 19:16:32 | Re: initdb recommendations |
Previous Message | Tom Lane | 2019-07-22 19:02:24 | Re: Broken defenses against dropping a partitioning column |