From chrisballinger at gmail.com  Fri Aug 12 20:36:41 2011
From: chrisballinger at gmail.com (Chris Ballinger)
Date: Fri, 12 Aug 2011 20:36:41 -0400
Subject: [OTR-dev] Open source OTR AIM client for iOS
Message-ID: <CAG7SQq4RGCjiYM10wXnn+gMNq-J9iCfGt1R4FP+wbj598mT11w@mail.gmail.com>

https://github.com/chrisballinger/Off-the-Record-iOS

After a lot of wrangling I was able to hack together a working AIM OTR
client for iOS devices. Clearly it's in a rough state at the moment, but it
is functional for testing purposes. Let me know what you think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110812/377c7f6c/attachment.htm>

From nathan at guardianproject.info  Sat Aug 13 07:47:34 2011
From: nathan at guardianproject.info (Nathan of Guardian)
Date: Sat, 13 Aug 2011 07:47:34 -0400
Subject: [OTR-dev] Open source OTR AIM client for iOS
In-Reply-To: <CAG7SQq4RGCjiYM10wXnn+gMNq-J9iCfGt1R4FP+wbj598mT11w@mail.gmail.com>
References: <CAG7SQq4RGCjiYM10wXnn+gMNq-J9iCfGt1R4FP+wbj598mT11w@mail.gmail.com>
Message-ID: <4E466456.7080600@guardianproject.info>

On 08/12/2011 08:36 PM, Chris Ballinger wrote:
> After a lot of wrangling I was able to hack together a working AIM OTR
> client for iOS devices. Clearly it's in a rough state at the moment, but
> it is functional for testing purposes. Let me know what you think.

Nice work, Chris! The next time I boot up my Mac dev station, I will
pull down the code and see how it builds/runs.

I am one of the developers of Gibberbot, the Android OTR/XMPP client,
and we have been waiting for someone to pick up the iOS mantle.

Any thoughts on supporting LibPurple, in order to support Jabber, GTalk,
etc?

+n8fr8

From donny.viszneki at gmail.com  Mon Aug 15 09:47:52 2011
From: donny.viszneki at gmail.com (Donny Viszneki)
Date: Mon, 15 Aug 2011 09:47:52 -0400
Subject: [OTR-dev] Open source OTR AIM client for iOS
In-Reply-To: <CAG7SQq4RGCjiYM10wXnn+gMNq-J9iCfGt1R4FP+wbj598mT11w@mail.gmail.com>
References: <CAG7SQq4RGCjiYM10wXnn+gMNq-J9iCfGt1R4FP+wbj598mT11w@mail.gmail.com>
Message-ID: <CAMrNWp1M09iULbFHrfvY7Dc80kC-11g4SXxHi9VThzcAd1MUDg@mail.gmail.com>

lol... dunno who you think any iOS device is safe from!

On Fri, Aug 12, 2011 at 8:36 PM, Chris Ballinger
<chrisballinger at gmail.com> wrote:
> https://github.com/chrisballinger/Off-the-Record-iOS
> After a lot of wrangling I was able to hack together a working AIM OTR
> client for iOS devices. Clearly it's in a rough state at the moment, but it
> is functional for testing purposes. Let me know what you think.
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>



-- 
http://codebad.com/

From stpeter at stpeter.im  Wed Aug 17 10:11:45 2011
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 17 Aug 2011 08:11:45 -0600
Subject: [OTR-dev] Fwd: [jdev] OTR (was: Re:  State of the XMPP Clients?)
In-Reply-To: <4E4BC8AD.1060705@stpeter.im>
References: <4E4BC8AD.1060705@stpeter.im>
Message-ID: <4E4BCC21.2030405@stpeter.im>

FYI. I'm working to get more Jabber developers interested in OTR. :)

-------- Original Message --------
Subject: [jdev] OTR (was: Re:  State of the XMPP Clients?)
Date: Wed, 17 Aug 2011 07:57:01 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: Jabber/XMPP software development list <jdev at jabber.org>
To: Jabber/XMPP software development list <jdev at jabber.org>

On 8/16/11 7:08 PM, Andreas Monitzer wrote:
> On Dienstag, 16. August 2011 at 23:30, Peter Saint-Andre wrote:
>> Don't forget OTR, too (I might be working on an Internet-Draft
>> about that with some of the OTR folks):
>>
>> http://www.cypherpunks.ca/otr/
>
> I know about OTR, but I don't like the standard. Due to its
> transport-independence, it doesn't integrate at all into XMPP. For
> example, there's no discovery for it. The client determines support
> at the other side by sending encrypted text and waiting whether a
> "wtf" by an irritated/confused human or a proper OTR response comes
> back.

