On Thu, 2014-08-14 at 14:45 +0100, David Woodhouse wrote: > On Thu, 2014-08-14 at 13:37 +0200, Simon Josefsson wrote: > > Thanks for the bug report! > > > > I'm a little uncertain how well the proposed patch works. What happens > > if you call pskc_build_xml() multiple times? > > If you call pskc_build_xml() multiple times, we can throw away the > xmlDoc that's created each time (apart from the latest). Nothing points > *into* those. > > It's only the original xmlDoc from pskc_parse_from_memory() that needs > to be kept around, because the individual fields in the pskc_t container > structure (e.g. container->id) will be pointing into it. > > So in pskc_build_xml() we free the old container->xmldoc but only if it > *isn't* equal to container->original_xmldoc. > > https://bugzilla.redhat.com/show_bug.cgi?id=1129491#c1 is probably the > nicer approach, *changing* the pointers to point into the new xmlDoc > instead of having to keep the original one around. But needs more work.
Ping. It would be nice to have a new release with this fixed, and SHA256 support. Although I'm very sad my application is going to need to *know* about SHA256 support and jump through lots of compatibility hoops to optionally support it with newer liboath. All I want is a function that will "generate a token code from <this> PSKC file and update the file as necessary, with appropriate file locking, if it's HOTP". And then SHA256 would have Just Worked™. :( -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
