From mark@kingant.net Tue Mar 6 06:44:14 2007 From: mark@kingant.net (Mark Doliner) Date: Tue, 6 Mar 2007 01:44:14 -0500 Subject: [OTR-dev] Lost OTR keys when upgrading from Gaim beta 5 to beta 6 Message-ID: <20070306063934.M80839@kingant.net> An Ubuntu user filed a bug[1] about some problems he encountered when upgrading from Gaim 2.0.0 beta 5 to Gaim 2.0.0 beta 6. The problems are related to the split of prpl-oscar into prpl-aim and prpl-icq. "The most serious problem I encountered was the fact, that ALL my icq ("oscar") OTR-keys and fingerprints were no longer found by gaim until I manually renamed all references in the config." I'm not familiar with the OTR plugin and don't know how yous guys store OTR keys and fingerprints, but you might need to rename your settings if the user is running Gaim 2.0.0 beta 6 or higher. If this has already been fixed, or is not a real problem then please ignore me. Thanks, Mark [1] https://launchpad.net/ubuntu/+source/gaim/+bug/88647 From ian@cypherpunks.ca Tue Mar 6 13:43:59 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 6 Mar 2007 08:43:59 -0500 Subject: [OTR-dev] Lost OTR keys when upgrading from Gaim beta 5 to beta 6 In-Reply-To: <20070306063934.M80839@kingant.net> References: <20070306063934.M80839@kingant.net> Message-ID: <20070306134359.GB22164@thunk.cs.uwaterloo.ca> On Tue, Mar 06, 2007 at 01:44:14AM -0500, Mark Doliner wrote: > An Ubuntu user filed a bug[1] about some problems he encountered when > upgrading from Gaim 2.0.0 beta 5 to Gaim 2.0.0 beta 6. The problems are > related to the split of prpl-oscar into prpl-aim and prpl-icq. > > "The most serious problem I encountered was the fact, that ALL my icq > ("oscar") OTR-keys and fingerprints were no longer found by gaim until I > manually renamed all references in the config." > > I'm not familiar with the OTR plugin and don't know how yous guys store OTR > keys and fingerprints, but you might need to rename your settings if the user > is running Gaim 2.0.0 beta 6 or higher. If this has already been fixed, or is > not a real problem then please ignore me. We've heard this before, but I think it's not a real problem; it's a one-time PITA for existing users, and putting in code to automatically try to compensate is likely to introduce more bugs than it's worth. Not only that, but the gaim2 beta series has proven to be a highly moving target, and I'd prefer to see it settle down before dealing with a minor issue involving a particular beta transition. - Ian From ian@cypherpunks.ca Wed Mar 7 22:07:07 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 7 Mar 2007 17:07:07 -0500 Subject: [OTR-dev] Linking libgcrypt statically into gaim-otr.so Message-ID: <20070307220707.GI8965@thunk.cs.uwaterloo.ca> I figured out how to do this on Linux. I have no idea how to do it on other systems, or how to get libtool to do this on its own (possibly not possible). The problem, again: other gaim plugins, such as Jabber or ldap, use libgcrypt (often in the guise of TLS). libgcrypt uses global variables, and assumes that it will only have one caller per address space. The various plugins initialize libgcrypt's global variables, and stomp all over each other's (and gaim-otr's) initializations. Badness ensues. The "right" solution is for libgcrypt to stop using global variables, and to pass handles around. Back-compatibility can be easily arranged by having the current routines do something like: gcry_foo(int bar, char *baz) { gcry_foo_r(&global_handle, bar, baz); } but callers "in the know" could call gcry_foo_r directly with a private handle. But until that happens, here's a workaround for gaim-otr to link libgcrypt statically. It's actually pretty tricky, since it seems calls from one .o to another in a .so file are always looked up dynamically, so if another copy of libgcrypt exists in the address space, you'll still get that one. So you have to put everything in a single .o, make the libgcrypt symbols local, and turn the result into a .so. Here's Makefile.static (for gaim-otr): .libs/gaim-otr.so: FORCE # Build everything from the standard Makefile make # Link everything, including libotr and libgcrypt, together into # a single .o file ld -r .libs/otr-plugin.o .libs/ui.o .libs/dialogs.o .libs/gtk-ui.o .libs/gtk-dialog.o /usr/lib/libotr.a /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a -o .libs/gaim-otr-shared.o # Make all the libgcrypt references local to that .o file objcopy -w -L '*gcry*' .libs/gaim-otr-shared.o .libs/gaim-otr-static.o # Turn the .o into a .so gcc -shared .libs/gaim-otr-static.o -Wl,-soname -Wl,gaim-otr.so -o .libs/gaim-otr.so FORCE: - Ian From mail@scottellis.com.au Thu Mar 22 16:55:23 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Fri, 23 Mar 2007 02:55:23 +1100 Subject: [OTR-dev] html in otr messages Message-ID: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> ------=_Part_201152_33376833.1174578923153 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline >From Wintermute on the Miranda forum: "Hm .. ok .. the friend made a statement and asked me to post it for him (as he isn't registered here and to lazy to do so): "Quote: I had a lengthy email conversation with Ian Goldberg, one of the authors of OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you will see that it specifies optional HTML-formating in the plaintext. As OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian thinks (as do I after thinking about it) that the OTR specs supersede the standards of "lower level" protocols such as XMPP. It is the job of an OTR plugin to process the HTML tags in the plaintext, if they are not used by the client it's the plugins job to strip them. If you don't see it that way, I suggest you contact the otr-dev mailinglist." I think of it quite the opposite way - OTR simply encapsulates protocol messages OTR would have quite a job to do trying to detect whether the client supports HTML in Miranda - there are so many messaging modules etc. And they're likely to change at any time - it would make maintainence difficult. I don't think tracking the client's capabilities is the plugin's job. And I think the client should output the same *intended message* whether or not OTR is installed - after decription, OTR messages from gaim OTR contain formatting html, whereas without OTR gaim outputs no formatting html. This means transmitting more information than usual - which, although very unlikely, may not be something that the user wants. Removing the tags means I would have to reimlement something already implemented by at least the AIM protocol plugin. Processing the codes 'properly' for the client could involve conversion from e.g. html to bbcodes, if the client supports those - which would mean differences in the nature of OTR plugins for different clients. Or further, if the OTR spec specifies handling of HTML, then the otr library should be able to handle it - but again that's a reimplementation of stuff that the protocol can already do. Also - and I really don't mean to criticize - but the protocol specs for things like jabber and other open protocols, with their RFC's and comittees etc etc, tend to be thought out pretty well. The reasons for disallowing things like 'mixed contect' (from the jabber RFC) are usually pretty good. For example, if I want to send the text blue to a friend, I can do so over jabber (because it is encoded and decoded by the protocol so as to not create 'mixed content') and expect him to get the message as I typed it, if the client performs to the spec. With OTR, if it's removing tags on clients that do not support markup, how does it tell the difference between formatting tags and what the user has typed? At a minimum it would somehow have to encode tags in message text and formatting tags differently - or you have restricted what messages users can and can't send. ------=_Part_201152_33376833.1174578923153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline >From Wintermute on the Miranda forum:

"Hm .. ok .. the friend made a statement and asked me to post it for him (as he isn't registered here and to lazy to do so):

"Quote:
I had a lengthy email conversation with Ian Goldberg, one of the authors of OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you will see that it specifies optional HTML-formating in the plaintext. As OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian thinks (as do I after thinking about it) that the OTR specs supersede the standards of "lower level" protocols such as XMPP. It is the job of an OTR plugin to process the HTML tags in the plaintext, if they are not used by the client it's the plugins job to strip them.
If you don't see it that way, I suggest you contact the otr-dev mailinglist."

I think of it quite the opposite way - OTR simply encapsulates protocol messages

OTR would have quite a job to do trying to detect whether the client supports HTML in Miranda - there are so many messaging modules etc. And they're likely to change at any time - it would make maintainence difficult. I don't think tracking the client's capabilities is the plugin's job.

And I think the client should output the same *intended message* whether or not OTR is installed - after decription, OTR messages from gaim OTR contain formatting html, whereas without OTR gaim outputs no formatting html.  This means transmitting more information than usual - which, although very unlikely, may not be something that the user wants.

Removing the tags means I would have to reimlement something already implemented by at least the AIM protocol plugin. Processing the codes 'properly' for the client could involve conversion from e.g. html to bbcodes, if the client supports those - which would mean differences in the nature of OTR plugins for different clients. Or further, if the OTR spec specifies handling of HTML, then the otr library should be able to handle it - but again that's a reimplementation of stuff that the protocol can already do.

