ports/105488: [patch] security/ipsec-tools: NAT-T support silently ignored if header file unpatched
yvan.vanhullebus at netasq.com
Mon Nov 20 20:56:16 UTC 2006
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
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
> 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
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?
> 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.
More information about the freebsd-ports-bugs