cvs commit: ports/security/sshguard Makefile
mij at bitchx.it
Sat Mar 3 13:05:23 UTC 2007
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
>>>> - 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
please include this dogma at some point in
> 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
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)
on all/most setups?
If we don't, no defaults make sense
while this seems the best approach, new protection mechanisms will
in the future. This would bring a lot pollution of security/sshguard-
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).
the port could check itself for what backend to use. E.g. look in /
for pf_* or firewall_* . If none of the possibilities are detected,
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
to cvs-* people for the next messages.
>>> 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?
More information about the cvs-ports