On Sat, 2012-09-29 at 20:29 -0700, Kevin Cernekee wrote: > David W, > > I was wondering if I could get your opinion on a couple of items > mentioned in TODO, contribute.xml, and nonroot.xml: > > 1) SecurID integration - is it your current line of thinking that > SecurID tokencode input should just be handled via "--passwd-on-stdin" > (possibly autogenerated by an external program), or did you still want > to explore the idea of adding the tokencode calculation right into > OpenConnect? The --passwd-on-stdin option doesn't work for that. Sometimes, SecurID authentication will ask you for *two* codes in succession, and there's also a delay between the program being spawned and the SecurID code being required. That could be a long time if it's waiting for the user to accept an unknown SSL certificate, for example. I'd really like to see a proper implementation of the SecurID algorithm in a (separate) library. We know how the old 64-bit one works, and it really shouldn't be that hard to work out how the new 128-bit AES-based one works either. Then hook it in to OpenConnect to generate a code when needed. We no longer use SecurID here, so this isn't a high priority for me. > 2) lwIP SOCKS proxy - do you think it is a good idea to add David > Edmondson's ocproxy/ocvpn (or a reasonable facsimile) to the main > OpenConnect repo, possibly under a contrib/ directory? Or is this > better off living as a separate project? It's not OpenConnect-specific, so I think I'd prefer it to be in a separate repository. It'd be good to get vpnc and other clients working with it at some point. But definitely we should document its use and link to it from the OpenConnect web site. > 3) "Better support for Cisco Secure Desktop" - were you thinking in > terms of creating a fully open source CSD clone, bundling a script > that merely spoofs the "good" response, or something else? I don't really know, to be honest. Best phrased as 'do something that makes me less queasy about the whole thing'. Some kind of tool which lets you run it in isolation and work out what it's doing when it goes wrong would be nice. It does go wrong quite often. And yeah, being able to capture a 'good' response from a successful run and then just post that in future would also be good. I'm not sure a full clone makes a huge amount of sense, although it would be cute. Perhaps the set of things it tests on Linux is small enough that it *isn't* a completely insane proposition to implement and keep up to date? -- 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.infradead.org/pipermail/openconnect-devel/attachments/20120930/e2975b55/attachment.bin>
