Re: Git cvsserver serious issue
От | Magnus Hagander |
---|---|
Тема | Re: Git cvsserver serious issue |
Дата | |
Msg-id | AANLkTikP1ggZzAHSoVA3cF=uL8koCye7znmEOwCWu1R8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Git cvsserver serious issue (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Git cvsserver serious issue
Re: Git cvsserver serious issue |
Список | pgsql-hackers |
On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan <andrew@dunslane.net> wrote: > > > On 10/07/2010 03:37 PM, Magnus Hagander wrote: >> >> On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan<andrew@dunslane.net> wrote: >>> >>> On 10/07/2010 10:11 AM, Magnus Hagander wrote: >>>>>< >>>>> OTOH, this patch seems pretty small and simple to maintain. >>>> >>>> True, it is rather small. >>>> >>>> Does anybody know if there's an automated way to maintain that on >>>> freebsd ports, and if so, how that works? I want to be *sure* we can't >>>> accidentally upgrade git-cvsserver *without* the patch, since that is >>>> a security issue. >>>> >>> Why not just make a local copy somewhere else and patch and run that? >>> It's >>> just a Perl script, no? >> >> Yeah, but then we have to remember to manually patch that one when >> somebody *else* finds/fixes a security issue. We have automatic >> monitoring on the ports stuff to detect when that happens.. > > There's a simpler solution which I have just tested. Instead of patching, > use the Pg driver instead of SQLite. Set the dbname to %m. If the database > doesn't exist the cvs checkout will fail. So we just set up databases for > the modules we want to export (master and RELn_m_STABLE for the live > branches). A database per branch seems like a horrible idea in general, but if it works us around the bug, it seems like a doable idea.. As long as we'll never have a branch called "postgres" or "git" (already in use on that box). I'll look into it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: