On Thu, 2013-03-07 at 16:19 -0800, Kevin Cernekee wrote: > On Thu, Mar 7, 2013 at 3:55 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > > On Thu, 2013-03-07 at 18:39 -0500, John Morrissey wrote: > >> - openconnect_set_stoken_mode no longer accepts the use_stoken argument > >> and instead always tries to initialize libstoken when called. This > >> makes sense in openconnect(8), but I'm not sure how much of a concern > >> this API change is for upstream consumers of libopenconnect. I also > >> wasn't sure how to account for this in libopenconnect.map.in. > > Would it be useful to allow the library user to disable token > generation, e.g. for retrying after a failed attempt? > > Or should we just ask them to tear down the context and start fresh > with a new one? I think in most cases they're just going to abort and declare the world is broken anyway; they're not going to retry it *either* way. > I sent a few network-manager-openconnect patches a while back: > > https://github.com/cernekee/network-manager-openconnect/commits/stoken-v2 > > I don't see them on git.gnome.org; I can rework them to use the latest > APIs and resubmit. Hm. Mea culpa, probably. Please do, and I'll try to make sure I pull them this time. > OK, so they want ./configure to fail if libstoken is missing, unless > --disable-stoken was explicitly specified? I think they'd settle for being able to use --disable-stoken to ensure that they *never* get stoken support, even if libstoken is present. > Should libproxy work the same way? Please :) -- 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/20130308/72ab1aca/attachment.bin>
