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>
