From owner-freebsd-ports-bugs@FreeBSD.ORG Mon Nov 20 20:56:16 2006 Return-Path: X-Original-To: freebsd-ports-bugs@FreeBSD.org Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6294F16A51B for ; Mon, 20 Nov 2006 20:56:16 +0000 (UTC) (envelope-from yvan.vanhullebus@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id A695643E1C for ; Mon, 20 Nov 2006 20:55:34 +0000 (GMT) (envelope-from yvan.vanhullebus@netasq.com) Received: from [10.2.0.2] (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 2116F232CE; Mon, 20 Nov 2006 21:55:49 +0100 (CET) Received: by darkstar.netasq.com (Postfix, from userid 1001) id 90E5AF7A3A; Mon, 20 Nov 2006 21:56:17 +0100 (CET) Date: Mon, 20 Nov 2006 21:56:17 +0100 From: VANHULLEBUS Yvan To: "Bjoern A. Zeeb" Message-ID: <20061120205617.GA45898@darkstar.netasq.com> References: <200611160930.kAG9UB8Q023235@freefall.freebsd.org> <20061117194616.A18512@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061117194616.A18512@maildrop.int.zabbadoz.net> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/105488: [patch] security/ipsec-tools: NAT-T support silently ignored if header file unpatched X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2006 20:56:16 -0000 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