Yes, that's an ugly hack, which is needed to work around the lack of
discovery protocols in systems like AIM and Yahoo. However, in XMPP we
have ways to discover feature support (service discovery and entity
capabilities), so it seems to me that we can define an XMPP feature for
OTR (properly versioned because OTRv3 is on the way) and simply ignore
the hacky text stuff.

> It also takes over the regular<body/>-tag for its binary data
> instead of using a proper separate tag with its own namespace (like
> xhtml-im).

On this point, I think we can work with the OTR team to define an XMPP
binding in OTRv3 or (more likely) OTRv4. The XMPP binding would be more
consistent with the Tao of Jabber, and if you're using AIM or Yahoo or
whatever then you'd default to stuffing all the data in the message
body. The XMPP binding would also enable us to perform whole-stanza
encryption for all stanza types (think Jingle negotiation and such),
instead of just the <body/> element of the <message/> stanza.

> Further, the library's LGPL license is incompatible with Apple's App
> Store, and so I'd have to implement it on my own?

Multiple implementations might be a good thing. :) The XSF might even be
able to provide funding for folks to work on a common library (BSD or
MIT licensed) that can be used by a wide variety of clients.

> At least the spec
> seems to be fairly detailed.

Yes.

More than that, OTR just works [tm]. We've had debates for many years
about PGP, S/MIME, SIGMA-based encrypted sessions, XTLS, etc. But for as
long as we've been having these interminable discussions, OTR has
quietly been working in the real world -- field tested by thousands of
users in a wide variety of clients, and seemingly resistant to attacks.

Instead of trying to invent something new, why don't we use something
that has plenty of running code behind it?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________

From nathan at guardianproject.info  Wed Aug 17 19:04:01 2011
From: nathan at guardianproject.info (Nathan of Guardian)
Date: Wed, 17 Aug 2011 19:04:01 -0400
Subject: [OTR-dev] Fwd: [jdev] OTR
In-Reply-To: <4E4BCC21.2030405@stpeter.im>
References: <4E4BC8AD.1060705@stpeter.im> <4E4BCC21.2030405@stpeter.im>
Message-ID: <4E4C48E1.6010903@guardianproject.info>


Can you let them know that the use of the "Whitespace Tag" is indeed a
way to support discovery without causing the WTF moment described below?
This is something we support in Gibberbot on Android.

Whitespace Tag:

    There is an OTR_MESSAGE_TAG, which is a 24-byte string of whitespace
    that clients can optionally append to (or insert in) messages to
    unobtrusively indicate that they understand the OTR protocol.  The
    string is as follows (in C notation):

	\x20\x09\x20\x20\x09\x09\x09\x09
	\x20\x09\x20\x09\x20\x09\x20\x20
	\x20\x09\x20\x09\x20\x20\x09\x20

    [This is the bit pattern of the string "OTR" as expressed in spaces and
    tabs.]




On 08/17/2011 10:11 AM, Peter Saint-Andre wrote:
> FYI. I'm working to get more Jabber developers interested in OTR. :)
> 
> -------- Original Message --------
> Subject: [jdev] OTR (was: Re:  State of the XMPP Clients?)
> Date: Wed, 17 Aug 2011 07:57:01 -0600
> From: Peter Saint-Andre <stpeter at stpeter.im>
> Reply-To: Jabber/XMPP software development list <jdev at jabber.org>
> To: Jabber/XMPP software development list <jdev at jabber.org>
> 
> On 8/16/11 7:08 PM, Andreas Monitzer wrote:
>> On Dienstag, 16. August 2011 at 23:30, Peter Saint-Andre wrote:
>>> Don't forget OTR, too (I might be working on an Internet-Draft
>>> about that with some of the OTR folks):
>>>
>>> http://www.cypherpunks.ca/otr/
>>
>> I know about OTR, but I don't like the standard. Due to its
>> transport-independence, it doesn't integrate at all into XMPP. For
>> example, there's no discovery for it. The client determines support
>> at the other side by sending encrypted text and waiting whether a
>> "wtf" by an irritated/confused human or a proper OTR response comes
>> back.
> 
> Yes, that's an ugly hack, which is needed to work around the lack of
> discovery protocols in systems like AIM and Yahoo. However, in XMPP we
> have ways to discover feature support (service discovery and entity
> capabilities), so it seems to me that we can define an XMPP feature for
> OTR (properly versioned because OTRv3 is on the way) and simply ignore
> the hacky text stuff.
> 
>> It also takes over the regular<body/>-tag for its binary data
>> instead of using a proper separate tag with its own namespace (like
>> xhtml-im).
> 
> On this point, I think we can work with the OTR team to define an XMPP
> binding in OTRv3 or (more likely) OTRv4. The XMPP binding would be more
> consistent with the Tao of Jabber, and if you're using AIM or Yahoo or
> whatever then you'd default to stuffing all the data in the message
> body. The XMPP binding would also enable us to perform whole-stanza
> encryption for all stanza types (think Jingle negotiation and such),
> instead of just the <body/> element of the <message/> stanza.
> 
>> Further, the library's LGPL license is incompatible with Apple's App
>> Store, and so I'd have to implement it on my own?
> 
> Multiple implementations might be a good thing. :) The XSF might even be
> able to provide funding for folks to work on a common library (BSD or
> MIT licensed) that can be used by a wide variety of clients.
> 
>> At least the spec
>> seems to be fairly detailed.
> 
> Yes.
> 
> More than that, OTR just works [tm]. We've had debates for many years
> about PGP, S/MIME, SIGMA-based encrypted sessions, XTLS, etc. But for as
> long as we've been having these interminable discussions, OTR has
> quietly been working in the real world -- field tested by thousands of
> users in a wide variety of clients, and seemingly resistant to attacks.
> 
> Instead of trying to invent something new, why don't we use something
> that has plenty of running code behind it?
> 
> Peter
> 


