| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Christoph Berg <cb(at)df7cb(dot)de>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Subject: | Re: Securing "make check" (CVE-2014-0067) |
| Date: | 2014-03-30 01:45:31 |
| Message-ID: | 20140330014531.GE170273@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote:
> Fwiw, to relocate the pg_regress socket dir, there is already the
> possibility to run make check EXTRA_REGRESS_OPTS="--host=/tmp". (With
> the pending fix I sent yesterday to extend this to contrib/test_decoding.)
That doesn't work for "make check", because the postmaster ends up with
"listen_addresses=/tmp".
> We've been putting a small patch into pg_upgrade in Debian to work
> around too long socket paths generated by pg_upgrade during running
> the testsuite (and effectively on end user systems, but I don't think
> anyone is using such long paths there).
>
> A similar code bit could be put into pg_regress itself.
Thanks for reminding me about Debian's troubles here. Once the dust settles
on pg_regress, it will probably make sense to do likewise to pg_upgrade.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-03-30 03:56:42 | Re: Fwd: Proposal: variant of regclass |
| Previous Message | Jeff Janes | 2014-03-29 23:10:10 | Re: [RFC] What should we do for reliable WAL archiving? |