ports/105488: [patch] security/ipsec-tools: NAT-T support silently ignored if header file unpatched

[VANHULLEBUS Yvan]

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