From aaron.toponce at gmail.com  Thu Aug 18 08:16:19 2011
From: aaron.toponce at gmail.com (Aaron Toponce)
Date: Thu, 18 Aug 2011 06:16:19 -0600
Subject: [OTR-dev] OTR support for Gajim
Message-ID: <20110818121619.GA23214@poseidon.cocyt.us>

According to http://trac.gajim.org/wiki/OTR, the OTR API is crap, and
implementing it into a project seems to be somewhat of a chore. I would
like to see OTR support built into Gajim, but it appears to be a deadend.
As the article states, you can see the code he ripped out from the commit
message here: http://trac.gajim.org/changeset/ef7496ee5eb2/.

Thankfully, it appears that Gajim will be supporting a plugin architecture,
and an OTR plugin looks likely. See http://gajim-otr.pentabarf.de/.
Currently, the only end-to-end encryption for Gajim, is using OpenPGP keys,
which digitally sign every message, which isn't optimal.

So, is OTR v4 being worked on? Is the claim that the current API sucks
accurate? It seems other projects, such as Pidgin and Bitlbee have
implemented OTR just fine, so maybe the core devs either have issues with
the Gajim code, or the OTR code that was written just sucked.

Thoughts?

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL: </pipermail/otr-dev/attachments/20110818/cecd4968/attachment.pgp>

From pesco at khjk.org  Thu Aug 18 08:42:12 2011
From: pesco at khjk.org (Sven Moritz Hallberg)
Date: Thu, 18 Aug 2011 14:42:12 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <20110818121619.GA23214@poseidon.cocyt.us>
References: <20110818121619.GA23214@poseidon.cocyt.us>
Message-ID: <874o1ehowr.fsf@atomzentrale.khjk.org>

On Thu, 18 Aug 2011 06:16:19 -0600, Aaron Toponce <aaron.toponce at gmail.com> wrote:
> According to http://trac.gajim.org/wiki/OTR, the OTR API is crap, and
> implementing it into a project seems to be somewhat of a chore. I would
> like to see OTR support built into Gajim, but it appears to be a deadend.
> As the article states, you can see the code he ripped out from the commit
> message here: http://trac.gajim.org/changeset/ef7496ee5eb2/.
> 
> [...]
>
> So, is OTR v4 being worked on? Is the claim that the current API sucks
> accurate? It seems other projects, such as Pidgin and Bitlbee have
> implemented OTR just fine, so maybe the core devs either have issues with
> the Gajim code, or the OTR code that was written just sucked.

FWIW, being the one who coded the support for BitlBee, i didn't find
anything overly painful about the API. in fact i thought it felt pretty
good. i'm sure there are things that could be improved, like the whole
SMP logic that you have to basically copy and paste from the README, but
then again, that wasn't hard either.

obviously i don't know what the insides of Gajim look like. also i don't
know what that message ID thing is about. overall, to my gut it sounds i bit
like he expected a three-line drop-in that would just magically work for
the developer. and you're just not going to get that if the software
you're talking about is security software that is trying hard to
automagically work for the *user*.

-pesco

From chrisballinger at gmail.com  Thu Aug 18 13:45:31 2011
From: chrisballinger at gmail.com (Chris Ballinger)
Date: Thu, 18 Aug 2011 13:45:31 -0400
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <20110818121619.GA23214@poseidon.cocyt.us>
References: <20110818121619.GA23214@poseidon.cocyt.us>
Message-ID: <CAG7SQq4sc70JY2gb7JRm3Mo_vrPieUWXmL4YRaTcWL_qk3HOLg@mail.gmail.com>

