Date: Sat, 3 Mar 2007 14:05:19 +0100 From: Mij <mij@bitchx.it> To: Kris Kennaway <kris@obsecurity.org> Cc: cvs-ports@FreeBSD.org, Cheng-Lung Sung <clsung@FreeBSD.org>, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/security/sshguard Makefile Message-ID: <1C8A6639-A325-46D6-B8C5-A01868780C78@bitchx.it> In-Reply-To: <20070302185318.GA30351@xor.obsecurity.org> References: <200703011006.l21A6EKZ036332@repoman.freebsd.org> <20070302164917.GA28444@xor.obsecurity.org> <44226B29-C2D1-4CF9-A0F9-FC661D5691C5@bitchx.it> <20070302185318.GA30351@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/mar/07, at 19:53, Kris Kennaway wrote: > On Fri, Mar 02, 2007 at 07:49:42PM +0100, Mij wrote: >> >> On 02/mar/07, at 17:49, Kris Kennaway wrote: >> >>> On Thu, Mar 01, 2007 at 10:06:14AM +0000, Cheng-Lung Sung wrote: >>>> clsung 2007-03-01 10:06:14 UTC >>>> >>>> FreeBSD ports repository >>>> >>>> Modified files: >>>> security/sshguard Makefile >>>> Log: >>>> - respect maintainer's insist on interactive part, >>>> even IS_INTERACTIVE is discouraged >> >> not glad to see such comment >> >> >>> This is disappointing. Can the maintainer explain why? >> >> the app requires the user to choose what firewall to support for >> building: IPFW or PF. >> They are in XOR and there is no reasonable default in this. >> >> Cheng-Lung chose PF default and removed is_interactive. >> A feedback request would have avoided this qui pro quo. > > IS_INTERACTIVE should *never* be used when there is a possible > alternative. please include this dogma at some point in http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ > The obvious choice here (if you really cannot decide on > a default) is to make your port in two variants, one a slave of the > other, which enable either option. I see three possibilities *) defaults do we have any data showing that PF (or IPFW) covers 95%+ of the users? or do we have any other reason to say that defaulting to PF (or IPFW) will work on all/most setups? If we don't, no defaults make sense *) variants while this seems the best approach, new protection mechanisms will appear in the future. This would bring a lot pollution of security/sshguard- * variants in the long run. E.g., version 1 has two more backends underway. Moreover, a default could actually happen in the future, one mechanism that works on all setups given some other compromise (e.g. hosts.allow). *) autodetection the port could check itself for what backend to use. E.g. look in / etc/rc.conf for pf_* or firewall_* . If none of the possibilities are detected, however, the problem falls back to the one of defaults. In the end, I think this port requires interaction. If some of you has more suggestions, they are welcome. In the meantime, as we've come to subtle details of the port, I will stop copying to cvs-* people for the next messages. bye mm >>> And what is this? :) >> >> this used to be ".error blah" for checking the options' XOR-ness, >> then removed because >> options are also set when deinstalling/cleaning etc. Definitely >> useless, replacing with a >> comment about the problem appears the best to do. Actually I dunno >> why this made its way >> in the submission :) > > OK, I assume you'll fix this? > > Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1C8A6639-A325-46D6-B8C5-A01868780C78>