Re: Securing "make check" (CVE-2014-0067)
От | Noah Misch |
---|---|
Тема | Re: Securing "make check" (CVE-2014-0067) |
Дата | |
Msg-id | 20140330014531.GE170273@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Securing "make check" (CVE-2014-0067) (Christoph Berg <cb@df7cb.de>) |
Ответы |
Re: Securing "make check" (CVE-2014-0067)
|
Список | 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
В списке pgsql-hackers по дате отправления: