Patches for Review (security/vpnc)

[David Woodhouse]

These mostly look good; thanks. Please could I have each with a
'Signed-off-by:' tag? See the 'Submitting Patches' section of
http://www.infradead.org/openconnect/contribute.html for more background
on that (and exactly what you're agreeing to).

On Thu, 2012-06-14 at 02:05 -0400, Jason Hellenthal wrote:
> r2 | jh | 2012-06-14 01:14:16 -0400 (Thu, 14 Jun 2012) | 4 lines
> ASCII'fy the copyrights section. less(1) and other tools see it as
> binary.

I'd rather not do this; I'd rather you file bugs against the tools which
see it as binary.

We're over a decade into the 21st century now; ∄ excuse for still using
EBCDIC, 7-bit ASCII or other legacy nonsense. Anyone who isn't operating
a policy of "everything on my system is UTF-8 as far as possible,
converted from legacy crap on the way in and begrudgingly converted to
legacy crap on the way out *only* if we really must" is asking for
trouble and mislabelled text.

As long as this is only a cosmetic issue — and I think it is — I'd
really prefer it to stay as it is.

If it annoys someone with broken tools or who is living in the 20th
century, then that's just fine by me ☺

Btw, I *would* accept patches to openconnect itself, to convert UTF-8
banners and prompts that we receive from the server into legacy crap for
local display. You could still call that a "cosmetic" issue, I suppose,
but it's an issue that actually affects the *user*, if they have a
legacy local encoding and the server is giving non-ASCII in its prompts.

> r3 | jh | 2012-06-14 01:25:31 -0400 (Thu, 14 Jun 2012) | 13 lines

> Adjust checking for if_tun to use kldstat(8) in place of /dev/tun
> While here kldload if_tun.ko quietly (-q)

Sounds good, and ISTR seeing a discussion in which it was confirmed that
this worked when if_tun was built in to the kernel statically too?
I'm going to defer entirely to you on the "back to 7.x and possibly
further" bit, and assume that it's reasonable not to care if there are
people with older systems on which this doesn't work?

Changes here tend to get merged into upstream vpnc too, so if there's an
ancient FreeBSD user who *does* happen to rebuild upstream vpnc for
security fixes, perhaps it'll break for them? I'm fine with not caring
about that if you (collectively, assuming my mail makes it to the ports@
list) are.

> r4 | jh | 2012-06-14 01:42:30 -0400 (Thu, 14 Jun 2012) | 11 lines
> 
> Interface creation and deletion should be handled directly by vpnc and
> return status should be handed back over to the script for
> negotiation.

Would be very nice if someone who knows the intimate details of FreeBSD
tunnel devices could respond to my outstanding queries about this. If we
can make the device go away automatically when its fd is closed, like we
can on all other systems, that would be best.

> For now comment out the implicit tunnel deletion function until it can
> be reworked.

I think we still need destroy_tun_device to run on NetBSD. Can you
comment out just the FreeBSD part of the case statement in
destroy_tun_device() instead?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120614/db531a82/smime-0001.bin