ports/105488: [patch] security/ipsec-tools: NAT-T support silently ignored if header file unpatched
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Fri Nov 17 20:05:19 UTC 2006
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.
> 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.
> 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
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.
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.
One more time: a single checkbox is yes/no but not maybe.
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
More information about the freebsd-ports-bugs