Date: Mon, 20 Nov 2006 21:56:17 +0100 From: VANHULLEBUS Yvan <yvan.vanhullebus@netasq.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/105488: [patch] security/ipsec-tools: NAT-T support silently ignored if header file unpatched Message-ID: <20061120205617.GA45898@darkstar.netasq.com> In-Reply-To: <20061117194616.A18512@maildrop.int.zabbadoz.net> References: <200611160930.kAG9UB8Q023235@freefall.freebsd.org> <20061117194616.A18512@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 17, 2006 at 08:03:49PM +0000, Bjoern A. Zeeb wrote: > On Thu, 16 Nov 2006, VANHULLEBUS Yvan wrote: > > >> People who won't care don't need it and would leave it to default > >> which is off anyway so that case does not matter. > > > >When this option has been included, I guessed integrating NAT-T > >support in FreeBSD's CVS would be quite fast, so I put the default to > >easy migration when it will be included, even for people who don't > >know what NAT-T means (but which may still need). > > if you do not know it you do not need it; it's a security feature and > not an item on a wishlist for free birthday presents. IPSec is a security feature. NAT-T is "just" an extension, and *is* just an item on some people's whishlist ! Btw, this was just to remember the situation quite a year ago. > >But now lots of people have WITH_NATT=3Dtrue in their > >/var/db/ports/ipsec-tools file, we can't just apply the patch you > >provided, as it would break ipsec-tools compilation for all people > >that don't know what NAT-T is, and who don't know the patch's > >existence. > > and what would that mean? They would actively have to decided if they > really need it or not and find out what it is about. > This is about security and not disco fun. No, they would just see that "ipsec-tools is broken and does not compile anymore". And I don't want basic ipsec-tools upgrade to be broken for people that just don't know what "NAT-T" means, or don't know how to patch/recompile a custom kernel, or perhaps just don't know how to go back to the options menu in a port. > >Of course, the best long term solution will be to have NAT-T support > >officially integrated in FreeBSD......... > > and it would make no difference if you provide a yes/no option. > Just that people wouldn't need to patch their system for the yes case > anymore. If the "yes / force" option works on a vanilla system, it is ok for me to assume "yes" to "break if no support". But even in that case, we'll have the problem of old systems with fresh ports..... > Remember that thread from September? > http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011855.html > It helped two people who weren't aware of the "maybe" problem. They > had enabled the option and not gotten the support in ipsec-tools. If you can generate a patch which explicitely provide a "yes and break if no support found" (aka enable-natt=yes), but keeps the "kernel" mode as default for people who already have installed ipsec-tools, and have WITH_NATT=true in their /var/db/ports/ipsec-tools, I'll be very happy to approve it. But I'll refuse any patch which may break things for people who don't know at all (and I don't consider newbies who are trying to have NAT-T support as "people who don't know at all"). > Since then I had helped several more people who had packaged > ipsec-tools for other boxes and afterwards complained that nat-t was > not working though they had turned it on in ipsec-tools. > It's is always painful to discover what's going on, them then > re-building their build framework, re-create an image, re-deploy > things, ... It would have saved them lots of time if they - by the > first time - had been told directly by a build failure of the port > that nat-t will not work after they had manually turned on an option > that defaults to no. I understand that. > One more time: a single checkbox is yes/no but not maybe. One more time: there are aleady lots of people who have a /var/db/ports/ipsec-tools, and I don't want to break things for them. Yvan. -- NETASQ http://www.netasq.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061120205617.GA45898>