cvs commit: ports/security/sshguard Makefile

Kris Kennaway kris at obsecurity.org
Sat Mar 3 20:32:05 UTC 2007


On Sat, Mar 03, 2007 at 02:05:19PM +0100, Mij wrote:

> >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/

You mean like in section 4.6? :)

> 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

ipfw is historically very commonly used but pf has gained popularity
in recent years.

> *) 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).

What you call "pollution" others call "ease of use".  e.g. your port
could be added easily with pkg_add -r.  Right now there is no way a
user (pf or ipfw) can obtain your package without compiling it.

Your objection of proliferation of options doesn't carry much weight:
there is no need to add a variant for every possible build
configuration, only the popular ones.  As with every other
customizable port in the collection, users who wish to customize with
non-default options can build it themselves.  The issue is providing a
reasonable default set of packages covering the common situations.

> *) 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.

This won't work on package builds.

> In the end, I think this port requires interaction.

You are probably the only port maintainer in recent memory who has
come to this conclusion when faced with such a choice.  I'd invite you
to reflect on that and consider how you can come to an accomodation
with the rest of us :)

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20070303/772cce86/attachment.pgp


More information about the cvs-all mailing list