I implemented libotr for iPhone in under a day so I'd say it's not
particularly difficult.

https://github.com/chrisballinger/Off-the-Record-iOS/blob/master/Off%20the%20Record/OTRCodec.m

Basically you just need to implement that structure OtrlMessageAppOps and
all of those static functions need to be modified to work with how Gajim
does its stuff. Then just follow the readme for how to encode/decodes
messages, or look at the bottom of my file for how I did it.

On Thu, Aug 18, 2011 at 8:16 AM, Aaron Toponce <aaron.toponce at gmail.com>wrote:

> According to http://trac.gajim.org/wiki/OTR, the OTR API is crap, and
> implementing it into a project seems to be somewhat of a chore. I would
> like to see OTR support built into Gajim, but it appears to be a deadend.
> As the article states, you can see the code he ripped out from the commit
> message here: http://trac.gajim.org/changeset/ef7496ee5eb2/.
>
> Thankfully, it appears that Gajim will be supporting a plugin architecture,
> and an OTR plugin looks likely. See http://gajim-otr.pentabarf.de/.
> Currently, the only end-to-end encryption for Gajim, is using OpenPGP keys,
> which digitally sign every message, which isn't optimal.
>
> So, is OTR v4 being worked on? Is the claim that the current API sucks
> accurate? It seems other projects, such as Pidgin and Bitlbee have
> implemented OTR just fine, so maybe the core devs either have issues with
> the Gajim code, or the OTR code that was written just sucked.
>
> Thoughts?
>
> --
> . o .   o . o   . . o   o . .   . o .
> . . o   . o o   o . o   . o o   . . o
> o o o   . o .   . o o   o o .   o o o
>
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110818/5ba81d81/attachment.htm>

From js-otrim at webkeks.org  Thu Aug 18 16:12:36 2011
From: js-otrim at webkeks.org (Jonathan Schleifer)
Date: Thu, 18 Aug 2011 22:12:36 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <874o1ehowr.fsf@atomzentrale.khjk.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<874o1ehowr.fsf@atomzentrale.khjk.org>
Message-ID: <FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>

Am 18.08.2011 um 14:42 schrieb Sven Moritz Hallberg:

> overall, to my gut it sounds i bit
> like he expected a three-line drop-in that would just magically work for
> the developer. and you're just not going to get that if the software
> you're talking about is security software that is trying hard to
> automagically work for the *user*.

Actually, exactly the opposite is the case, if you look at the commit. There was a lot of code, but libotr just wants to be that three-line drop in, so you lose a lot of flexibility which you need to properly support XMPP with all it's features.

I'm especially astonished to hear that it works in bitlbee without any effort, as there is no HTML parsing in bitlbee. Or is the implementation for bitlbee one of those where you suddenly see HTML as soon as something goes wrong?

--
Jonathan


From js-otrim at webkeks.org  Thu Aug 18 16:13:18 2011
From: js-otrim at webkeks.org (Jonathan Schleifer)
Date: Thu, 18 Aug 2011 22:13:18 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <20110818121619.GA23214@poseidon.cocyt.us>
References: <20110818121619.GA23214@poseidon.cocyt.us>
Message-ID: <5D817269-AD9D-493D-9E59-9FE37CBB2613@webkeks.org>

Am 18.08.2011 um 14:16 schrieb Aaron Toponce:

> Currently, the only end-to-end encryption for Gajim, is using OpenPGP keys,
> which digitally sign every message, which isn't optimal.

Not really true: There's still ESessions.

> It seems other projects, such as Pidgin and Bitlbee have
> implemented OTR just fine, so maybe the core devs either have issues with
> the Gajim code, or the OTR code that was written just sucked.

They don't care that they get error messages as HTML etc and just display them without specially handling them (because you can't). They are also missing a lot of features we have which would not have been possible anymore with the current libotr API without huge and hacky workarounds.

I was the one removing OTR. I spent a lot of time to get it working properly, but that's not really possible if you are forced to parse strings containing HTML that are even localized to see if an error happened?

--
Jonathan

From chrisballinger at gmail.com  Thu Aug 18 19:31:12 2011
From: chrisballinger at gmail.com (Chris Ballinger)
Date: Thu, 18 Aug 2011 19:31:12 -0400
Subject: [OTR-dev] Finding your own fingerprint?
Message-ID: <CAG7SQq4rmgJR5HzCkzGi+_Yr=oFAbiAeW3vnoF-fp0r8bd7NMw@mail.gmail.com>

After looking in ConnContext it seems that the pointer
active_fingerprint refers
to the fingerprint of the user you are messaging (remote user). How do I
find the fingerprint for the person sending the messages (local user)?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110818/64be7758/attachment.html>

