Re: Securing "make check" (CVE-2014-0067)
От | Noah Misch |
---|---|
Тема | Re: Securing "make check" (CVE-2014-0067) |
Дата | |
Msg-id | 20140302052022.GC3407963@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Securing "make check" (CVE-2014-0067) (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Securing "make check" (CVE-2014-0067)
Re: Securing "make check" (CVE-2014-0067) Re: Securing "make check" (CVE-2014-0067) |
Список | pgsql-hackers |
On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote: > On 03/01/2014 05:10 PM, Tom Lane wrote: > >One other thought here: is it actually reasonable to expend a lot of effort > >on the Windows case? I'm not aware that people normally expect a Windows > >box to have multiple users at all, let alone non-mutually-trusting users. > > As Stephen said, it's fairly unusual. There are usually quite a few > roles, but it's rare to have more than one "human" type role > connected to the machine at a given time. I, too, agree it's rare. Rare enough to justify leaving the vulnerability open on Windows, indefinitely? I'd say not. Windows itself has been pushing steadily toward better multi-user support over the past 15 years or so. Releasing software for Windows as though it were a single-user platform is backwards-looking. We should be a model in this area, not a straggler. > I'd be happy doing nothing in this case, or not very much. e.g. > provide a password but not with great cryptographic strength. One option that would simplify things is to fix only non-Windows in the back branches, via socket protection, and fix Windows in HEAD only. We could even do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes. Using weak passwords on Windows alone would not simplify the effort. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: