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? > You can't account for it. It's an ABI break and it would take us to > libopenconnect.so.3. I'd like to avoid this change, if possible. > > Admittedly, I don't think anyone is *using* the existing functions from > a GUI; I certainly haven't seen any NetworkManager-openconnect patches > go by which implement stoken support there. But that isn't really the > point. There are consumers of this library that I *don't* keep a close > eye on, like kde-plasma-networkmanagement and Shimo. 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. > I've already received complaints about the way that stoken support is > automatically built if libstoken is present, and silently omitted if > not. It would be nice to have a --disable-oath argument to configure: > http://www.gentoo.org/proj/en/qa/automagic.xml OK, so they want ./configure to fail if libstoken is missing, unless --disable-stoken was explicitly specified? Should libproxy work the same way?