From aaron.toponce at gmail.com  Fri Aug 19 17:30:03 2011
From: aaron.toponce at gmail.com (Aaron Toponce)
Date: Fri, 19 Aug 2011 15:30:03 -0600
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <F6327715-FA3C-4310-9CE6-B880A242B693@webkeks.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<F6327715-FA3C-4310-9CE6-B880A242B693@webkeks.org>
Message-ID: <20110819213003.GE23214@poseidon.cocyt.us>

On Thu, Aug 18, 2011 at 10:09:00PM +0200, Jonathan Schleifer wrote:
> I was the one removing OTR. I spent a lot of time to get it working properly, but that's not really possible if you are forced to parse strings containing HTML that are even localized to see if an error happened?

I hope you don't think I was criticizing your code, or attacking you in any
way. I appear to come off that way on mailing lists. I was just curious
what it would take, in the long shot, to get it working. It appears that
0.15 will support plugins, and a plugin is ready, or getting ready, to go
live with it.

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL: </pipermail/otr-dev/attachments/20110819/d7247572/attachment.pgp>

From kb at pentabarf.de  Mon Aug 22 07:59:47 2011
From: kb at pentabarf.de (Kjell Braden)
Date: Mon, 22 Aug 2011 13:59:47 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <20110819213003.GE23214@poseidon.cocyt.us>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<F6327715-FA3C-4310-9CE6-B880A242B693@webkeks.org>
	<20110819213003.GE23214@poseidon.cocyt.us>
Message-ID: <4E5244B3.6040404@pentabarf.de>

On 08/19/2011 11:30 PM, Aaron Toponce wrote:
> On Thu, Aug 18, 2011 at 10:09:00PM +0200, Jonathan Schleifer wrote:
>> I was the one removing OTR. I spent a lot of time to get it working properly, but that's not really possible if you are forced to parse strings containing HTML that are even localized to see if an error happened?
> 
> I hope you don't think I was criticizing your code, or attacking you in any
> way. I appear to come off that way on mailing lists. I was just curious
> what it would take, in the long shot, to get it working. It appears that
> 0.15 will support plugins, and a plugin is ready, or getting ready, to go
> live with it.
> 
> --
> . o .   o . o   . . o   o . .   . o .
> . . o   . o o   o . o   . o o   . . o
> o o o   . o .   . o o   o o .   o o o
> 
> 
> 
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev

Hi,

 being the one who was working on gajim-otr, I think I need to clarify
one or another point here:

 First: the libotr itself is not bad. I found that working with it can
be really easy. The worst (and the IMHO only really critical, though js
may disagree here) problem was that can't implement callbacks for the
libotr in python. You can, but you have to deal with python-exceptions,
and the libotr callbacks must not fail. I used abort() for that matter,
which was probably not my best idea. ;-)

 Mostly for that project I built the python-otr bindings (ie. a python
interface to the libotr), which was mostly a 1:1 mapping to the libotr
api and therefore not quite what you like to use in python. For that
reason, gajim-otr was pretty much unusable and was abandoned. Few
months ago I had some time left and created a pure python implementation
of the otr protocol (this means, its not the libotr, but it is
compatible in what it does) [1]. It works, but hasn't received much
testing. I have a working gajim plugin but currently don't really have
the time to release it for beta.

On 08/18/2011 02:42 PM, Sven Moritz Hallberg wrote:
> overall, to my gut it sounds i bit
> like he expected a three-line drop-in that would just magically work for
> the developer. and you're just not going to get that if the software
> you're talking about is security software that is trying hard to
> automagically work for the *user*.

 I have no idea what your gut read or saw about that story, but it
definitely had nothing to do with three-line drop-ins.


[1] http://lists.cypherpunks.ca/pipermail/otr-dev/2011-May/001174.html

-- 
Kjell

From pesco at khjk.org  Mon Aug 22 17:03:33 2011
From: pesco at khjk.org (Sven Moritz Hallberg)
Date: Mon, 22 Aug 2011 23:03:33 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<874o1ehowr.fsf@atomzentrale.khjk.org>
	<FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>
Message-ID: <87sjotf9ay.fsf@atomzentrale.khjk.org>

On Thu, 18 Aug 2011 22:12:36 +0200, Jonathan Schleifer <js-otrim at webkeks.org> wrote:
> Actually, exactly the opposite is the case, if you look at the
> commit. There was a lot of code, but libotr just wants to be that
> three-line drop in, so you lose a lot of flexibility which you need to
> properly support XMPP with all it's features.

out of curiosity, what are examples of those XMPP features?

> I'm especially astonished to hear that it works in bitlbee without any
> effort, as there is no HTML parsing in bitlbee. Or is the
> implementation for bitlbee one of those where you suddenly see HTML as
> soon as something goes wrong?