Also - and I really don't mean to criticize - but the protocol specs for things like jabber and other open protocols, with their RFC's and comittees etc etc, tend to be thought out pretty well. The reasons for disallowing things like 'mixed contect' (from the jabber RFC) are usually pretty good. For example, if I want to send the text <font>blue</font> to a friend, I can do so over jabber (because it is encoded and decoded by the protocol so as to not create 'mixed content') and expect him to get the message as I typed it, if the client performs to the spec. With OTR, if it's removing tags on clients that do not support markup, how does it tell the difference between formatting tags and what the user has typed? At a minimum it would somehow have to encode tags in message text and formatting tags differently - or you have restricted what messages users can and can't send.
------=_Part_201152_33376833.1174578923153-- From ian@cypherpunks.ca Thu Mar 22 19:17:00 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 22 Mar 2007 14:17:00 -0400 Subject: [OTR-dev] html in otr messages In-Reply-To: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> Message-ID: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: > >From Wintermute on the Miranda forum: > > "Hm .. ok .. the friend made a statement and asked me to post it for him (as > he isn't registered here and to lazy to do so): > > "Quote: > I had a lengthy email conversation with Ian Goldberg, one of the authors of > OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you > will see that it specifies optional HTML-formating in the plaintext. As > OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian > thinks (as do I after thinking about it) that the OTR specs supersede the > standards of "lower level" protocols such as XMPP. It is the job of an OTR > plugin to process the HTML tags in the plaintext, if they are not used by > the client it's the plugins job to strip them. > If you don't see it that way, I suggest you contact the otr-dev > mailinglist." > > I think of it quite the opposite way - OTR simply encapsulates protocol > messages > > OTR would have quite a job to do trying to detect whether the client > supports HTML in Miranda - there are so many messaging modules etc. And > they're likely to change at any time - it would make maintainence difficult. > I don't think tracking the client's capabilities is the plugin's job. You're right; I think that whatever calls the OTR plugin should be able to understand what the plugin outputs. In gaim, there's no problem, since gaim understands the format of OTR plaintext messages already. Miranda hasn't (yet?) implemented tag-handling in most of its protocol plugins, fine. So the Miranda AIM plugin, for example, has to explicitly strip the tags, instead of parsing them. You could have the Miranda OTR plugin optionally do that instead; the protocol plugin could pass a parameter that says "strip the HTML tags from the plaintext before giving it back to me". Or just have a function in the OTR plugin to do that (steal it from the AIM plugin) that the protocol plugins can call. > And I think the client should output the same *intended message* whether or > not OTR is installed - after decription, OTR messages from gaim OTR contain > formatting html, whereas without OTR gaim outputs no formatting html. Not true: see my otr-users message. gaim sends *both* the formatted and non-formatted versions in Jabber. > This > means transmitting more information than usual - which, although very > unlikely, may not be something that the user wants. There's no more information in the OTR version than in the original Jabber message. Miranda was just ignoring the more information-rich part of the Jabber message. > Removing the tags means I would have to reimlement something already > implemented by at least the AIM protocol plugin. Processing the codes > 'properly' for the client could involve conversion from e.g. html to > bbcodes, if the client supports those - which would mean differences in the > nature of OTR plugins for different clients. Or further, if the OTR spec > specifies handling of HTML, then the otr library should be able to handle it > - but again that's a reimplementation of stuff that the protocol can already > do. The OTR library gives you a plaintext message, in utf-8 encoding, that is allowed to have HTML tags in it. If you need something different for your application, you'll need to convert it. For example, if your application decides it needs to convert the HTML tags to bbcodes, either it, or its OTR plugin, will need to do that; libotr won't do it by default. [Of course, if there's a really common conversion that lots of different clients need, we could consider just bundling it with the library.] > Also - and I really don't mean to criticize - but the protocol specs for > things like jabber and other open protocols, with their RFC's and comittees > etc etc, tend to be thought out pretty well. The reasons for disallowing > things like 'mixed contect' (from the jabber RFC) are usually pretty good. > For example, if I want to send the text blue to a friend, I can > do so over jabber (because it is encoded and decoded by the protocol so as > to not create 'mixed content') and expect him to get the message as I typed > it, if the client performs to the spec. With OTR, if it's removing tags on > clients that do not support markup, how does it tell the difference between > formatting tags and what the user has typed? At a minimum it would somehow > have to encode tags in message text and formatting tags differently - or you > have restricted what messages users can and can't send. OTR expects your plaintext input to be HTML-encoded. Which means if there's a literal "<" in your plaintext message, you should convert it to "<" before giving it to OTR. That's certainly what Jabber does: even without OTR, "<"s in messages get converted to "<" on the wire. So if you send "blue" (a message intending to start with a literal "<") to your buddy, your end will convert it to "<font>blue</font>" (whether or not you're using OTR), then if you're using OTR, you'll pass *that* to the OTR plugin, which will encrypt it. Your buddy's client will decrypt it back to "<font>blue</font>" and display it to him as "blue". Out of curiosity, why doesn't Miranda just parse the HTML tags for all protocols that support them? - Ian From rabbi@abditum.com Thu Mar 22 19:26:19 2007 From: rabbi@abditum.com (Len Sassaman) Date: Thu, 22 Mar 2007 10:26:19 -0800 (PST) Subject: [OTR-dev] gaim-otr art In-Reply-To: References: <20061027010201.30794.32036.Mailman@brandeis.paip.net> <1161912165.12700.13.camel@asshair> <1162017307.5285.2.camel@asshair> Message-ID: On Sat, 28 Oct 2006, Paul Wouters wrote: > buttons are very carefully chosen. Grey means "we don't know for sure > who this is", multiple grey people mean "others you dont know might read > this". The one yellow coloured person means "only this known verified > person can read this". Those images can not be replaced by other imagery > without discussion on whether the new images still clearly convey that > message. Hi Paul, Pardon me if this is answered somewhere in the archives; I couldn't find it. Were these icon decisions made based on any prior HCI work in this area, or was this a design decision of the OTR time? If the former, could you point me at it? (If the latter, could you point me at the best summary of the rationale behind it, and any alternatives considered?) Thanks, Len From paul@cypherpunks.ca Fri Mar 23 03:39:44 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 23 Mar 2007 03:39:44 +0100 (CET) Subject: [OTR-dev] gaim-otr art In-Reply-To: References: <20061027010201.30794.32036.Mailman@brandeis.paip.net> <1161912165.12700.13.camel@asshair> <1162017307.5285.2.camel@asshair> Message-ID: On Thu, 22 Mar 2007, Len Sassaman wrote: > Pardon me if this is answered somewhere in the archives; I couldn't find > it. Were these icon decisions made based on any prior HCI work in this > area, or was this a design decision of the OTR time? If the former, could > you point me at it? (If the latter, could you point me at the best > summary of the rationale behind it, and any alternatives considered?) Most of the discussion happened on the list, as far as I remember. Some might have come from face to face meetings. In the end, I think Kat and Ian made the final decisions on the icons. What keeps reoccuring though is people asking for a padlock, and other people saying the padlock just cannot convey the message. Paul From mail@scottellis.com.au Fri Mar 23 04:20:06 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Fri, 23 Mar 2007 14:20:06 +1100 Subject: [OTR-dev] html in otr messages In-Reply-To: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> <20070322181700.GF23856@thunk.cs.uwaterloo.ca> Message-ID: <96e269140703222020y57105700r26296b6051fc86b4@mail.gmail.com> ------=_Part_226355_180953.1174620006385 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline First I'll explain how encryption works in Miranda, then I'll address a couple of your points. Miranda has a 'message chain'. When a message is received, it gets converted on the network level by the protocol into a standard internal format. Then it is passed through the message chain, and back to the protocol before being displayed to the user. When sending, it also goes through the chain but in reverse. Any plugin can register as a 'filter' which means, for the contacts it specifies, it will receive the messages that go through the message chain and it can do with them what it wants. There are several predefined types of filters - encryption, translation, etc - and the type controls the order of the 'chain' - so that e.g. decryption is done before translation. Any properly designed mirnada protocol plugin will do any processing of text within recv'd messages after the chain has been called, and within sent message before the chain is called - like AIM does. Protocols can optionally install their own filters to do processing at other points in the chain. IMO this is the correct way to do this - it allows for proper interoperation of different plugins that affect the contents of messages - and it allows plugins to concentrate on their job, e.g. ecryption, without worrying about any protocol issues. It allows for different encryption plugins to be used with a standard interface - the protocol does not need to know anything about the encryption, and visa versa. But it does mean that encryption plugins are just that - and not protocols that can specify their own rules about message content in the plaintext. The protocol has a right to expect valid protocol messages after decryption. I could just pass the message on to the user directly without continuing through the message chain, but then the message would not be processed by other filters registered for that contact. Miranda doesn't do tag stripping or parsing, because only AIM supports tags in messages. Alright, in a way Jabber does too - but the protocol itself, not the miranda jabber plugin, provides a way to ignore them. Most protocols do not support html in messages. As is proper, it is the protocol's job to convert messages between the network encoding and the internal encoding. Since this is being done already by protocols, and happens automatically in miranda even for OTR encrypted messages, it really should not be re-implemented in the OTR plugin. Why do you allow markup in otr messages? OTR doesn't need it. I'm arguing that the spec should be changed in this respect - I think OTR messages should be allowed to contain anything valid on the underlying protocol, and nothing else. That means OTR can stick to the job of encryption, in any client. I'm not arguing because I'm too lazy to make changes to the plugin - in fact I'm planning a 'html stripper' plugin to get rid of this problem in miranda, and as you say by pinching the code from AIM it's a very small job - but that is not directly related to this discussion. I'm arguing because I think the way the OTR plugin in miranda works now is correct, and OTR should, for the sake of developers for any client, stick to encryption and keep things simple, and not try to call itself a 'protocol' and deal with the encoding issues that entails. Currently, if you look at the code, the miranda OTR plugin and the gaim one are very similar in functionality - neither does parsing of HTML tags, or URL encoding. If the spec was changed to remove the 'optional html markup', then all that needs to be done is for gaim otr to do the encryption/decryption after/before the protocol has made the message valid according to it's own rules - all protocols in all clients must by definition contain the code to do that already. If markup is allowed just because this is difficult to do in gaim, then it's the fault of the way gaim works, and neither the OTR spec nor any OTR plugins should have to shoulder the burden of working around that. On 3/23/07, Ian Goldberg wrote: > > On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: > > >From Wintermute on the Miranda forum: > > > > "Hm .. ok .. the friend made a statement and asked me to post it for him > (as > > he isn't registered here and to lazy to do so): > > > > "Quote: > > I had a lengthy email conversation with Ian Goldberg, one of the authors > of > > OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, > you > > will see that it specifies optional HTML-formating in the plaintext. As > > OTR-messages are merely encapsulated using Jabber (or other) protocols, > Ian > > thinks (as do I after thinking about it) that the OTR specs supersede > the > > standards of "lower level" protocols such as XMPP. It is the job of an > OTR > > plugin to process the HTML tags in the plaintext, if they are not used > by > > the client it's the plugins job to strip them. > > If you don't see it that way, I suggest you contact the otr-dev > > mailinglist." > > > > I think of it quite the opposite way - OTR simply encapsulates protocol > > messages > > > > OTR would have quite a job to do trying to detect whether the client > > supports HTML in Miranda - there are so many messaging modules etc. And > > they're likely to change at any time - it would make maintainence > difficult. > > I don't think tracking the client's capabilities is the plugin's job. > > You're right; I think that whatever calls the OTR plugin should be able > to understand what the plugin outputs. In gaim, there's no problem, > since gaim understands the format of OTR plaintext messages already. > Miranda hasn't (yet?) implemented tag-handling in most of its protocol > plugins, fine. So the Miranda AIM plugin, for example, has to > explicitly strip the tags, instead of parsing them. You could have the > Miranda OTR plugin optionally do that instead; the protocol plugin could > pass a parameter that says "strip the HTML tags from the plaintext > before giving it back to me". Or just have a function in the OTR plugin > to do that (steal it from the AIM plugin) that the protocol plugins can > call. Miranda won't implement tag handling in most of it's protocols, because the specs do not allow for them. Yes, it's easy to copy the code from aim - but I would like to avoid having two copies of the same code in the same application (unless the user can choose to do so, or choose not to without losing functionality - e.g. by installing an optional 'html stripper' plugin) - AIM obviously still needs it for clients without OTR, so it can't simply be moved. Having OTR-specific flags means the protocols need to know something about the encryption that they otherwise would not. To keep the interface standard, other encryption plugins would need to handle such flags as well. And AIM does parse the tags - it will optionally convert them to bbcodes. It's not scalable - to keep OTR message sessions otherwise equivalent to non-otr ones, the OTR plugin would have to to re-implement all similar functionality from all protocol plugins, if and when that functionality exists. > And I think the client should output the same *intended message* whether > or > > not OTR is installed - after decription, OTR messages from gaim OTR > contain > > formatting html, whereas without OTR gaim outputs no formatting html. > > Not true: see my otr-users message. gaim sends *both* the formatted and > non-formatted versions in Jabber. > This > > means transmitting more information than usual - which, although very > > unlikely, may not be something that the user wants. > > There's no more information in the OTR version than in the original > Jabber message. Miranda was just ignoring the more information-rich > part of the Jabber message. Yes, I didn't realise this about Jabber. What about other protocols like ICQ and Yahoo? > Removing the tags means I would have to reimlement something already > > implemented by at least the AIM protocol plugin. Processing the codes > > 'properly' for the client could involve conversion from e.g. html to > > bbcodes, if the client supports those - which would mean differences in > the > > nature of OTR plugins for different clients. Or further, if the OTR spec > > specifies handling of HTML, then the otr library should be able to > handle it > > - but again that's a reimplementation of stuff that the protocol can > already > > do. > > The OTR library gives you a plaintext message, in utf-8 encoding, that > is allowed to have HTML tags in it. If you need something different for > your application, you'll need to convert it. For example, if your > application decides it needs to convert the HTML tags to bbcodes, either > it, or its OTR plugin, will need to do that; libotr won't do it by > default. [Of course, if there's a really common conversion that lots of > different clients need, we could consider just bundling it with the > library.] Yes, with the spec the way it is, that's true. But why is markup specifically allowed? My main point is that if it were not, then I wouldn't have to do that conversion. The secondary point here is that the OTR library should encapsulate the protocol, if it's considered a protocol, in it's entirety - not everything except one little bit. If the OTR library just does encryption/decryption, then, IMO, OTR would be better defined as an encryption layer on top of other protocols. > Also - and I really don't mean to criticize - but the protocol specs for > > things like jabber and other open protocols, with their RFC's and > comittees > > etc etc, tend to be thought out pretty well. The reasons for disallowing > > things like 'mixed contect' (from the jabber RFC) are usually pretty > good. > > For example, if I want to send the text blue to a friend, I > can > > do so over jabber (because it is encoded and decoded by the protocol so > as > > to not create 'mixed content') and expect him to get the message as I > typed > > it, if the client performs to the spec. With OTR, if it's removing tags > on > > clients that do not support markup, how does it tell the difference > between > > formatting tags and what the user has typed? At a minimum it would > somehow > > have to encode tags in message text and formatting tags differently - or > you > > have restricted what messages users can and can't send. > > OTR expects your plaintext input to be HTML-encoded. Which means if > there's a literal "<" in your plaintext message, you should convert it > to "<" before giving it to OTR. That's certainly what Jabber does: > even without OTR, "<"s in messages get converted to "<" on the wire. > So if you send "blue" (a message intending to start > with a literal "<") to your buddy, your end will convert it to > "<font>blue</font>" (whether or not you're using OTR), then > if you're using OTR, you'll pass *that* to the OTR plugin, which will > encrypt it. Your buddy's client will decrypt it back to > "<font>blue</font>" and display it to him as > "blue". Hm - i didn't see anything in the spec saying the plaintext must be URL encoded. I assume you mean that html entities typed in by the user are URL encoded and formatting tags are not? 'Cause that's what gaim otr is sending. If jabber is doing the URL encoding in gaim with OTR, then it does get two goes at the message (URL encoding before encryption, and then again to send the encrypted message), and so it should get two goes at recv'd messages too, if just for the sake of symetry. Which means it's not difficult to let protocols do the job of making otr messages conform to the protocol rules under gaim. But I suspect that in gaim, URL encoding/decoding is actually done by the UI. In miranda, this would mean having another block of code to do a job that is already handled by the jabber protocol plugin. And, for properly designed miranda protocol plugins that will do such text manipulation at the proper point in the message chain, for e.g. compatibility with other encryption plugins, it will mean that OTR messages would be double-URL-encoded - ugh - or OTR would have to know which protocols already do it, and it would need this knowledge to be maintained either by code changes or API changes. Is it very hard to add a hook in gaim, so that OTR can affect messages just before or just after they are sent/recv'd in the network layer? Option 1 benefits (obviously my preferred option) - remove optional html markup from otr spec and change gaim architecture ----- looser coupling/no connection between otr spec and client capabilities - smaller scope of responsibilities for otr plugins - easier to implement in a wider range of clients no doubling-up of code no continued maintenance of miranda otr plugin, possibly other client plugins gaim gets the benefit of added functionality that can be used accross a range of plugins conformance to miranda's existing encryption plugin standards no miranda changes required after the work is done, no negative side-effects ...vs Option 2 benefits - make miranda OTR compliant with current OTR spec: ------ relatively easy to implement so that it works for now, by only changing the miranda plugin no gaim changes required The third option of modifying all miranda's message window plugins (and extensions such as ieview), the miranda messageing API, and probably all protocols, to allow for html markup and to do URL encoding/decoding isn't very practical - the benefit would only be to aim, otr, and jabber at present. Sorry for being so long-winded about this. We're obviously both going to be biased by the environment in which we're working - but shouldn't the end result, in terms of simplicity, 'purity', maintainability, and user experience, be more important than the ease of getting there? As it stands there's no way to implement OTR in Miranda without negative side effects - but it's possible, with more effort, to make everything compliant with no (lasting) negative side effects, and even gain a few positive ones. Am I missing something? ------=_Part_226355_180953.1174620006385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Rmlyc3QgSSYjMzk7bGwgZXhwbGFpbiBob3cgZW5jcnlwdGlvbiB3b3JrcyBpbiBNaXJhbmRhLCB0 aGVuIEkmIzM5O2xsIGFkZHJlc3MgYSBjb3VwbGUgb2YgeW91ciBwb2ludHMuPGJyPjxicj5NaXJh bmRhIGhhcyBhICYjMzk7bWVzc2FnZSBjaGFpbiYjMzk7LiBXaGVuIGEgbWVzc2FnZSBpcyByZWNl aXZlZCwgaXQgZ2V0cyBjb252ZXJ0ZWQgb24gdGhlIG5ldHdvcmsgbGV2ZWwgYnkgdGhlIHByb3Rv Y29sIGludG8gYSBzdGFuZGFyZCBpbnRlcm5hbCBmb3JtYXQuIFRoZW4gaXQgaXMgcGFzc2VkIHRo cm91Z2ggdGhlIG1lc3NhZ2UgY2hhaW4sIGFuZCBiYWNrIHRvIHRoZSBwcm90b2NvbCBiZWZvcmUg YmVpbmcgZGlzcGxheWVkIHRvIHRoZSB1c2VyLiBXaGVuIHNlbmRpbmcsIGl0IGFsc28gZ29lcyB0 aHJvdWdoIHRoZSBjaGFpbiBidXQgaW4gcmV2ZXJzZS4KPGJyPjxicj5BbnkgcGx1Z2luIGNhbiBy ZWdpc3RlciBhcyBhICYjMzk7ZmlsdGVyJiMzOTsgd2hpY2ggbWVhbnMsIGZvciB0aGUgY29udGFj dHMgaXQgc3BlY2lmaWVzLCBpdCB3aWxsIHJlY2VpdmUgdGhlIG1lc3NhZ2VzIHRoYXQgZ28gdGhy b3VnaCB0aGUgbWVzc2FnZSBjaGFpbiBhbmQgaXQgY2FuIGRvIHdpdGggdGhlbSB3aGF0IGl0IHdh bnRzLiBUaGVyZSBhcmUgc2V2ZXJhbCBwcmVkZWZpbmVkIHR5cGVzIG9mIGZpbHRlcnMgLSBlbmNy eXB0aW9uLCB0cmFuc2xhdGlvbiwgZXRjIC0gYW5kIHRoZSB0eXBlIGNvbnRyb2xzIHRoZSBvcmRl ciBvZiB0aGUgJiMzOTtjaGFpbiYjMzk7IC0gc28gdGhhdCAKZS5nLiBkZWNyeXB0aW9uIGlzIGRv bmUgYmVmb3JlIHRyYW5zbGF0aW9uLjxicj48YnI+QW55IHByb3Blcmx5IGRlc2lnbmVkIG1pcm5h ZGEgcHJvdG9jb2wgcGx1Z2luIHdpbGwgZG8gYW55IHByb2Nlc3Npbmcgb2YgdGV4dCB3aXRoaW4g cmVjdiYjMzk7ZCBtZXNzYWdlcyBhZnRlciB0aGUgY2hhaW4gaGFzIGJlZW4gY2FsbGVkLCZuYnNw OyBhbmQgd2l0aGluIHNlbnQgbWVzc2FnZSBiZWZvcmUgdGhlIGNoYWluIGlzIGNhbGxlZCAtIGxp a2UgQUlNIGRvZXMuIFByb3RvY29scyBjYW4gb3B0aW9uYWxseSBpbnN0YWxsIHRoZWlyIG93biBm aWx0ZXJzIHRvIGRvIHByb2Nlc3NpbmcgYXQgb3RoZXIgcG9pbnRzIGluIHRoZSBjaGFpbi4KPGJy Pjxicj5JTU8gdGhpcyBpcyB0aGUgY29ycmVjdCB3YXkgdG8gZG8gdGhpcyAtIGl0IGFsbG93cyBm b3IgcHJvcGVyIGludGVyb3BlcmF0aW9uIG9mIGRpZmZlcmVudCBwbHVnaW5zIHRoYXQgYWZmZWN0 IHRoZSBjb250ZW50cyBvZiBtZXNzYWdlcyAtIGFuZCBpdCBhbGxvd3MgcGx1Z2lucyB0byBjb25j ZW50cmF0ZSBvbiB0aGVpciBqb2IsIGUuZy4gZWNyeXB0aW9uLCB3aXRob3V0IHdvcnJ5aW5nIGFi b3V0IGFueSBwcm90b2NvbCBpc3N1ZXMuIEl0IGFsbG93cyBmb3IgZGlmZmVyZW50IGVuY3J5cHRp b24gcGx1Z2lucyB0byBiZSB1c2VkIHdpdGggYSBzdGFuZGFyZCBpbnRlcmZhY2UgLSB0aGUgcHJv dG9jb2wgZG9lcyBub3QgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBlbmNyeXB0aW9u LCBhbmQgdmlzYSB2ZXJzYS4gQnV0IGl0IGRvZXMgbWVhbiB0aGF0IGVuY3J5cHRpb24gcGx1Z2lu cyBhcmUganVzdCB0aGF0IC0gYW5kIG5vdCBwcm90b2NvbHMgdGhhdCBjYW4gc3BlY2lmeSB0aGVp ciBvd24gcnVsZXMgYWJvdXQgbWVzc2FnZSBjb250ZW50IGluIHRoZSBwbGFpbnRleHQuIFRoZSBw cm90b2NvbCBoYXMgYSByaWdodCB0byBleHBlY3QgdmFsaWQgcHJvdG9jb2wgbWVzc2FnZXMgYWZ0 ZXIgZGVjcnlwdGlvbi4gSSBjb3VsZCBqdXN0IHBhc3MgdGhlIG1lc3NhZ2Ugb24gdG8gdGhlIHVz ZXIgZGlyZWN0bHkgd2l0aG91dCBjb250aW51aW5nIHRocm91Z2ggdGhlIG1lc3NhZ2UgY2hhaW4s IGJ1dCB0aGVuIHRoZSBtZXNzYWdlIHdvdWxkIG5vdCBiZSBwcm9jZXNzZWQgYnkgb3RoZXIgZmls dGVycyByZWdpc3RlcmVkIGZvciB0aGF0IGNvbnRhY3QuCjxicj48YnI+TWlyYW5kYSBkb2VzbiYj Mzk7dCBkbyB0YWcgc3RyaXBwaW5nIG9yIHBhcnNpbmcsIGJlY2F1c2Ugb25seSBBSU0gc3VwcG9y dHMgdGFncyBpbiBtZXNzYWdlcy4gQWxyaWdodCwgaW4gYSB3YXkgSmFiYmVyIGRvZXMgdG9vIC0g YnV0IHRoZSBwcm90b2NvbCBpdHNlbGYsIG5vdCB0aGUgbWlyYW5kYSBqYWJiZXIgcGx1Z2luLCBw cm92aWRlcyBhIHdheSB0byBpZ25vcmUgdGhlbS4gTW9zdCBwcm90b2NvbHMgZG8gbm90IHN1cHBv cnQgaHRtbCBpbiBtZXNzYWdlcy4gQXMgaXMgcHJvcGVyLCBpdCBpcyB0aGUgcHJvdG9jb2wmIzM5 O3Mgam9iIHRvIGNvbnZlcnQgbWVzc2FnZXMgYmV0d2VlbiB0aGUgbmV0d29yayBlbmNvZGluZyBh bmQgdGhlIGludGVybmFsIGVuY29kaW5nLiBTaW5jZSB0aGlzIGlzIGJlaW5nIGRvbmUgYWxyZWFk eSBieSBwcm90b2NvbHMsIGFuZCBoYXBwZW5zIGF1dG9tYXRpY2FsbHkgaW4gbWlyYW5kYSBldmVu IGZvciBPVFIgZW5jcnlwdGVkIG1lc3NhZ2VzLCBpdCByZWFsbHkgc2hvdWxkIG5vdCBiZSByZS1p bXBsZW1lbnRlZCBpbiB0aGUgT1RSIHBsdWdpbi4KPGJyPjxicj5XaHkgZG8geW91IGFsbG93IG1h cmt1cCBpbiBvdHIgbWVzc2FnZXM/IE9UUiBkb2VzbiYjMzk7dCBuZWVkIGl0LiBJJiMzOTttIGFy Z3VpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgYmUgY2hhbmdlZCBpbiB0aGlzIHJlc3BlY3QgLSBJ IHRoaW5rIE9UUiBtZXNzYWdlcyBzaG91bGQgYmUgYWxsb3dlZCB0byBjb250YWluIGFueXRoaW5n IHZhbGlkIG9uIHRoZSB1bmRlcmx5aW5nIHByb3RvY29sLCBhbmQgbm90aGluZyBlbHNlLiBUaGF0 IG1lYW5zIE9UUiBjYW4gc3RpY2sgdG8gdGhlIGpvYiBvZiBlbmNyeXB0aW9uLCBpbiBhbnkgY2xp ZW50Lgo8YnI+PGJyPkkmIzM5O20gbm90IGFyZ3VpbmcgYmVjYXVzZSBJJiMzOTttIHRvbyBsYXp5 IHRvIG1ha2UgY2hhbmdlcyB0byB0aGUgcGx1Z2luIC0gaW4gZmFjdCBJJiMzOTttIHBsYW5uaW5n IGEgJiMzOTtodG1sIHN0cmlwcGVyJiMzOTsgcGx1Z2luIHRvIGdldCByaWQgb2YgdGhpcyBwcm9i bGVtIGluIG1pcmFuZGEsIGFuZCBhcyB5b3Ugc2F5IGJ5IHBpbmNoaW5nIHRoZSBjb2RlIGZyb20g QUlNIGl0JiMzOTtzIGEgdmVyeSBzbWFsbCBqb2IgLSBidXQgdGhhdCBpcyBub3QgZGlyZWN0bHkg cmVsYXRlZCB0byB0aGlzIGRpc2N1c3Npb24uIEkmIzM5O20gYXJndWluZyBiZWNhdXNlIEkgdGhp bmsgdGhlIHdheSB0aGUgT1RSIHBsdWdpbiBpbiBtaXJhbmRhIHdvcmtzIG5vdyBpcyBjb3JyZWN0 LCBhbmQgT1RSIHNob3VsZCwgZm9yIHRoZSBzYWtlIG9mIGRldmVsb3BlcnMgZm9yIGFueSBjbGll bnQsIHN0aWNrIHRvIGVuY3J5cHRpb24gYW5kIGtlZXAgdGhpbmdzIHNpbXBsZSwgYW5kIG5vdCB0 cnkgdG8gY2FsbCBpdHNlbGYgYSAmIzM5O3Byb3RvY29sJiMzOTsgYW5kIGRlYWwgd2l0aCB0aGUg ZW5jb2RpbmcgaXNzdWVzIHRoYXQgZW50YWlscy4gQ3VycmVudGx5LCBpZiB5b3UgbG9vayBhdCB0 aGUgY29kZSwgdGhlIG1pcmFuZGEgT1RSIHBsdWdpbiBhbmQgdGhlIGdhaW0gb25lIGFyZSB2ZXJ5 IHNpbWlsYXIgaW4gZnVuY3Rpb25hbGl0eSAtIG5laXRoZXIgZG9lcyBwYXJzaW5nIG9mIEhUTUwg dGFncywgb3IgVVJMIGVuY29kaW5nLiBJZiB0aGUgc3BlYyB3YXMgY2hhbmdlZCB0byByZW1vdmUg dGhlICYjMzk7b3B0aW9uYWwgaHRtbCBtYXJrdXAmIzM5OywgdGhlbiBhbGwgdGhhdCBuZWVkcyB0 byBiZSBkb25lIGlzIGZvciBnYWltIG90ciB0byBkbyB0aGUgZW5jcnlwdGlvbi9kZWNyeXB0aW9u IGFmdGVyL2JlZm9yZSB0aGUgcHJvdG9jb2wgaGFzIG1hZGUgdGhlIG1lc3NhZ2UgdmFsaWQgYWNj b3JkaW5nIHRvIGl0JiMzOTtzIG93biBydWxlcyAtIGFsbCBwcm90b2NvbHMgaW4gYWxsIGNsaWVu dHMgbXVzdCBieSBkZWZpbml0aW9uIGNvbnRhaW4gdGhlIGNvZGUgdG8gZG8gdGhhdCBhbHJlYWR5 LiBJZiBtYXJrdXAgaXMgYWxsb3dlZCBqdXN0IGJlY2F1c2UgdGhpcyBpcyBkaWZmaWN1bHQgdG8g ZG8gaW4gZ2FpbSwgdGhlbiBpdCYjMzk7cyB0aGUgZmF1bHQgb2YgdGhlIHdheSBnYWltIHdvcmtz LCBhbmQgbmVpdGhlciB0aGUgT1RSIHNwZWMgbm9yIGFueSBPVFIgcGx1Z2lucyBzaG91bGQgaGF2 ZSB0byBzaG91bGRlciB0aGUgYnVyZGVuIG9mIHdvcmtpbmcgYXJvdW5kIHRoYXQuCjxicj48YnI+ PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDMvMjMvMDcsIDxiIGNsYXNzPSJnbWFp bF9zZW5kZXJuYW1lIj5JYW4gR29sZGJlcmc8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuQGN5 cGhlcnB1bmtzLmNhIj5pYW5AY3lwaGVycHVua3MuY2E8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xp ZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmct bGVmdDogMWV4OyI+Ck9uIEZyaSwgTWFyIDIzLCAyMDA3IGF0IDAyOjU1OjIzQU0gKzExMDAsIFNj b3R0IEVsbGlzIHdyb3RlOjxicj4mZ3Q7ICZndDtGcm9tIFdpbnRlcm11dGUgb24gdGhlIE1pcmFu ZGEgZm9ydW06PGJyPiZndDs8YnI+Jmd0OyAmcXVvdDtIbSAuLiBvayAuLiB0aGUgZnJpZW5kIG1h ZGUgYSBzdGF0ZW1lbnQgYW5kIGFza2VkIG1lIHRvIHBvc3QgaXQgZm9yIGhpbSAoYXM8YnI+Jmd0 OyBoZSBpc24mIzM5O3QgcmVnaXN0ZXJlZCBoZXJlIGFuZCB0byBsYXp5IHRvIGRvIHNvKToKPGJy PiZndDs8YnI+Jmd0OyAmcXVvdDtRdW90ZTo8YnI+Jmd0OyBJIGhhZCBhIGxlbmd0aHkgZW1haWwg Y29udmVyc2F0aW9uIHdpdGggSWFuIEdvbGRiZXJnLCBvbmUgb2YgdGhlIGF1dGhvcnMgb2Y8YnI+ Jmd0OyBPVFIsIGxpYm90ciBhbmQgdGhlIGdhaW0tb3RyIHBsdWdpbi4gSWYgeW91IHJlYWQgdGhl IE9UUiBzcGVjIGNhcmVmdWxseSwgeW91PGJyPiZndDsgd2lsbCBzZWUgdGhhdCBpdCBzcGVjaWZp ZXMgb3B0aW9uYWwgSFRNTC1mb3JtYXRpbmcgaW4gdGhlIHBsYWludGV4dC4gQXMKPGJyPiZndDsg T1RSLW1lc3NhZ2VzIGFyZSBtZXJlbHkgZW5jYXBzdWxhdGVkIHVzaW5nIEphYmJlciAob3Igb3Ro ZXIpIHByb3RvY29scywgSWFuPGJyPiZndDsgdGhpbmtzIChhcyBkbyBJIGFmdGVyIHRoaW5raW5n IGFib3V0IGl0KSB0aGF0IHRoZSBPVFIgc3BlY3Mgc3VwZXJzZWRlIHRoZTxicj4mZ3Q7IHN0YW5k YXJkcyBvZiAmcXVvdDtsb3dlciBsZXZlbCZxdW90OyBwcm90b2NvbHMgc3VjaCBhcyBYTVBQLiBJ dCBpcyB0aGUgam9iIG9mIGFuIE9UUgo8YnI+Jmd0OyBwbHVnaW4gdG8gcHJvY2VzcyB0aGUgSFRN TCB0YWdzIGluIHRoZSBwbGFpbnRleHQsIGlmIHRoZXkgYXJlIG5vdCB1c2VkIGJ5PGJyPiZndDsg dGhlIGNsaWVudCBpdCYjMzk7cyB0aGUgcGx1Z2lucyBqb2IgdG8gc3RyaXAgdGhlbS48YnI+Jmd0 OyBJZiB5b3UgZG9uJiMzOTt0IHNlZSBpdCB0aGF0IHdheSwgSSBzdWdnZXN0IHlvdSBjb250YWN0 IHRoZSBvdHItZGV2PGJyPgomZ3Q7IG1haWxpbmdsaXN0LiZxdW90Ozxicj4mZ3Q7PGJyPiZndDsg SSB0aGluayBvZiBpdCBxdWl0ZSB0aGUgb3Bwb3NpdGUgd2F5IC0gT1RSIHNpbXBseSBlbmNhcHN1 bGF0ZXMgcHJvdG9jb2w8YnI+Jmd0OyBtZXNzYWdlczxicj4mZ3Q7PGJyPiZndDsgT1RSIHdvdWxk IGhhdmUgcXVpdGUgYSBqb2IgdG8gZG8gdHJ5aW5nIHRvIGRldGVjdCB3aGV0aGVyIHRoZSBjbGll bnQ8YnI+Jmd0OyBzdXBwb3J0cyBIVE1MIGluIE1pcmFuZGEgLSB0aGVyZSBhcmUgc28gbWFueSBt ZXNzYWdpbmcgbW9kdWxlcyBldGMuIEFuZAo8YnI+Jmd0OyB0aGV5JiMzOTtyZSBsaWtlbHkgdG8g Y2hhbmdlIGF0IGFueSB0aW1lIC0gaXQgd291bGQgbWFrZSBtYWludGFpbmVuY2UgZGlmZmljdWx0 Ljxicj4mZ3Q7IEkgZG9uJiMzOTt0IHRoaW5rIHRyYWNraW5nIHRoZSBjbGllbnQmIzM5O3MgY2Fw YWJpbGl0aWVzIGlzIHRoZSBwbHVnaW4mIzM5O3Mgam9iLjxicj48YnI+WW91JiMzOTtyZSByaWdo dDsgSSB0aGluayB0aGF0IHdoYXRldmVyIGNhbGxzIHRoZSBPVFIgcGx1Z2luIHNob3VsZCBiZSBh YmxlCjxicj50byB1bmRlcnN0YW5kIHdoYXQgdGhlIHBsdWdpbiBvdXRwdXRzLiZuYnNwOyZuYnNw O0luIGdhaW0sIHRoZXJlJiMzOTtzIG5vIHByb2JsZW0sPGJyPnNpbmNlIGdhaW0gdW5kZXJzdGFu ZHMgdGhlIGZvcm1hdCBvZiBPVFIgcGxhaW50ZXh0IG1lc3NhZ2VzIGFscmVhZHkuPGJyPk1pcmFu ZGEgaGFzbiYjMzk7dCAoeWV0PykgaW1wbGVtZW50ZWQgdGFnLWhhbmRsaW5nIGluIG1vc3Qgb2Yg aXRzIHByb3RvY29sCjxicj5wbHVnaW5zLCBmaW5lLiZuYnNwOyZuYnNwO1NvIHRoZSBNaXJhbmRh IEFJTSBwbHVnaW4sIGZvciBleGFtcGxlLCBoYXMgdG88YnI+ZXhwbGljaXRseSBzdHJpcCB0aGUg dGFncywgaW5zdGVhZCBvZiBwYXJzaW5nIHRoZW0uJm5ic3A7Jm5ic3A7WW91IGNvdWxkIGhhdmUg dGhlPGJyPk1pcmFuZGEgT1RSIHBsdWdpbiBvcHRpb25hbGx5IGRvIHRoYXQgaW5zdGVhZDsgdGhl IHByb3RvY29sIHBsdWdpbiBjb3VsZDxicj4KcGFzcyBhIHBhcmFtZXRlciB0aGF0IHNheXMgJnF1 b3Q7c3RyaXAgdGhlIEhUTUwgdGFncyBmcm9tIHRoZSBwbGFpbnRleHQ8YnI+YmVmb3JlIGdpdmlu ZyBpdCBiYWNrIHRvIG1lJnF1b3Q7LiZuYnNwOyZuYnNwO09yIGp1c3QgaGF2ZSBhIGZ1bmN0aW9u IGluIHRoZSBPVFIgcGx1Z2luPGJyPnRvIGRvIHRoYXQgKHN0ZWFsIGl0IGZyb20gdGhlIEFJTSBw bHVnaW4pIHRoYXQgdGhlIHByb3RvY29sIHBsdWdpbnMgY2FuCjxicj5jYWxsLjwvYmxvY2txdW90 ZT48ZGl2Pjxicj5NaXJhbmRhIHdvbiYjMzk7dCBpbXBsZW1lbnQgdGFnIGhhbmRsaW5nIGluIG1v c3Qgb2YgaXQmIzM5O3MgcHJvdG9jb2xzLCBiZWNhdXNlIHRoZSBzcGVjcyBkbyBub3QgYWxsb3cg Zm9yIHRoZW0uIFllcywgaXQmIzM5O3MgZWFzeSB0byBjb3B5IHRoZSBjb2RlIGZyb20gYWltIC0g YnV0IEkgd291bGQgbGlrZSB0byBhdm9pZCBoYXZpbmcgdHdvIGNvcGllcyBvZiB0aGUgc2FtZSBj b2RlIGluIHRoZSBzYW1lIGFwcGxpY2F0aW9uICh1bmxlc3MgdGhlIHVzZXIgY2FuIGNob29zZSB0 byBkbyBzbywgb3IgY2hvb3NlIG5vdCB0byB3aXRob3V0IGxvc2luZyBmdW5jdGlvbmFsaXR5IC0g CmUuZy4gYnkgaW5zdGFsbGluZyBhbiBvcHRpb25hbCAmIzM5O2h0bWwgc3RyaXBwZXImIzM5OyBw bHVnaW4pIC0gQUlNIG9idmlvdXNseSBzdGlsbCBuZWVkcyBpdCBmb3IgY2xpZW50cyB3aXRob3V0 IE9UUiwgc28gaXQgY2FuJiMzOTt0IHNpbXBseSBiZSBtb3ZlZC4gSGF2aW5nIE9UUi1zcGVjaWZp YyBmbGFncyBtZWFucyB0aGUgcHJvdG9jb2xzIG5lZWQgdG8ga25vdyBzb21ldGhpbmcgYWJvdXQg dGhlIGVuY3J5cHRpb24gdGhhdCB0aGV5IG90aGVyd2lzZSB3b3VsZCBub3QuIFRvIGtlZXAgdGhl IGludGVyZmFjZSBzdGFuZGFyZCwgb3RoZXIgZW5jcnlwdGlvbiBwbHVnaW5zIHdvdWxkIG5lZWQg dG8gaGFuZGxlIHN1Y2ggZmxhZ3MgYXMgd2VsbC4gQW5kIEFJTSBkb2VzIHBhcnNlIHRoZSB0YWdz IC0gaXQgd2lsbCBvcHRpb25hbGx5IGNvbnZlcnQgdGhlbSB0byBiYmNvZGVzLiBJdCYjMzk7cyBu b3Qgc2NhbGFibGUgLSB0byBrZWVwIE9UUiBtZXNzYWdlIHNlc3Npb25zIG90aGVyd2lzZSBlcXVp dmFsZW50IHRvIG5vbi1vdHIgb25lcywgdGhlIE9UUiBwbHVnaW4gd291bGQgaGF2ZSB0byB0byBy ZS1pbXBsZW1lbnQgYWxsIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSBmcm9tIGFsbCBwcm90b2NvbCBw bHVnaW5zLCBpZiBhbmQgd2hlbiB0aGF0IGZ1bmN0aW9uYWxpdHkgZXhpc3RzLiAKPGJyPjwvZGl2 Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDog MXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg cGFkZGluZy1sZWZ0OiAxZXg7Ij4mZ3Q7IEFuZCBJIHRoaW5rIHRoZSBjbGllbnQgc2hvdWxkIG91 dHB1dCB0aGUgc2FtZSAqaW50ZW5kZWQgbWVzc2FnZSogd2hldGhlciBvcgo8YnI+Jmd0OyBub3Qg T1RSIGlzIGluc3RhbGxlZCAtIGFmdGVyIGRlY3JpcHRpb24sIE9UUiBtZXNzYWdlcyBmcm9tIGdh aW0gT1RSIGNvbnRhaW48YnI+Jmd0OyBmb3JtYXR0aW5nIGh0bWwsIHdoZXJlYXMgd2l0aG91dCBP VFIgZ2FpbSBvdXRwdXRzIG5vIGZvcm1hdHRpbmcgaHRtbC48YnI+PGJyPk5vdCB0cnVlOiBzZWUg bXkgb3RyLXVzZXJzIG1lc3NhZ2UuJm5ic3A7Jm5ic3A7Z2FpbSBzZW5kcyAqYm90aCogdGhlIGZv cm1hdHRlZCBhbmQKPGJyPm5vbi1mb3JtYXR0ZWQgdmVyc2lvbnMgaW4gSmFiYmVyLjwvYmxvY2tx dW90ZT48ZGl2Pjxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjog MHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Jmd0OyBUaGlzPGJyPiZndDsg bWVhbnMgdHJhbnNtaXR0aW5nIG1vcmUgaW5mb3JtYXRpb24gdGhhbiB1c3VhbCAtIHdoaWNoLCBh bHRob3VnaCB2ZXJ5Cjxicj4mZ3Q7IHVubGlrZWx5LCBtYXkgbm90IGJlIHNvbWV0aGluZyB0aGF0 IHRoZSB1c2VyIHdhbnRzLjxicj48YnI+VGhlcmUmIzM5O3Mgbm8gbW9yZSBpbmZvcm1hdGlvbiBp biB0aGUgT1RSIHZlcnNpb24gdGhhbiBpbiB0aGUgb3JpZ2luYWw8YnI+SmFiYmVyIG1lc3NhZ2Uu Jm5ic3A7Jm5ic3A7TWlyYW5kYSB3YXMganVzdCBpZ25vcmluZyB0aGUgbW9yZSBpbmZvcm1hdGlv bi1yaWNoPGJyPnBhcnQgb2YgdGhlIEphYmJlciBtZXNzYWdlLgo8L2Jsb2NrcXVvdGU+PGRpdj48 YnI+WWVzLCBJIGRpZG4mIzM5O3QgcmVhbGlzZSB0aGlzIGFib3V0IEphYmJlci4gV2hhdCBhYm91 dCBvdGhlciBwcm90b2NvbHMgbGlrZSBJQ1EgYW5kIFlhaG9vPyA8YnI+CjwvZGl2Pjxicj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlk IHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1s ZWZ0OiAxZXg7Ij4mZ3Q7IFJlbW92aW5nIHRoZSB0YWdzIG1lYW5zIEkgd291bGQgaGF2ZSB0byBy ZWltbGVtZW50IHNvbWV0aGluZyBhbHJlYWR5PGJyPiZndDsgaW1wbGVtZW50ZWQgYnkgYXQgbGVh c3QgdGhlIEFJTSBwcm90b2NvbCBwbHVnaW4uIFByb2Nlc3NpbmcgdGhlIGNvZGVzCjxicj4mZ3Q7 ICYjMzk7cHJvcGVybHkmIzM5OyBmb3IgdGhlIGNsaWVudCBjb3VsZCBpbnZvbHZlIGNvbnZlcnNp b24gZnJvbSBlLmcuIGh0bWwgdG88YnI+Jmd0OyBiYmNvZGVzLCBpZiB0aGUgY2xpZW50IHN1cHBv cnRzIHRob3NlIC0gd2hpY2ggd291bGQgbWVhbiBkaWZmZXJlbmNlcyBpbiB0aGU8YnI+Jmd0OyBu YXR1cmUgb2YgT1RSIHBsdWdpbnMgZm9yIGRpZmZlcmVudCBjbGllbnRzLiBPciBmdXJ0aGVyLCBp ZiB0aGUgT1RSIHNwZWMKPGJyPiZndDsgc3BlY2lmaWVzIGhhbmRsaW5nIG9mIEhUTUwsIHRoZW4g dGhlIG90ciBsaWJyYXJ5IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSBpdDxicj4mZ3Q7IC0gYnV0 IGFnYWluIHRoYXQmIzM5O3MgYSByZWltcGxlbWVudGF0aW9uIG9mIHN0dWZmIHRoYXQgdGhlIHBy b3RvY29sIGNhbiBhbHJlYWR5PGJyPiZndDsgZG8uPGJyPjxicj5UaGUgT1RSIGxpYnJhcnkgZ2l2 ZXMgeW91IGEgcGxhaW50ZXh0IG1lc3NhZ2UsIGluIHV0Zi04IGVuY29kaW5nLCB0aGF0Cjxicj5p cyBhbGxvd2VkIHRvIGhhdmUgSFRNTCB0YWdzIGluIGl0LiZuYnNwOyZuYnNwO0lmIHlvdSBuZWVk IHNvbWV0aGluZyBkaWZmZXJlbnQgZm9yPGJyPnlvdXIgYXBwbGljYXRpb24sIHlvdSYjMzk7bGwg bmVlZCB0byBjb252ZXJ0IGl0LiZuYnNwOyZuYnNwO0ZvciBleGFtcGxlLCBpZiB5b3VyPGJyPmFw cGxpY2F0aW9uIGRlY2lkZXMgaXQgbmVlZHMgdG8gY29udmVydCB0aGUgSFRNTCB0YWdzIHRvIGJi Y29kZXMsIGVpdGhlcgo8YnI+aXQsIG9yIGl0cyBPVFIgcGx1Z2luLCB3aWxsIG5lZWQgdG8gZG8g dGhhdDsgbGlib3RyIHdvbiYjMzk7dCBkbyBpdCBieTxicj5kZWZhdWx0LiZuYnNwOyZuYnNwO1tP ZiBjb3Vyc2UsIGlmIHRoZXJlJiMzOTtzIGEgcmVhbGx5IGNvbW1vbiBjb252ZXJzaW9uIHRoYXQg bG90cyBvZjxicj5kaWZmZXJlbnQgY2xpZW50cyBuZWVkLCB3ZSBjb3VsZCBjb25zaWRlciBqdXN0 IGJ1bmRsaW5nIGl0IHdpdGggdGhlCjxicj5saWJyYXJ5Ll08L2Jsb2NrcXVvdGU+PGRpdj48YnI+ WWVzLCB3aXRoIHRoZSBzcGVjIHRoZSB3YXkgaXQgaXMsIHRoYXQmIzM5O3MgdHJ1ZS4gQnV0IHdo eSBpcyBtYXJrdXAgc3BlY2lmaWNhbGx5IGFsbG93ZWQ/IE15IG1haW4gcG9pbnQgaXMgdGhhdCBp ZiBpdCB3ZXJlIG5vdCwgdGhlbiBJIHdvdWxkbiYjMzk7dCBoYXZlIHRvIGRvIHRoYXQgY29udmVy c2lvbi4gVGhlIHNlY29uZGFyeSBwb2ludCBoZXJlIGlzIHRoYXQgdGhlIE9UUiBsaWJyYXJ5IHNo b3VsZCBlbmNhcHN1bGF0ZSB0aGUgcHJvdG9jb2wsIGlmIGl0JiMzOTtzIGNvbnNpZGVyZWQgYSBw cm90b2NvbCwgaW4gaXQmIzM5O3MgZW50aXJldHkgLSBub3QgZXZlcnl0aGluZyBleGNlcHQgb25l IGxpdHRsZSBiaXQuIElmIHRoZSBPVFIgbGlicmFyeSBqdXN0IGRvZXMgZW5jcnlwdGlvbi9kZWNy eXB0aW9uLCB0aGVuLCBJTU8sIE9UUiB3b3VsZCBiZSBiZXR0ZXIgZGVmaW5lZCBhcyBhbiBlbmNy eXB0aW9uIGxheWVyIG9uIHRvcCBvZiBvdGhlciBwcm90b2NvbHMuCjxicj48L2Rpdj48YnI+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xp ZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmct bGVmdDogMWV4OyI+Jmd0OyBBbHNvIC0gYW5kIEkgcmVhbGx5IGRvbiYjMzk7dCBtZWFuIHRvIGNy aXRpY2l6ZSAtIGJ1dCB0aGUgcHJvdG9jb2wgc3BlY3MgZm9yCjxicj4mZ3Q7IHRoaW5ncyBsaWtl IGphYmJlciBhbmQgb3RoZXIgb3BlbiBwcm90b2NvbHMsIHdpdGggdGhlaXIgUkZDJiMzOTtzIGFu ZCBjb21pdHRlZXM8YnI+Jmd0OyBldGMgZXRjLCB0ZW5kIHRvIGJlIHRob3VnaHQgb3V0IHByZXR0 eSB3ZWxsLiBUaGUgcmVhc29ucyBmb3IgZGlzYWxsb3dpbmc8YnI+Jmd0OyB0aGluZ3MgbGlrZSAm IzM5O21peGVkIGNvbnRlY3QmIzM5OyAoZnJvbSB0aGUgamFiYmVyIFJGQykgYXJlIHVzdWFsbHkg cHJldHR5IGdvb2QuCjxicj4mZ3Q7IEZvciBleGFtcGxlLCBpZiBJIHdhbnQgdG8gc2VuZCB0aGUg dGV4dCAmbHQ7Zm9udCZndDtibHVlJmx0Oy9mb250Jmd0OyB0byBhIGZyaWVuZCwgSSBjYW48YnI+ Jmd0OyBkbyBzbyBvdmVyIGphYmJlciAoYmVjYXVzZSBpdCBpcyBlbmNvZGVkIGFuZCBkZWNvZGVk IGJ5IHRoZSBwcm90b2NvbCBzbyBhczxicj4mZ3Q7IHRvIG5vdCBjcmVhdGUgJiMzOTttaXhlZCBj b250ZW50JiMzOTspIGFuZCBleHBlY3QgaGltIHRvIGdldCB0aGUgbWVzc2FnZSBhcyBJIHR5cGVk Cjxicj4mZ3Q7IGl0LCBpZiB0aGUgY2xpZW50IHBlcmZvcm1zIHRvIHRoZSBzcGVjLiBXaXRoIE9U UiwgaWYgaXQmIzM5O3MgcmVtb3ZpbmcgdGFncyBvbjxicj4mZ3Q7IGNsaWVudHMgdGhhdCBkbyBu b3Qgc3VwcG9ydCBtYXJrdXAsIGhvdyBkb2VzIGl0IHRlbGwgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl bjxicj4mZ3Q7IGZvcm1hdHRpbmcgdGFncyBhbmQgd2hhdCB0aGUgdXNlciBoYXMgdHlwZWQ/IEF0 IGEgbWluaW11bSBpdCB3b3VsZCBzb21laG93Cjxicj4mZ3Q7IGhhdmUgdG8gZW5jb2RlIHRhZ3Mg aW4gbWVzc2FnZSB0ZXh0IGFuZCBmb3JtYXR0aW5nIHRhZ3MgZGlmZmVyZW50bHkgLSBvciB5b3U8 YnI+Jmd0OyBoYXZlIHJlc3RyaWN0ZWQgd2hhdCBtZXNzYWdlcyB1c2VycyBjYW4gYW5kIGNhbiYj Mzk7dCBzZW5kLjxicj48YnI+T1RSIGV4cGVjdHMgeW91ciBwbGFpbnRleHQgaW5wdXQgdG8gYmUg SFRNTC1lbmNvZGVkLiZuYnNwOyZuYnNwO1doaWNoIG1lYW5zIGlmCjxicj50aGVyZSYjMzk7cyBh IGxpdGVyYWwgJnF1b3Q7Jmx0OyZxdW90OyBpbiB5b3VyIHBsYWludGV4dCBtZXNzYWdlLCB5b3Ug c2hvdWxkIGNvbnZlcnQgaXQ8YnI+dG8gJnF1b3Q7JmFtcDtsdDsmcXVvdDsgYmVmb3JlIGdpdmlu ZyBpdCB0byBPVFIuJm5ic3A7Jm5ic3A7VGhhdCYjMzk7cyBjZXJ0YWlubHkgd2hhdCBKYWJiZXIg ZG9lczo8YnI+ZXZlbiB3aXRob3V0IE9UUiwgJnF1b3Q7Jmx0OyZxdW90O3MgaW4gbWVzc2FnZXMg Z2V0IGNvbnZlcnRlZCB0byAmcXVvdDsmYW1wO2x0OyZxdW90OyBvbiB0aGUgd2lyZS4KPGJyPlNv IGlmIHlvdSBzZW5kICZxdW90OyZsdDtmb250Jmd0O2JsdWUmbHQ7L2ZvbnQmZ3Q7JnF1b3Q7IChh IG1lc3NhZ2UgaW50ZW5kaW5nIHRvIHN0YXJ0PGJyPndpdGggYSBsaXRlcmFsICZxdW90OyZsdDsm cXVvdDspIHRvIHlvdXIgYnVkZHksIHlvdXIgZW5kIHdpbGwgY29udmVydCBpdCB0bzxicj4mcXVv dDsmYW1wO2x0O2ZvbnQmYW1wO2d0O2JsdWUmYW1wO2x0Oy9mb250JmFtcDtndDsmcXVvdDsgKHdo ZXRoZXIgb3Igbm90IHlvdSYjMzk7cmUgdXNpbmcgT1RSKSwgdGhlbgo8YnI+aWYgeW91JiMzOTty ZSB1c2luZyBPVFIsIHlvdSYjMzk7bGwgcGFzcyAqdGhhdCogdG8gdGhlIE9UUiBwbHVnaW4sIHdo aWNoIHdpbGw8YnI+ZW5jcnlwdCBpdC4mbmJzcDsmbmJzcDtZb3VyIGJ1ZGR5JiMzOTtzIGNsaWVu dCB3aWxsIGRlY3J5cHQgaXQgYmFjayB0bzxicj4mcXVvdDsmYW1wO2x0O2ZvbnQmYW1wO2d0O2Js dWUmYW1wO2x0Oy9mb250JmFtcDtndDsmcXVvdDsgYW5kIGRpc3BsYXkgaXQgdG8gaGltIGFzCjxi cj4mcXVvdDsmbHQ7Zm9udCZndDtibHVlJmx0Oy9mb250Jmd0OyZxdW90Oy48L2Jsb2NrcXVvdGU+ PGRpdj48YnI+SG0gLSBpIGRpZG4mIzM5O3Qgc2VlIGFueXRoaW5nIGluIHRoZSBzcGVjIHNheWlu ZyB0aGUgcGxhaW50ZXh0IG11c3QgYmUgVVJMIGVuY29kZWQuIEkgYXNzdW1lIHlvdSBtZWFuIHRo YXQgaHRtbCBlbnRpdGllcyB0eXBlZCBpbiBieSB0aGUgdXNlciBhcmUgVVJMIGVuY29kZWQgYW5k IGZvcm1hdHRpbmcgdGFncyBhcmUgbm90PyAmIzM5O0NhdXNlIHRoYXQmIzM5O3Mgd2hhdCBnYWlt IG90ciBpcyBzZW5kaW5nLgo8YnI+PGJyPklmIGphYmJlciBpcyBkb2luZyB0aGUgVVJMIGVuY29k aW5nIGluIGdhaW0gd2l0aCBPVFIsIHRoZW4gaXQgZG9lcyBnZXQgdHdvIGdvZXMgYXQgdGhlIG1l c3NhZ2UgKFVSTCBlbmNvZGluZyBiZWZvcmUgZW5jcnlwdGlvbiwgYW5kIHRoZW4gYWdhaW4gdG8g c2VuZCB0aGUgZW5jcnlwdGVkIG1lc3NhZ2UpLCBhbmQgc28gaXQgc2hvdWxkIGdldCB0d28gZ29l cyBhdCByZWN2JiMzOTtkIG1lc3NhZ2VzIHRvbywgaWYganVzdCBmb3IgdGhlIHNha2Ugb2Ygc3lt ZXRyeS4gV2hpY2ggbWVhbnMgaXQmIzM5O3Mgbm90IGRpZmZpY3VsdCB0byBsZXQgcHJvdG9jb2xz IGRvIHRoZSBqb2Igb2YgbWFraW5nIG90ciBtZXNzYWdlcyBjb25mb3JtIHRvIHRoZSBwcm90b2Nv bCBydWxlcyB1bmRlciBnYWltLiBCdXQgSSBzdXNwZWN0IHRoYXQgaW4gZ2FpbSwgVVJMIGVuY29k aW5nL2RlY29kaW5nIGlzIGFjdHVhbGx5IGRvbmUgYnkgdGhlIFVJLgo8YnI+PGJyPkluIG1pcmFu ZGEsIHRoaXMgd291bGQgbWVhbiBoYXZpbmcgYW5vdGhlciBibG9jayBvZiBjb2RlIHRvIGRvIGEg am9iIHRoYXQgaXMgYWxyZWFkeSBoYW5kbGVkIGJ5IHRoZSBqYWJiZXIgcHJvdG9jb2wgcGx1Z2lu LiBBbmQsIGZvciBwcm9wZXJseSBkZXNpZ25lZCBtaXJhbmRhIHByb3RvY29sIHBsdWdpbnMgdGhh dCB3aWxsIGRvIHN1Y2ggdGV4dCBtYW5pcHVsYXRpb24gYXQgdGhlIHByb3BlciBwb2ludCBpbiB0 aGUgbWVzc2FnZSBjaGFpbiwgZm9yIAplLmcuIGNvbXBhdGliaWxpdHkgd2l0aCBvdGhlciBlbmNy eXB0aW9uIHBsdWdpbnMsIGl0IHdpbGwgbWVhbiB0aGF0IE9UUiBtZXNzYWdlcyB3b3VsZCBiZSBk b3VibGUtVVJMLWVuY29kZWQgLSB1Z2ggLSBvciBPVFIgd291bGQgaGF2ZSB0byBrbm93IHdoaWNo IHByb3RvY29scyBhbHJlYWR5IGRvIGl0LCBhbmQgaXQgd291bGQgbmVlZCB0aGlzIGtub3dsZWRn ZSB0byBiZSBtYWludGFpbmVkIGVpdGhlciBieSBjb2RlIGNoYW5nZXMgb3IgQVBJIGNoYW5nZXMu Cjxicj48YnI+SXMgaXQgdmVyeSBoYXJkIHRvIGFkZCBhIGhvb2sgaW4gZ2FpbSwgc28gdGhhdCBP VFIgY2FuIGFmZmVjdCBtZXNzYWdlcyBqdXN0IGJlZm9yZSBvciBqdXN0IGFmdGVyIHRoZXkgYXJl IHNlbnQvcmVjdiYjMzk7ZCBpbiB0aGUgbmV0d29yayBsYXllcj88YnI+PGJyPk9wdGlvbiAxIGJl bmVmaXRzIChvYnZpb3VzbHkgbXkgcHJlZmVycmVkIG9wdGlvbikmbmJzcDsgLSByZW1vdmUgb3B0 aW9uYWwgaHRtbCBtYXJrdXAgZnJvbSBvdHIgc3BlYyBhbmQgY2hhbmdlIGdhaW0gYXJjaGl0ZWN0 dXJlCjxicj4tLS0tLTxicj5sb29zZXIgY291cGxpbmcvbm8gY29ubmVjdGlvbiBiZXR3ZWVuIG90 ciBzcGVjIGFuZCBjbGllbnQgY2FwYWJpbGl0aWVzIC0gc21hbGxlciBzY29wZSBvZiByZXNwb25z aWJpbGl0aWVzIGZvciBvdHIgcGx1Z2lucyAtIGVhc2llciB0byBpbXBsZW1lbnQgaW4gYSB3aWRl ciByYW5nZSBvZiBjbGllbnRzPGJyPm5vIGRvdWJsaW5nLXVwIG9mIGNvZGU8YnI+bm8gY29udGlu dWVkIG1haW50ZW5hbmNlIG9mIG1pcmFuZGEgb3RyIHBsdWdpbiwgcG9zc2libHkgb3RoZXIgY2xp ZW50IHBsdWdpbnMKPGJyPmdhaW0gZ2V0cyB0aGUgYmVuZWZpdCBvZiBhZGRlZCBmdW5jdGlvbmFs aXR5IHRoYXQgY2FuIGJlIHVzZWQgYWNjcm9zcyBhIHJhbmdlIG9mIHBsdWdpbnM8YnI+Y29uZm9y bWFuY2UgdG8gbWlyYW5kYSYjMzk7cyBleGlzdGluZyBlbmNyeXB0aW9uIHBsdWdpbiBzdGFuZGFy ZHM8YnI+bm8gbWlyYW5kYSBjaGFuZ2VzIHJlcXVpcmVkPGJyPmFmdGVyIHRoZSB3b3JrIGlzIGRv bmUsIG5vIG5lZ2F0aXZlIHNpZGUtZWZmZWN0cwo8YnI+Cjxicj4uLi52cyBPcHRpb24gMiBiZW5l Zml0cyAtIG1ha2UgbWlyYW5kYSBPVFIgY29tcGxpYW50IHdpdGggY3VycmVudCBPVFIgc3BlYzo8 YnI+LS0tLS0tPGJyPnJlbGF0aXZlbHkgZWFzeSB0byBpbXBsZW1lbnQgc28gdGhhdCBpdCB3b3Jr cyBmb3Igbm93LCBieSBvbmx5IGNoYW5naW5nIHRoZSBtaXJhbmRhIHBsdWdpbjxicj5ubyBnYWlt IGNoYW5nZXMgcmVxdWlyZWQ8YnI+PGJyPlRoZSB0aGlyZCBvcHRpb24gb2YgbW9kaWZ5aW5nIGFs bCBtaXJhbmRhJiMzOTtzIG1lc3NhZ2Ugd2luZG93IHBsdWdpbnMgKGFuZCBleHRlbnNpb25zIHN1 Y2ggYXMgaWV2aWV3KSwgdGhlIG1pcmFuZGEgbWVzc2FnZWluZyBBUEksIGFuZCBwcm9iYWJseSBh bGwgcHJvdG9jb2xzLCB0byBhbGxvdyBmb3IgaHRtbCBtYXJrdXAgYW5kIHRvIGRvIFVSTCBlbmNv ZGluZy9kZWNvZGluZyBpc24mIzM5O3QgdmVyeSBwcmFjdGljYWwgLSB0aGUgYmVuZWZpdCB3b3Vs ZCBvbmx5IGJlIHRvIGFpbSwgb3RyLCBhbmQgamFiYmVyIGF0IHByZXNlbnQuCjxicj48YnI+U29y cnkgZm9yIGJlaW5nIHNvIGxvbmctd2luZGVkIGFib3V0IHRoaXMuIFdlJiMzOTtyZSBvYnZpb3Vz bHkgYm90aCBnb2luZyB0byBiZSBiaWFzZWQgYnkgdGhlIGVudmlyb25tZW50IGluIHdoaWNoIHdl JiMzOTtyZSB3b3JraW5nIC0gYnV0IHNob3VsZG4mIzM5O3QgdGhlIGVuZCByZXN1bHQsIGluIHRl cm1zIG9mIHNpbXBsaWNpdHksICYjMzk7cHVyaXR5JiMzOTssIG1haW50YWluYWJpbGl0eSwgYW5k IHVzZXIgZXhwZXJpZW5jZSwgYmUgbW9yZSBpbXBvcnRhbnQgdGhhbiB0aGUgZWFzZSBvZiBnZXR0 aW5nIHRoZXJlPyBBcyBpdCBzdGFuZHMgdGhlcmUmIzM5O3Mgbm8gd2F5IHRvIGltcGxlbWVudCBP VFIgaW4gTWlyYW5kYSB3aXRob3V0IG5lZ2F0aXZlIHNpZGUgZWZmZWN0cyAtIGJ1dCBpdCYjMzk7 cyBwb3NzaWJsZSwgd2l0aCBtb3JlIGVmZm9ydCwgdG8gbWFrZSBldmVyeXRoaW5nIGNvbXBsaWFu dCB3aXRoIG5vIChsYXN0aW5nKSBuZWdhdGl2ZSBzaWRlIGVmZmVjdHMsIGFuZCBldmVuIGdhaW4g YSBmZXcgcG9zaXRpdmUgb25lcy4KPGJyPjxicj5BbSBJIG1pc3Npbmcgc29tZXRoaW5nPzxicj48 L2Rpdj48L2Rpdj4K ------=_Part_226355_180953.1174620006385-- From stpeter@jabber.org Mon Mar 26 16:55:03 2007 From: stpeter@jabber.org (Peter Saint-Andre) Date: Mon, 26 Mar 2007 09:55:03 -0600 Subject: [OTR-dev] html in otr messages In-Reply-To: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> <20070322181700.GF23856@thunk.cs.uwaterloo.ca> Message-ID: <4607ECD7.2080507@jabber.org> This is a cryptographically signed message in MIME format. --------------ms050200030005010506070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Goldberg wrote: > On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: >> >From Wintermute on the Miranda forum: >> I had a lengthy email conversation with Ian Goldberg, one of the authors of >> OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you >> will see that it specifies optional HTML-formating in the plaintext. As >> OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian >> thinks (as do I after thinking about it) that the OTR specs supersede the >> standards of "lower level" protocols such as XMPP. It is the job of an OTR >> plugin to process the HTML tags in the plaintext, if they are not used by >> the client it's the plugins job to strip them. >> If you don't see it that way, I suggest you contact the otr-dev >> mailinglist." >> >> I think of it quite the opposite way - OTR simply encapsulates protocol >> messages >> >> OTR would have quite a job to do trying to detect whether the client >> supports HTML in Miranda - there are so many messaging modules etc. And >> they're likely to change at any time - it would make maintainence difficult. >> I don't think tracking the client's capabilities is the plugin's job. > > You're right; I think that whatever calls the OTR plugin should be able > to understand what the plugin outputs. Does this apply only to [X]HTML formatting? The reason I ask is that people put other kinds of extensions in Jabber messages, and in fact we have packet types other than ( and ). People would like to encrypt the entire packet for all XMPP packet types, not just the plaintext (or XHTML-formatted) message body, but we have not figured out how to do that in OTR, which is one reason why we are pursuing other approaches to end-to-end encryption: http://www.xmpp.org/extensions/xep-0116.html Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms050200030005010506070907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDMyNjE1NTUwM1owIwYJKoZIhvcNAQkEMRYEFB5Wv1LdF1KBjILSVByL5QQk7z08MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAEXPXd5dzq4cCvadezzwbJV6QPNzBYgOut1MLmzGdjV/ gZck6CGfuYYUbPLm1HsNhRTqkNJ9Hz2CtwxmVeLrdXZ9eFr095kpu5q3YfU2pa69OhViqMNj 5jqYJp2nDXwBZAgbnwTth8kvYlYPR6Z4teek+tNknYPpfeR0qcEF9VruIB1LIVM+AAL1bDdn wV6PAJl+5M5znBMpKHwnlevWhRXaMw8XfWYi+18b9xWyZrSEUzGKRCugX9s//IUBwqW9IiNk NtKbjnFeIlx1hdLUpxqPMpHgYPOF+PheSPKs9jfNJk5Qj9xcMzTMjtAGTvQ0ihGY/hVEMHZJ 4WcoRIjHjEAAAAAAAAA= --------------ms050200030005010506070907-- From ogoffart@kde.org Fri Mar 30 14:28:49 2007 From: ogoffart@kde.org (Olivier Goffart) Date: Fri, 30 Mar 2007 15:28:49 +0200 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd Message-ID: <200703301528.54920.ogoffart@kde.org> --nextPart1622750.uuxVPSQP6Q Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I have developed a module for ejabberd (A widely used Jabber server) that = do=20 the man in the middle attack on OTR messages. I made this module to show that it is not possible to make e2e encryption u= ser=20 friendly. (for those who want an easy-to-use enabled-by-default e2e=20 encryption) Lamda user (who doesn't really care about security) will not check=20 fingerprint. So now, check your fingerprints :-) mod_otr: http://ejabberd.jabber.ru/mod_otr announcement: http://blog.bepointbe.be/index.php/2007/03/29/20-mod_otr =2D-=20 Olivier --nextPart1622750.uuxVPSQP6Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGDRCSz58lY8jWrL0RAh0RAJ9W6RBw1v/F8P2bI2Xj0puuMvS1VgCfT8ER MAHhHKFFhDFc0gsZ7Yy+DSg= =ip3P -----END PGP SIGNATURE----- --nextPart1622750.uuxVPSQP6Q-- From paul@cypherpunks.ca Sat Mar 31 19:38:19 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Sat, 31 Mar 2007 20:38:19 +0200 (CEST) Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: <200703301528.54920.ogoffart@kde.org> References: <200703301528.54920.ogoffart@kde.org> Message-ID: On Fri, 30 Mar 2007, Olivier Goffart wrote: > I have developed a module for ejabberd (A widely used Jabber server) that do > the man in the middle attack on OTR messages. Excellent! > I made this module to show that it is not possible to make e2e encryption user > friendly. I would call OTR pretty userfriendly.... > So now, check your fingerprints :-) > mod_otr: http://ejabberd.jabber.ru/mod_otr I'll have to play with this! Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155