Add TOTP (RFC6238) one-time password support

[David Woodhouse]

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>