i'd say it was without much *undue* effort. as for the HTML messages,
there is agreement i think that these are the big ugly part of libotr
that needs overhaul. however: there is code in bitlbee to display HTML
messages, because that's what you get from some transports. so we push
OTR's messages through that and display them.

what kind of cases did you encounter where you had to actually parse the
message to determine an error?

-pesco

PS. i apologize if my original comment came off as
condescending. apparently, as Kjell explained, a lot of the trouble had
to do with the C API being hard to interface into the Python world. i
thought the developer had just been lazy and annoyed when it became
clear you need to handle a bunch of stuff for this encryption shit. that
was arrogant. sorry.

From ian at cypherpunks.ca  Tue Aug 23 18:39:15 2011
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 23 Aug 2011 18:39:15 -0400
Subject: [OTR-dev] Finding your own fingerprint?
In-Reply-To: <CAG7SQq4rmgJR5HzCkzGi+_Yr=oFAbiAeW3vnoF-fp0r8bd7NMw@mail.gmail.com>
References: <CAG7SQq4rmgJR5HzCkzGi+_Yr=oFAbiAeW3vnoF-fp0r8bd7NMw@mail.gmail.com>
Message-ID: <20110823223915.GB10744@yoink.cs.uwaterloo.ca>

On Thu, Aug 18, 2011 at 07:31:12PM -0400, Chris Ballinger wrote:
> After looking in ConnContext it seems that the pointer
> active_fingerprint refers
> to the fingerprint of the user you are messaging (remote user). How do I
> find the fingerprint for the person sending the messages (local user)?
> 
> Thanks!

You can use the otrl_privkey_fingerprint{,_raw} functions for this.

   - Ian

From ian at cypherpunks.ca  Tue Aug 23 18:46:17 2011
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 23 Aug 2011 18:46:17 -0400
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <5D817269-AD9D-493D-9E59-9FE37CBB2613@webkeks.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<5D817269-AD9D-493D-9E59-9FE37CBB2613@webkeks.org>
Message-ID: <20110823224617.GC10744@yoink.cs.uwaterloo.ca>

On Thu, Aug 18, 2011 at 10:13:18PM +0200, Jonathan Schleifer wrote:
> They don't care that they get error messages as HTML etc and just
> display them without specially handling them (because you can't). They
> are also missing a lot of features we have which would not have been
> possible anymore with the current libotr API without huge and hacky
> workarounds.
> 
> I was the one removing OTR. I spent a lot of time to get it working
> properly, but that's not really possible if you are forced to parse
> strings containing HTML that are even localized to see if an error
> happened?

This was a very broken misfeature of the libotr API, and it's been fixed
for the next version.  Errors signalled by the library are now passed to
the application via error codes, and the application can do whatever it
likes (in whatever i18n) with them.

See, for example,
http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/otr;a=blob;f=libotr/src/message.h;h=f2d1c7ac2429f0985bb85ef88b667c225522ba12;hb=HEAD

   - Ian

From chrisballinger at gmail.com  Tue Aug 23 22:35:58 2011
From: chrisballinger at gmail.com (Chris Ballinger)
Date: Tue, 23 Aug 2011 22:35:58 -0400
Subject: [OTR-dev] Finding your own fingerprint?
In-Reply-To: <20110823223915.GB10744@yoink.cs.uwaterloo.ca>
References: <CAG7SQq4rmgJR5HzCkzGi+_Yr=oFAbiAeW3vnoF-fp0r8bd7NMw@mail.gmail.com>
	<20110823223915.GB10744@yoink.cs.uwaterloo.ca>
Message-ID: <CAG7SQq65U-2rA3V+kCc7e2OiAxU7wVnHR6f=WYaH+h1xEu9iSA@mail.gmail.com>

Thanks, though I actually found it by searching for a known string in the
dialog box :)

On Tue, Aug 23, 2011 at 6:39 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:

> On Thu, Aug 18, 2011 at 07:31:12PM -0400, Chris Ballinger wrote:
> > After looking in ConnContext it seems that the pointer
> > active_fingerprint refers
> > to the fingerprint of the user you are messaging (remote user). How do I
> > find the fingerprint for the person sending the messages (local user)?
> >
> > Thanks!
>
> You can use the otrl_privkey_fingerprint{,_raw} functions for this.
>
>   - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110823/092b9ae3/attachment.html>

From stpeter at stpeter.im  Wed Aug 24 12:20:26 2011
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 24 Aug 2011 10:20:26 -0600
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <87sjotf9ay.fsf@atomzentrale.khjk.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<874o1ehowr.fsf@atomzentrale.khjk.org>
	<FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>
	<87sjotf9ay.fsf@atomzentrale.khjk.org>
