Why should I trust this library to get its crypto right?

[Profpatsch]

I’m currently evaluating for a GNOME project whether I can safely use this library or should rather wrap libotr.

Are there any reference projects (apart from Gajim) that use this library or any peer reviews by security people? Anything that gives me a reason this implementation is as safe as well tested libotr?

[afflux]

This library is basically unmaintained and has never received any kind of public audit or peer review. As far as I'm aware it's only used by the (also unmaintained) gajim-otr from the same author (myself) and weechat-otr. There is a number of open issues around:

https://github.com/python-otr/pure-python-otr/issues/
https://github.com/python-otr/gajim-otr/issues/
https://trac-plugins.gajim.org/query?status=!closed&component=OffTheRecordPlugin

[Profpatsch]

So you have pretty much abandoned it? Would you recommend a wrapper around libotr?

[afflux]

Pretty much. I would not recommend a wrapper around libotr: I had that before I wrote pure-python-otr. The biggest reason to come up with a reimplementation was that libotr has a number of callbacks that execute application code and had no way to handle exceptions in the callbacks. If your python code ended up throwing an exception for whatever reason (out of memory, bugs, ...) you had the choice to either

• return to the lib as if nothing happened
• call abort()

[Profpatsch]

These callbacks were the thing I stumbled into, too.

How about re-initializing otr with the already exchanged keys if that happened? C application code would have the same problem, too, wouldn’t it?

What C wrapping framework did you use? I found ctypes to be a blessing as far as useability goes.

[afflux]

I used swig but that was 5+ years ago and I assume things have changed. Not sure about C applications, it's been a while.

[Profpatsch]

Thanks!

[koolfy]

I'd be willing to help maintain the codebase in my spare time.
Obviously though, I won't be able to tackle that myself alone. I don't think I'd have the python or cryptographic skills, but some people have kindly agreed to review what I would contribute, to help this library survive.

At the very least I should be able to review pull requests, and make sure consequent changes get proprer review from people I know to be knowledgeable before getting merged.

[DrWhax]

I spoke with Koolfy about it on #otr on OFTC that we should do some reviewing against the OTR specification and see if it has any holes in it.

[koolfy]

I'll be maintaining this project the best I can for the forseable future.
Leaving this ticket open as "trust", "review" and "reliability" are still open problems that I can't consider as addressed for now.

This means "don't rely on pure-python-otr just now if you're hesitating".
Hopefully we'll get to this point someday.
Until then there's a lot of work to do.

[dsoprea]

Thank you for picking-up the mantle on this, @koolfy.
On Aug 2, 2014 4:34 PM, "koolfy" [email protected] wrote:

I'll be maintaining this project the best I can for the forseable future.
Leaving this ticket open as "trust", "review" and "reliability" are still
open problems that I can't consider as addressed for now.

This means "don't rely on pure-python-otr just now if you're hesitating".
Hopefully we'll get to this point someday.
Until then there's a lot of work to do.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.