Windows support

[David Woodhouse]

On Wed, 2014-02-12 at 09:35 +0100, Nikos Mavrogiannopoulos wrote:
> On Tue, Feb 11, 2014 at 11:09 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> >> I'm currently looking at just how awful it would be to convert to using
> >> Windows events. It's either that or spawn a thread just to handle the
> >> tun device.
> > All done. Not quite as horrid as I anticipated. And lays the foundation
> > for us supporting epoll() if we really want to, too.
> 
> I guess it wouldn't affect the performance, but if it would be needed,
> wouldn't it make sense to use something cross platform like libev?

I have historically tried to keep the required dependencies of
OpenConnect fairly minimal. Our event handling is simple enough that
abstracting it away (commit 67c6cf51) and then adding Windows support
(commit 1edb49e1) really wasn't that hard or ugly. I'm not sure libev
would buy us that much.

Our event loop basically just waits for *anything* to wake us up, then
runs through *everything* that might need doing, paying no attention to
the actual event(s) which caused the wakeup. If we ever change that,
perhaps we might want something a little more sophisticated. But it
hasn't been necessary so far.

> > I have yet to find an issue with native push/pull functions in the
> > 3.1.16 release.
> 
> If you ship binaries you could simply use a version that works well
> (like the 3.1.16) and simply drop the wrappers.

I don't have much interest in shipping binaries, although if someone
wants to put together an NSI installer it might be interesting.

But if the default build the "easy way" using Fedora's mingw packages is
working (and it *is*, with both mingw32 and mingw64), then that'll be
fine with me. I'm happy enough to stick a pkgconfig check in, just for
Windows, for the known-problematic versions of GnuTLS. If only I knew
for sure which those were... :)

> > Do we have support for using keys in the Windows certificate store?
> 
> Only the trusted CAs are loaded from there. For keys I think that this
> API would work as a smart card so gnutls_privkey_import_ext2() should
> be used (and only the signing function needed). From people that have
> already done it, I was told that you need a signing function similar
> to:
> http://thewalter.net/git/cgit.cgi/p11-capi/tree/module/p11-capi-rsa.c#n180

Hm, interesting.

I note Stef's code is licence-compatible with GnuTLS. It would be very
interesting if we could get proper support for the Windows key store
into GnuTLS natively. And by "we" I don't really mean to do it myself
this time; that's one rathole too far :)

Doing the TPM thing was fun, and I'm glad it's now supported out of the
box in upstream GnuTLS. But really, you've stolen enough of my time in
the last week or two by posting a half-working win32 patch and letting
my OCD kick in and make me finish it off — I really have to do some real
work now :)


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140212/bdc937cc/attachment.bin>