Message-ID: <4E5524CA.3000307@stpeter.im>

On 8/22/11 3:03 PM, Sven Moritz Hallberg wrote:
> On Thu, 18 Aug 2011 22:12:36 +0200, Jonathan Schleifer <js-otrim at webkeks.org> wrote:
>> Actually, exactly the opposite is the case, if you look at the
>> commit. There was a lot of code, but libotr just wants to be that
>> three-line drop in, so you lose a lot of flexibility which you need to
>> properly support XMPP with all it's features.
> 
> out of curiosity, what are examples of those XMPP features?

XMPP is used for many things other than sending human-readable IMs. One
prominent example is Jingle, an extension for managing voice, video, and
other multimedia sessions that is used in the Google Talk service and
several open-source XMPP clients. Such extensions are not forced into
the message body, instead they are XML-structured payloads that are
often placed inside the XMPP <iq/> element rather than the <message/>
element. You can see examples here:

http://xmpp.org/extensions/xep-0167.html#example-1

http://xmpp.org/extensions/xep-0234.html#example-1

If you're exchanging things like IP addresses and file names, you really
might want to encrypt that end-to-end so snoops in the middle can't
learn things that are none of their business.

Ideally, a future version of OTR would have a mode that enables people
to send this kind of information, instead of just XML character data
like the "foo" in <message><body>foo</body></message>.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From pesco at khjk.org  Thu Aug 25 04:30:50 2011
From: pesco at khjk.org (Sven Moritz Hallberg)
Date: Thu, 25 Aug 2011 10:30:50 +0200
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <4E5524CA.3000307@stpeter.im>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<874o1ehowr.fsf@atomzentrale.khjk.org>
	<FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>
	<87sjotf9ay.fsf@atomzentrale.khjk.org>
	<4E5524CA.3000307@stpeter.im>
Message-ID: <8739gpgaf9.fsf@atomzentrale.khjk.org>

On Wed, 24 Aug 2011 10:20:26 -0600, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 8/22/11 3:03 PM, Sven Moritz Hallberg wrote:
> > On Thu, 18 Aug 2011 22:12:36 +0200, Jonathan Schleifer <js-otrim at webkeks.org> wrote:
> >> There was a lot of code, but libotr just wants to be that
> >> three-line drop in, so you lose a lot of flexibility which you need to
> >> properly support XMPP with all it's features.
> > 
> > out of curiosity, what are examples of those XMPP features?
> 
> XMPP is used for many things other than sending human-readable IMs.
> [...]
>
> Ideally, a future version of OTR would have a mode that enables people
> to send this kind of information, instead of just XML character data
> like the "foo" in <message><body>foo</body></message>.

this would necessarily be an XMPP-specific adaptation. there's nothing
wrong with that, i think it would be a good idea to make one. but it's
separate from the transport-agnostic "base case" currently catered to by
libotr.

i was wondering if there are XMPP specialities that actually interfere
with implementing that text-IM-only base case?

-pesco

From nikita at uiuc.edu  Mon Aug 29 17:53:47 2011
From: nikita at uiuc.edu (Nikita Borisov)
Date: Tue, 30 Aug 2011 05:53:47 +0800
Subject: [OTR-dev] cypherpunks.ca serving malware as of 8/28
In-Reply-To: <93C55069F88A304D8D861EBC3FAA836B013B5E9C0DED@MBX1.EXCHPROD.USA.NET>
References: <93C55069F88A304D8D861EBC3FAA836B013B5E9C0DED@MBX1.EXCHPROD.USA.NET>
Message-ID: <CAE4DWpvtB5QEauC2fM0awg7kQMDS8UkFan2-r2Q==sSz3XrEQA@mail.gmail.com>

Dear Evan,

Thank you for bringing this to our attention.  I have visited the URL
you provided but was not able to find a threat expert report with the
md5 listed.  I have also tried scanning the indicated file with threat
expert and it did not list any issues, so I'm assuming that the
malc0de page is in error.  Please let us know if you have any
information to the contrary.

- Nikita

On Tue, Aug 30, 2011 at 12:02 AM, Keiser, Evan <ekeiser at perimeterusa.com> wrote:
> Guys,
>
>
>
> I have been an avid user of OTR since its inception and I wanted to ensure
> you were aware of some recent activity coming from your domain. Today a user
> on our network attempted to download one of the pidgin-OTR wrapped
> executables and we found it was blocked by one of our malware correlations.
> It appears since the 28th ?of this month your executables have been serving
> numerous different types of malware. You can find the link to the malc0de
> entry here, http://malc0de.com/database/index.php?search=www.cypherpunks.ca
> and you can take a look at the MD5 hash links to the threatexpert reports.
> Please let us know when this is resolved or remove the download if possible.
> Thank you.
>
>
>
>
>
> Thanks,
>
> Evan Robert Keiser
>
> Security Analyst
>
> Perimeter e-Security
>
> 919.228.2571
>
>
>
> --
>  The sender of this email subscribes to Perimeter E-Security's email
>  anti-virus service. This email has been scanned for malicious code and is
>  believed to be virus free. For more information on email security please
>  visit: http://www.perimeterusa.com/services/messaging
>  This communication is confidential, intended only for the named
> recipient(s)
>  above and may contain trade secrets or other information that is exempt
> from
>  disclosure under applicable law. Any use, dissemination, distribution or
>  copying of this communication by anyone other than the named recipient(s)
> is
>  strictly prohibited. If you have received this communication in error,
> please
>  delete the email and immediately notify our Command Center at 203-541-3444.
>
>  Thanks
>



-- 
Nikita Borisov - http://hatswitch.org/~nikita/
Assistant Professor, Electrical and Computer Engineering
Tel: (217) 903-4401, Office: 460 CSL

From stpeter at stpeter.im  Tue Aug 30 13:14:08 2011
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 30 Aug 2011 11:14:08 -0600
Subject: [OTR-dev] OTR support for Gajim
In-Reply-To: <8739gpgaf9.fsf@atomzentrale.khjk.org>
References: <20110818121619.GA23214@poseidon.cocyt.us>
	<874o1ehowr.fsf@atomzentrale.khjk.org>
	<FB63AF43-5C8D-4946-9236-3BE1214542C6@webkeks.org>
	<87sjotf9ay.fsf@atomzentrale.khjk.org>
	<4E5524CA.3000307@stpeter.im>
	<8739gpgaf9.fsf@atomzentrale.khjk.org>
Message-ID: <4E5D1A60.8050109@stpeter.im>

On 8/25/11 2:30 AM, Sven Moritz Hallberg wrote:
> On Wed, 24 Aug 2011 10:20:26 -0600, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> On 8/22/11 3:03 PM, Sven Moritz Hallberg wrote:
>>> On Thu, 18 Aug 2011 22:12:36 +0200, Jonathan Schleifer <js-otrim at webkeks.org> wrote:
>>>> There was a lot of code, but libotr just wants to be that
>>>> three-line drop in, so you lose a lot of flexibility which you need to
>>>> properly support XMPP with all it's features.
>>>
>>> out of curiosity, what are examples of those XMPP features?
>>
>> XMPP is used for many things other than sending human-readable IMs.
>> [...]
>>
>> Ideally, a future version of OTR would have a mode that enables people
>> to send this kind of information, instead of just XML character data
>> like the "foo" in <message><body>foo</body></message>.
> 
> this would necessarily be an XMPP-specific adaptation. there's nothing
> wrong with that, i think it would be a good idea to make one. but it's
> separate from the transport-agnostic "base case" currently catered to by
> libotr.
> 
> i was wondering if there are XMPP specialities that actually interfere
> with implementing that text-IM-only base case?

The text-only-IM case works fine right now in XMPP. But we'd like to
encrypt more than just text-only IM.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From Byrd.B at insightcom.com  Tue Aug 30 13:51:34 2011
From: Byrd.B at insightcom.com (Byrd, Brendan)
Date: Tue, 30 Aug 2011 17:51:34 +0000
Subject: [OTR-dev] In need of a patch to libotr
Message-ID: <A5A6E86B6C128841AE5F80F7C520C93157E1B6@HUBMAIL03.insight.ds>

This bug has been bothering me for almost a year now:

http://lists.cypherpunks.ca/pipermail/otr-users/2010-December/001891.html

I would submit a full patch, but I need somebody to review the changes, as C isn't my first language and I'm not familiar with the OTR code as a whole.  Here's the list of changes:

All of this applies to message.c / otrl_message_receiving / case OTRL_MSGTYPE_NOTOTR:


*         This case needs to try a refresh of the conversation.  Obviously, if the states are confused, leaving them in that state is NOT the best policy.  It should instead immediately start an encrypted refresh.  I think this would be a call to the "go_encrypted" sub.

*         After the refresh, the previously unencrypted side should resend the message.  OTR Messages don't get flashed by Pidgin at least, and probably others.  As such, a U->E conversation gets lost until hours later when I happen to see all of the collected messages.

Can somebody please make a patch as such?  Hell, I'll test it out as long as I can get a Windows compiled binary of it.  This

--
Brendan Byrd <byrd.b at insightcom.com<mailto:byrd.b at insightcom.com>>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110830/7851aaf7/attachment.htm>