From a.sporto+bee@gmail.com Mon Jun 2 03:07:26 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Mon, 2 Jun 2008 02:07:26 +0000 (UTC) Subject: [OTR-dev] SMP state machine broken? Message-ID: Hiho, first of all thanks for OTR! I'm developing an OTR module for the irssi IRC client [1]. It is already quite usable, no matter if you use plain IRC or bitlbee. However, I had lot's of trouble with implementing SMP authentication because the SMP state machine is apparently broken - please correct me here if I am wrong. I managed to get so far that Bob can authenticate Alice (assuming Alice started). But Alice can never be sure that it's Bob because Alice never decodes TLV_SMP4, simply because it never expects it. A simple grep SMP_EXPECT4 on the source reveals that this state is never reached. What also surprised me is that there are no callbacks for smp. Additionally, the state is never reset to EXPECT1 unless abort is called. Therefore, one has to replicate the SMP state machine in his/her application and track in and outgoing messages in order to give any feedback to the user. I wonder how other implementations deal with this? Are people patching libotr? Is it known to work both ways with any client? Maybe I'm just not up to date, is there a VCS somewhere? I only found the source tarball. Thanks for any feedback. Uli [1] http://projects.tuxfamily.org/group.pl?name=irssiotr From ian@cypherpunks.ca Tue Jun 3 13:44:49 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 3 Jun 2008 08:44:49 -0400 Subject: [OTR-dev] SMP state machine broken? In-Reply-To: References: Message-ID: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> On Mon, Jun 02, 2008 at 02:07:26AM +0000, Uli M wrote: > Hiho, > > first of all thanks for OTR! > > I'm developing an OTR module for the irssi IRC client [1]. It is > already quite usable, no matter if you use plain IRC or bitlbee. > However, I had lot's of trouble with implementing SMP authentication > because the SMP state machine is apparently broken - please correct me > here if I am wrong. > > I managed to get so far that Bob can authenticate Alice (assuming > Alice started). But Alice can never be sure that it's Bob because > Alice never decodes TLV_SMP4, simply because it never expects it. A > simple grep SMP_EXPECT4 on the source reveals that this state is never > reached. > > What also surprised me is that there are no callbacks for smp. > Additionally, the state is never reset to EXPECT1 unless abort is > called. Therefore, one has to replicate the SMP state machine in > his/her application and track in and outgoing messages in order to > give any feedback to the user. > > I wonder how other implementations deal with this? Are people patching > libotr? Is it known to work both ways with any client? > > Maybe I'm just not up to date, is there a VCS somewhere? I only found > the source tarball. This is part of the current API problems we're working on cleaning up. Right now, there's some stuff libotr does for you, and some you need to do in the calling application. This was done to avoid adding another callback (since the application, not the library, needs to handle certain cases), but I agree that it's very messy, and one or more callbacks will be the way it'll be handled in v4. For now, see the UPGRADING file in the libotr source to see how to add the necessary support into your application. Also, you can find the current cvs at sourceforge: http://sourceforge.net/cvs/?group_id=128860 - Ian From a.sporto+bee@gmail.com Wed Jun 4 22:13:29 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Wed, 4 Jun 2008 21:13:29 +0000 (UTC) Subject: [OTR-dev] Re: SMP state machine broken? References: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> Message-ID: Hi Ian, thanks for your answer, I do see things more clearly now :) On 2008-06-03, Ian Goldberg wrote: [snip] > This is part of the current API problems we're working on cleaning up. > Right now, there's some stuff libotr does for you, and some you need to > do in the calling application. This was done to avoid adding another > callback (since the application, not the library, needs to handle > certain cases), but I agree that it's very messy, and one or more > callbacks will be the way it'll be handled in v4. That sounds like a good idea to me. > For now, see the UPGRADING file in the libotr source to see how to add > the necessary support into your application. That file was indeed my only source of information when implementing SMP and I see now that the code snippet in there is meant as a template for applications and not (as I understood it) as a description of the libotr implementation. What misleaded me was that it is first said "You may access context->smstate->nextExpected to find out which TLV should come next" and then it says "A typical control flow looks like this:" Because of this introduction and the fact that nextExpected is not only read but also written to in the code snippet I assumed this is libotr code. I imagine other people could misunderstand this as well. > Also, you can find the current cvs at sourceforge: > > http://sourceforge.net/cvs/?group_id=128860 Thanks! One thing I noticed in the diff to 3.1.0 is that apparently something like s/3.1.0/3.2.0/ was applied to the code which lead to a passage that states that fragmentation was introduced in 3.2.0. I'm guessing that is not meant to be. Thanks, Uli From ian@cypherpunks.ca Thu Jun 5 18:40:31 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 5 Jun 2008 13:40:31 -0400 Subject: [OTR-dev] Re: SMP state machine broken? In-Reply-To: References: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> Message-ID: <20080605174031.GJ19116@thunk.cs.uwaterloo.ca> On Wed, Jun 04, 2008 at 09:13:29PM +0000, Uli M wrote: > Thanks! One thing I noticed in the diff to 3.1.0 is that apparently > something like s/3.1.0/3.2.0/ was applied to the code which lead to a > passage that states that fragmentation was introduced in 3.2.0. I'm > guessing that is not meant to be. Yeah, I guess that's a little ambiguous. As it stands now, it talks about the changes from 3.0.0 to 3.2.0, and is not clear which parts were in 3.1.0 and which are new in 3.2.0. I'll add that to the list of things to fix before 3.2.0 release. Thanks, - Ian From orymate@gmail.com Sun Jun 8 19:04:51 2008 From: orymate@gmail.com (=?ISO-8859-2?Q?=D5ry_M=E1t=E9?=) Date: Sun, 8 Jun 2008 20:04:51 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> Message-ID: <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> ------=_Part_10933_23151869.1212948291654 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 Content-Disposition: inline RGVhciBJYW4sCgo+ICAgIENhbiB5b3UgdXBkYXRlIHlvdXIgdHJhbnNsYXRpb25zIGZpbGUgdG8g aW5jbHVkZSB0aGUgbmV3IHRleHQgZnJvbQo+ICAgIHRoZSBuZXcgdmVyc2lvbj8gIFNlZSBwby9S RUFETUUgZm9yIHN1cGVyLWJyaWVmIGluc3RydWN0aW9ucywgb3IKPiAgICBlbWFpbCBtZSBpZiB5 b3UncmUgaGF2aW5nIHRyb3VibGUuCgpJIGhhdmUgdXBkYXRlZCB0aGUgSHVuZ2FyaWFuIHRyYW5z bGF0aW9uIG9mIGdhaW0tb3RyLiBJIGZvdW5kIHNvbWUKbWVzc2FnZXMsIHdoaWNoIG9uZXMgd2Vy ZSBoYXJkIHRvIHRyYW5zbGF0ZSB0byBIdW5nYXJpYW4uIEkndmUgbWFkZQpzb21lIGNvbW1lbnRz IGZvciB0cmFuc2xhdG9ycywgYW5kIEkgaGF2ZSBtb2RpZmllZCB0d28gbWVzc2FnZXMsCmJlY2F1 c2UgdGhleSBjb3VsZG4ndCBiZSB0cmFuc2xhdGVkIHRvIEh1bmdhcmlhbiAod2hpY2ggaXMgYW4K YWdnbHV0aW5hdGluZyBsYW5ndWFnZSB1bmxpa2UgRW5nbGlzaCwgd2hpY2ggaXMgbWFpbmx5IGlz b2xhdGluZykuCgpUaGUgdHJhbnNsYXRpb24gaXMgbWFkZSBmb3IgdGhlIG1vZGlmaWVkIGNvZGUu IEkgaGF2ZSBub3QgdGVzdGVkIGl0LApub3IgY29tcGlsZWQuCgooT3VyIGdub21lIHRyYW5zbGF0 aW9uIHByb2plY3QgbGVhZGVyIHN1Z2dlc3RlZCB0aGlzIHNvdW5kdHJhY2tbMl0gYXMKYSBwdW5p c2htZW50IGZvciB0aGUgZGV2ZWxvcGVyIHdobyBzcGxpdHMgc2VudGVuY2VzWzFdIHRoYXQgd2F5 ICA7KSkKCjEgaHR0cDovL2xpdmUuZ25vbWUub3JnL1RyYW5zbGF0aW9uUHJvamVjdC9EZXZHdWlk ZWxpbmVzL05ldmVyJTIwc3BsaXQlMjBzZW50ZW5jZXMKMiBodHRwOi8veW91dHViZS5jb20vd2F0 Y2g/dj1PeUJ3UUtxSjYtawoKLS0gCtVyeSBN4XTpIChNYXRlIE9SWSkK ------=_Part_10933_23151869.1212948291654 Content-Type: application/octet-stream; name=i18n.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_fh7xi73a0 Content-Disposition: attachment; filename=i18n.diff SW5kZXg6IGd0ay1kaWFsb2cuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3Zzcm9vdC9vdHIvZ2Fp bS1vdHIvZ3RrLWRpYWxvZy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjIzCmRpZmYgLXUgLXIx LjIzIGd0ay1kaWFsb2cuYwotLS0gZ3RrLWRpYWxvZy5jCTI5IE1heSAyMDA4IDIxOjE5OjIyIC0w MDAwCTEuMjMKKysrIGd0ay1kaWFsb2cuYwk4IEp1biAyMDA4IDE3OjQyOjA2IC0wMDAwCkBAIC05 MjMsNyArOTIzLDkgQEAKIAogICAgIGRpYWxvZyA9IGd0a19kaWFsb2dfbmV3X3dpdGhfYnV0dG9u cygKIAkgICAgY29udGV4dC0+c21zdGF0ZS0+cmVjZWl2ZWRfcXVlc3Rpb24gPworICAgICAgICAg ICAgLyogVHJhbnNsYXRvcnM6IHlvdSBhcmUgYXNrZWQgdG8gYXV0aGVudGljYXRlIHlvdXJzZWxm ICovCiAJICAgIF8oIkF1dGhlbnRpY2F0aW5nIHRvIEJ1ZGR5IikgOgorICAgICAgICAgICAgLyog VHJhbnNsYXRvcnM6IHlvdSBhc2tlZCB5b3VyIGJ1ZGR5IHRvIGF1dGhlbnRpY2F0ZSBoaW0vaGVy c2VsZiAqLwogCSAgICBfKCJBdXRoZW50aWNhdGluZyBCdWRkeSIpLAogCSAgICBwYXJlbnQsIDAs IEdUS19TVE9DS19DQU5DRUwsIEdUS19SRVNQT05TRV9SRUpFQ1QsCiAJICAgIEdUS19TVE9DS19P SywgR1RLX1JFU1BPTlNFX0FDQ0VQVCwgTlVMTCk7CkBAIC05NTAsOSArOTUyLDEwIEBACiAgICAg Z3RrX2JveF9wYWNrX3N0YXJ0KEdUS19CT1goaGJveCksIGltZywgRkFMU0UsIEZBTFNFLCAwKTsK IAogICAgIGxhYmVsX3RleHQgPSBnX3N0cmR1cF9wcmludGYoCi0JICAgICAgICI8c3BhbiB3ZWln aHQ9XCJib2xkXCIgc2l6ZT1cImxhcmdlclwiPiVzICVzPC9zcGFuPlxuIiwKLQkgICAgICAgY29u dGV4dC0+c21zdGF0ZS0+cmVjZWl2ZWRfcXVlc3Rpb24gPyBfKCJBdXRoZW50aWNhdGluZyB0byIp Ci0JICAgICAgIDogXygiQXV0aGVudGljYXRpbmciKSwgY29udGV4dC0+dXNlcm5hbWUpOworCSAg ICAgICBjb250ZXh0LT5zbXN0YXRlLT5yZWNlaXZlZF9xdWVzdGlvbiA/CisgICAgICAgICAgICAg ICBfKCI8c3BhbiB3ZWlnaHQ9XCJib2xkXCIgc2l6ZT1cImxhcmdlclwiPkF1dGhlbnRpY2F0aW5n IHRvICVzPC9zcGFuPlxuIikgOgorCSAgICAgICBfKCI8c3BhbiB3ZWlnaHQ9XCJib2xkXCIgc2l6 ZT1cImxhcmdlclwiPkF1dGhlbnRpY2F0aW5nICVzPC9zcGFuPlxuIiksCisgICAgICAgICAgICAg ICBjb250ZXh0LT51c2VybmFtZSk7CiAKICAgICBsYWJlbCA9IGd0a19sYWJlbF9uZXcoTlVMTCk7 CiAKQEAgLTE0MzgsOSArMTQ0MSwxNSBAQAogCiAgICAgaGJveCA9IGd0a19oYm94X25ldyhGQUxT RSwgMCk7CiAgICAgY29tYm8gPSBndGtfY29tYm9fYm94X25ld190ZXh0KCk7CisgICAgLyogVHJh bnNsYXRvcnM6IHRoZSBmb2xsb3dpbmcgZm91ciBtZXNzYWdlcyBzaG91bGQgZ2l2ZSBhbHRlcm5h dGl2ZSBzZW50ZW5jZXMuCisgICAgICAgVGhlIHVzZXIgc2VsZWN0cyB0aGUgZmlyc3Qgb3Igc2Vj b25kIG1lc3NhZ2UgaW4gYSBjb21ibyBib3g7CisgICAgICB0aGUgdGhpcmQgbWVzc2FnZSwgYSBu ZXcgbGluZSwgYSBmaW5nZXJwcmludCwgYSBuZXcgbGluZSwgYW5kIAorICAgICAgdGhlIGZvdXJ0 aCBtZXNzYWdlIHdpbGwgZm9sbG93IGl0LiAqLwogICAgIGd0a19jb21ib19ib3hfYXBwZW5kX3Rl eHQoR1RLX0NPTUJPX0JPWChjb21ibyksIF8oIkkgaGF2ZSBub3QiKSk7CisgICAgLyogMm5kIG1l c3NhZ2UgKi8KICAgICBndGtfY29tYm9fYm94X2FwcGVuZF90ZXh0KEdUS19DT01CT19CT1goY29t Ym8pLCBfKCJJIGhhdmUiKSk7CiAgICAgZ3RrX2NvbWJvX2JveF9zZXRfYWN0aXZlKEdUS19DT01C T19CT1goY29tYm8pLCB2ZXJpZmllZCk7CisgICAgLyogM3JkIG1lc3NhZ2UgKi8KICAgICBsYWJl bCA9IGd0a19sYWJlbF9uZXcoXygiIHZlcmlmaWVkIHRoYXQgdGhpcyBpcyBpbiBmYWN0IHRoZSBj b3JyZWN0IikpOwogICAgIGd0a19ib3hfcGFja19zdGFydChHVEtfQk9YKGhib3gpLCBjb21ibywg RkFMU0UsIEZBTFNFLCAwKTsKICAgICBndGtfYm94X3BhY2tfc3RhcnQoR1RLX0JPWChoYm94KSwg bGFiZWwsIEZBTFNFLCBGQUxTRSwgMCk7CkBAIC0xNDUwLDYgKzE0NTksNyBAQAogCSAgICBHX0NB TExCQUNLKHZyZnlfZmluZ2VycHJpbnRfY2hhbmdlZCksIHZmZCk7CiAKICAgICBoYm94ID0gZ3Rr X2hib3hfbmV3KEZBTFNFLCAwKTsKKyAgICAvKiA0dGggbWVzc2FnZSAqLwogICAgIGxhYmVsdCA9 IGdfc3RyZHVwX3ByaW50ZihfKCJmaW5nZXJwcmludCBmb3IgJXMuIiksCiAJICAgIHZmZC0+dXNl cm5hbWUpOwogICAgIGxhYmVsID0gZ3RrX2xhYmVsX25ldyhsYWJlbHQpOwo= ------=_Part_10933_23151869.1212948291654 Content-Type: application/octet-stream; name=hu.po Content-Transfer-Encoding: base64 X-Attachment-Id: f_fh7xilc91 Content-Disposition: attachment; filename=hu.po IyB0cmFuc2xhdGlvbiBvZiBodS5wbyB0byBIdW5nYXJpYW4KIyBDb3B5cmlnaHQgKEMpIDIwMDQt MjAwOCAgSWFuIEdvbGRiZXJnLCBSb2IgU21pdHMsCiMgICAgICAgICAgICAgICAgICAgICAgICAg IENocmlzIEFsZXhhbmRlciwgTmlraXRhIEJvcmlzb3YKIyBUaGlzIGZpbGUgaXMgZGlzdHJpYnV0 ZWQgdW5kZXIgdGhlIHNhbWUgbGljZW5zZSBhcyB0aGUgcGlkZ2luLW90ciBwYWNrYWdlLgojCiMg TWF0ZSBPcnkgPG9yeW1hdGVAZ21haWwuY29tPiwgMjAwOC4KbXNnaWQgIiIKbXNnc3RyICIiCiJQ cm9qZWN0LUlkLVZlcnNpb246IGh1XG4iCiJSZXBvcnQtTXNnaWQtQnVncy1UbzogXG4iCiJQT1Qt Q3JlYXRpb24tRGF0ZTogMjAwOC0wNi0wOCAxOTozOCswMjAwXG4iCiJQTy1SZXZpc2lvbi1EYXRl OiAyMDA4LTA2LTA4IDE5OjA1KzAyMDBcbiIKIkxhc3QtVHJhbnNsYXRvcjogTWF0ZSBPcnkgPG9y eW1hdGVAZ21haWwuY29tPlxuIgoiTGFuZ3VhZ2UtVGVhbTogSHVuZ2FyaWFuIDx1YnVudHUtbDEw bi1odUBsaXN0cy51YnVudHUuY29tPlxuIgoiTUlNRS1WZXJzaW9uOiAxLjBcbiIKIkNvbnRlbnQt VHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOFxuIgoiQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdFxuIgoiUGx1cmFsLUZvcm1zOiAgbnBsdXJhbHM9MjsgcGx1cmFsPShuICE9IDEp O1xuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjI5MSAuLi9ndGstZGlhbG9nLmM6MTE0MyAuLi9ndGst ZGlhbG9nLmM6MTE0NwojOiAuLi9ndGstZGlhbG9nLmM6MTMwOSAuLi9ndGstZGlhbG9nLmM6MTQ4 NyAuLi9ndGstZGlhbG9nLmM6MTY2OAojOiAuLi9ndGstZGlhbG9nLmM6MTc3MSAuLi9ndGstZGlh bG9nLmM6MTg2MiAuLi9ndGstZGlhbG9nLmM6MjMwOAptc2dpZCAiP2xhbmc9ZW4iCm1zZ3N0ciAi P2xhbmc9aHUiCgojOiAuLi9ndGstZGlhbG9nLmM6NDQwIC4uL2d0ay1kaWFsb2cuYzoyMDQyIC4u L2d0ay1kaWFsb2cuYzoyNTE2Cm1zZ2lkICJfV2hhdCdzIHRoaXM/Igptc2dzdHIgIl9NaSBlej8i CgojOiAuLi9ndGstZGlhbG9nLmM6NDc1Cm1zZ2lkICIiCiJZb3VyIGJ1ZGR5IGlzIGF0dGVtcHRp bmcgdG8gZGV0ZXJtaW5lIGlmIGhlIG9yIHNoZSBpcyByZWFsbHkgdGFsa2luZyB0byB5b3UsICIK Im9yIGlmIGl0J3Mgc29tZW9uZSBwcmV0ZW5kaW5nIHRvIGJlIHlvdS4gIFlvdXIgYnVkZHkgaGFz IGFza2VkIGEgcXVlc3Rpb24sICIKImluZGljYXRlZCBiZWxvdy4gIFRvIGF1dGhlbnRpY2F0ZSB0 byB5b3VyIGJ1ZGR5LCBlbnRlciB0aGUgYW5zd2VyIGFuZCBjbGljayAiCiJPSy4iCm1zZ3N0ciAi IgoiQSBwYXJ0bmVyZSBlbCBzemVyZXRuw6kgZMO2bnRlbmksIGhvZ3kgdmFsw7NiYW4gYXp6YWwg YmVzesOpbC1lLCBha2luZWsgw7ZuIG1hZ8OhdCAiCiLDoWxsw610amEuIEZlbHRldHRlIGF6IGFs w6FiYmkga8OpcmTDqXN0LiBBIGhpdGVsZXPDrXTDqXNoZXogdsOhbGFzem9samEgbWVnLCBtYWpk ICIKInbDoWxhc3N6YSBheiBPSyBnb21ib3QuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjQ4Mgptc2dp ZCAiIgoiVG8gYXV0aGVudGljYXRlIHVzaW5nIGEgcXVlc3Rpb24sIHBpY2sgYSBxdWVzdGlvbiB3 aG9zZSBhbnN3ZXIgaXMga25vd24gb25seSAiCiJ0byB5b3UgYW5kIHlvdXIgYnVkZHkuICBFbnRl ciB0aGlzIHF1ZXN0aW9uIGFuZCB0aGlzIGFuc3dlciwgdGhlbiB3YWl0IGZvciAiCiJ5b3VyIGJ1 ZGR5IHRvIGVudGVyIHRoZSBhbnN3ZXIgdG9vLiAgSWYgdGhlIGFuc3dlcnMgZG9uJ3QgbWF0Y2gs IHRoZW4geW91ICIKIm1heSBiZSB0YWxraW5nIHRvIGFuIGltcG9zdGVyLiIKbXNnc3RyICIiCiJB IGvDqXJkw6lzc2VsIHTDtnJ0w6luxZEgaGl0ZWxlc8OtdMOpc2hleiB2w6FsYXNzem9uIGVneSBj c2FrIGEgcGFydG5lcmUgw6lzIMO2biDDoWx0YWwgIgoiaXNtZXJ0IHRpdGtvdC4gQWRqYSBtZWcg ZXp0IGVneSBrw6lyZMOpcyDDqXMgZWd5IHbDoWxhc3ogZm9ybcOhasOhYmFuLCBtYWpkIHbDoXJq YSAiCiJtZWcsIG3DrWcgYSBwYXJ0bmVyIGlzIMOtZ3kgdGVzei4gSGEgYSB2w6FsYXN6b2sgbmVt IGVneWV6bmVrIG1lZywgbGVoZXRzw6lnZXMsICIKImhvZ3kgZWd5IHN6w6lsaMOhbW9zc2FsIGNz ZXZlZy4iCgojOiAuLi9ndGstZGlhbG9nLmM6NTAwCiMsIGMtZm9ybWF0Cm1zZ2lkICJUaGlzIGlz IHRoZSBxdWVzdGlvbiBhc2tlZCBieSB5b3VyIGJ1ZGR5OiIKbXNnc3RyICJBIGvDtnZldGtlesWR IGvDqXJkw6lzdCB0ZXR0ZSBmZWwgYSBwYXJ0bmVyZToiCgojOiAuLi9ndGstZGlhbG9nLmM6NTAz CiMsIGMtZm9ybWF0Cm1zZ2lkICJFbnRlciBxdWVzdGlvbiBoZXJlOiIKbXNnc3RyICJBZGphIG1l ZyBhIGvDqXJkw6lzdDoiCgojOiAuLi9ndGstZGlhbG9nLmM6NTM0IC4uL2d0ay1kaWFsb2cuYzo2 MTgKbXNnaWQgIlRoaXMgYnVkZHkgaXMgYWxyZWFkeSBhdXRoZW50aWNhdGVkLiIKbXNnc3RyICJB IHBhcnRuZXIgbcOhciBoaXRlbGVzw610dmUgdmFuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo1NDYK IywgYy1mb3JtYXQKbXNnaWQgIkVudGVyIHNlY3JldCBhbnN3ZXIgaGVyZSAoY2FzZSBzZW5zaXRp dmUpOiIKbXNnc3RyICJBZGphIG1lZyBhIChraXMtIMOpcyBuYWd5YmV0xbHDqXJ6w6lrZW55KSB0 aXRrb3MgdsOhbGFzenQ6IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjU4Nwptc2dpZCAiIgoiVG8gYXV0 aGVudGljYXRlLCBwaWNrIGEgc2VjcmV0IGtub3duIG9ubHkgdG8geW91IGFuZCB5b3VyIGJ1ZGR5 LiAgRW50ZXIgdGhpcyAiCiJzZWNyZXQsIHRoZW4gd2FpdCBmb3IgeW91ciBidWRkeSB0byBlbnRl ciBpdCB0b28uICBJZiB0aGUgc2VjcmV0cyBkb24ndCAiCiJtYXRjaCwgdGhlbiB5b3UgbWF5IGJl IHRhbGtpbmcgdG8gYW4gaW1wb3N0ZXIuIgptc2dzdHIgIiIKIkEgaGl0ZWxlc8OtdMOpc2hleiB2 w6FsYXNzem9uIGVneSBjc2FrIGEgcGFydG5lcmUgw6lzIMO2biDDoWx0YWwgaXNtZXJ0IHRpdGtv dC4gIgoiQWRqYSBtZWcgZXp0LCBtYWpkIHbDoXJqYSBtZWcsIG3DrWcgYSBwYXJ0bmVyIGlzIMOt Z3kgdGVzei4gSGEgYSB0aXRrb2sgbmVtICIKImVneWV6bmVrIG1lZywgbGVoZXRzw6lnZXMsIGhv Z3kgZWd5IHN6w6lsaMOhbW9zc2FsIGNzZXZlZy4iCgojOiAuLi9ndGstZGlhbG9nLmM6NjAxCiMs IGMtZm9ybWF0Cm1zZ2lkICJFbnRlciBzZWNyZXQgaGVyZToiCm1zZ3N0ciAiQWRqYSBtZWcgYSB0 aXRrb3Q6IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjY1MiAuLi9ndGstZGlhbG9nLmM6MTQ3NiAuLi9n dGstZGlhbG9nLmM6MTUyOQptc2dpZCAiIgoiVG8gdmVyaWZ5IHRoZSBmaW5nZXJwcmludCwgY29u dGFjdCB5b3VyIGJ1ZGR5IHZpYSBzb21lIDxpPm90aGVyPC9pPiAiCiJhdXRoZW50aWNhdGVkIGNo YW5uZWwsIHN1Y2ggYXMgdGhlIHRlbGVwaG9uZSBvciBHUEctc2lnbmVkIGVtYWlsLiAgRWFjaCBv ZiAiCiJ5b3Ugc2hvdWxkIHRlbGwgeW91ciBmaW5nZXJwcmludCB0byB0aGUgb3RoZXIuIgptc2dz dHIgIiIKIkF6IHVqamxlbnlvbWF0IGVsbGVuxZFyesOpc8OpaGV6IHZlZ3llIGZlbCBhIGthcGNz b2xhdG90IGVneSA8aT5tw6FzaWs8L2k+ICIKImhpdGVsZXMgY3NhdG9ybsOhbiwgcMOpbGTDoXVs IHRlbGVmb25vbiB2YWd5IGRpZ2l0w6FsaXNhbiBhbMOhw61ydCBlbGVrdHJvbmlrdXMgIgoibGV2 w6lsYmVuLiBNaW5ka8OpdCBmw6lsIG1lZyBrZWxsIGFkamEgYSBzYWrDoXQgdWpqbGVueW9tYXTD oXQuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjY1NiAuLi9ndGstZGlhbG9nLmM6MTQ4MCAuLi9ndGst ZGlhbG9nLmM6MTUzMwptc2dpZCAiIgoiSWYgZXZlcnl0aGluZyBtYXRjaGVzIHVwLCB5b3Ugc2hv dWxkIGluZGljYXRlIGluIHRoZSBhYm92ZSBkaWFsb2cgdGhhdCB5b3UgIgoiPGI+aGF2ZTwvYj4g dmVyaWZpZWQgdGhlIGZpbmdlcnByaW50LiIKbXNnc3RyICIiCiJBbWVubnlpYmVuIG1pbmRlbiBl Z3llemlrLCBhIGZlbnRpIGFibGFrYmFuIHbDoWxhc3N6YSwgaG9neSA8aT5tZWdnecWResWRZMO2 dHQ8LyIKImk+IGF6IHVqamxlbnlvbWF0IGhpdGVsZXNzw6lnw6lyxZFsLiIKCiM6IC4uL2d0ay1k aWFsb2cuYzo2NjcgLi4vZ3RrLWRpYWxvZy5jOjE1MTgKbXNnaWQgIltub25lXSIKbXNnc3RyICJb bmluY3NdIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjY3NCAuLi9ndGstZGlhbG9nLmM6MTAzMSAuLi9n dGstZGlhbG9nLmM6MTUyNQojOiAuLi9ndGstZGlhbG9nLmM6MTU3NiAuLi9ndGstdWkuYzoxODEg Li4vb3RyLXBsdWdpbi5jOjExNgojOiAuLi9vdHItcGx1Z2luLmM6MjEzIC4uL3VpLmM6MTExCm1z Z2lkICJVbmtub3duIgptc2dzdHIgIklzbWVyZXRsZW4iCgojOiAuLi9ndGstZGlhbG9nLmM6Njc1 CiMsIGMtZm9ybWF0Cm1zZ2lkICIiCiJGaW5nZXJwcmludCBmb3IgeW91LCAlcyAoJXMpOlxuIgoi JXNcbiIKIlxuIgoiUHVycG9ydGVkIGZpbmdlcnByaW50IGZvciAlczpcbiIKIiVzXG4iCm1zZ3N0 ciAiIgoiQXogw7ZuICglcywgJXMpIHVqamxlbnlvbWF0YTpcbiIKIiVzXG4iCiJcbiIKIiVzIGZl bHTDqXRlbGV6ZXR0IHVqamxlbnlvbWF0YTpcbiIKIiVzXG4iCgojOiAuLi9ndGstZGlhbG9nLmM6 NzI3Cm1zZ2lkICJIb3cgd291bGQgeW91IGxpa2UgdG8gYXV0aGVudGljYXRlIHlvdXIgYnVkZHk/ Igptc2dzdHIgIk1pbHllbiBtw7Nkb24gc3plcmV0bsOpIHBhcnRuZXLDqXQgaGl0ZWxlc8OtdGVu aT8iCgojOiAuLi9ndGstZGlhbG9nLmM6NzM2Cm1zZ2lkICJRdWVzdGlvbiBhbmQgYW5zd2VyIgpt c2dzdHIgIkvDqXJkw6lzLXbDoWxhc3oiCgojOiAuLi9ndGstZGlhbG9nLmM6NzM5Cm1zZ2lkICJT aGFyZWQgc2VjcmV0Igptc2dzdHIgIkvDtnrDtnMgdGl0b2siCgojOiAuLi9ndGstZGlhbG9nLmM6 NzQyCm1zZ2lkICJNYW51YWwgZmluZ2VycHJpbnQgdmVyaWZpY2F0aW9uIgptc2dzdHIgIkvDqXpp IHVqamxlbnlvbWF0LWVsbGVuxZFyesOpcyIKCiM6IC4uL2d0ay1kaWFsb2cuYzo3ODUKbXNnaWQg Il9BdXRoZW50aWNhdGUiCm1zZ3N0ciAiX0hpdGVsZXPDrXTDqXMiCgojOiAuLi9ndGstZGlhbG9n LmM6ODE4Cm1zZ2lkICIiCiJBdXRoZW50aWNhdGluZyBhIGJ1ZGR5IGhlbHBzIGVuc3VyZSB0aGF0 IHRoZSBwZXJzb24geW91IGFyZSB0YWxraW5nIHRvIGlzICIKIndobyBoZSBvciBzaGUgY2xhaW1z IHRvIGJlLiIKbXNnc3RyICIiCiJQYXJ0bmVyw6luZWsgaGl0ZWxlc8OtdMOpc2Ugc2Vnw610aSBh bm5hayBheiBlbGxlbsWRcnrDqXPDqXQsIGhvZ3kgw7ZuIGF6emFsIGEgIgoic3plbcOpbGx5ZWwg Y3NldmVnLWUsIGFraW5layDFkSBtYWfDoXQgw6FsbMOtdGphLiIKCiMuIFRyYW5zbGF0b3JzOiB5 b3UgYXJlIGFza2VkIHRvIGF1dGhlbnRpY2F0ZSB5b3Vyc2VsZgojOiAuLi9ndGstZGlhbG9nLmM6 OTI3Cm1zZ2lkICJBdXRoZW50aWNhdGluZyB0byBCdWRkeSIKbXNnc3RyICJIaXRlbGVzw610w6lz IHBhcnRuZXJuZWsiCgojLiBUcmFuc2xhdG9yczogeW91IGFza2VkIHlvdXIgYnVkZHkgdG8gYXV0 aGVudGljYXRlIGhpbS9oZXJzZWxmCiM6IC4uL2d0ay1kaWFsb2cuYzo5MjkKbXNnaWQgIkF1dGhl bnRpY2F0aW5nIEJ1ZGR5Igptc2dzdHIgIlBhcnRuZXIgaGl0ZWxlc8OtdMOpc2UiCgojOiAuLi9n dGstZGlhbG9nLmM6OTU2CiMsIGMtZm9ybWF0Cm1zZ2lkICI8c3BhbiB3ZWlnaHQ9XCJib2xkXCIg c2l6ZT1cImxhcmdlclwiPkF1dGhlbnRpY2F0aW5nIHRvICVzPC9zcGFuPlxuIgptc2dzdHIgIjxz cGFuIHdlaWdodD1cImJvbGRcIiBzaXplPVwibGFyZ2VyXCI+SGl0ZWxlc8OtdMOpcyAlcyByw6lz esOpcmU8L3NwYW4+XG4iCgojOiAuLi9ndGstZGlhbG9nLmM6OTU3CiMsIGMtZm9ybWF0Cm1zZ2lk ICI8c3BhbiB3ZWlnaHQ9XCJib2xkXCIgc2l6ZT1cImxhcmdlclwiPkF1dGhlbnRpY2F0aW5nICVz PC9zcGFuPlxuIgptc2dzdHIgIjxzcGFuIHdlaWdodD1cImJvbGRcIiBzaXplPVwibGFyZ2VyXCI+ JXMgaGl0ZWxlc8OtdMOpc2U8L3NwYW4+XG4iCgojOiAuLi9ndGstZGlhbG9nLmM6OTg5Cm1zZ2lk ICJXYWl0aW5nIGZvciBidWRkeS4uLiIKbXNnc3RyICJWw6FyYWtvesOhcyBhIHBhcnRuZXJyZeKA piIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMDIyCm1zZ2lkICJHZW5lcmF0aW5nIHByaXZhdGUga2V5 Igptc2dzdHIgIlN6ZW3DqWx5ZXMga3VsY3MgbMOpdHJlaG96w6FzYSIKCiM6IC4uL2d0ay1kaWFs b2cuYzoxMDIzCm1zZ2lkICJQbGVhc2Ugd2FpdCIKbXNnc3RyICJLaXMgdMO8cmVsbWV0IgoKIy4g Q3JlYXRlIHRoZSBQbGVhc2UgV2FpdC4uLiBkaWFsb2cKIzogLi4vZ3RrLWRpYWxvZy5jOjEwMzQK IywgYy1mb3JtYXQKbXNnaWQgIkdlbmVyYXRpbmcgcHJpdmF0ZSBrZXkgZm9yICVzICglcykuLi4i Cm1zZ3N0ciAiU3plbcOpbHllcyBrdWxjcyBsw6l0cmVob3rDoXNhIGEga8O2dmV0a2V6xZFow7Z6 OiAlcyAoJXMp4oCmIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEwNzkKIywgYy1mb3JtYXQKbXNnaWQg IiVzIERvbmUuIgptc2dzdHIgIiVzIGVsa8Opc3rDvGx0LiIKCiM6IC4uL2d0ay1kaWFsb2cuYzox MTQxCiMsIGMtZm9ybWF0Cm1zZ2lkICIiCiIlcyBpcyBjb250YWN0aW5nIHlvdSBmcm9tIGFuIHVu cmVjb2duaXplZCBjb21wdXRlci4gIFlvdSBzaG91bGQgPGEgaHJlZj1cIiVzJSIKInNcIj5hdXRo ZW50aWNhdGU8L2E+IHRoaXMgYnVkZHkuIgptc2dzdHIgIiIKIiVzIGVneSBpc21lcmV0bGVuIHN6 w6Ftw610w7Nnw6lwcsWRbCBrYXBjc29sw7NkaWsuIDxhIGhyZWY9XCIlcyVzXCI+SGl0ZWxlc8Ot dHNlPC8iCiJhPiBwYXJ0bmVyw6l0LiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMTQ1CiMsIGMtZm9y bWF0Cm1zZ2lkICIiCiIlcyBoYXMgbm90IGJlZW4gYXV0aGVudGljYXRlZCB5ZXQuICBZb3Ugc2hv dWxkIDxhIGhyZWY9XCIlcyVzIgoiXCI+YXV0aGVudGljYXRlPC9hPiB0aGlzIGJ1ZGR5LiIKbXNn c3RyICIlcyBtw6lnIG5pbmNzIGhpdGVsZXPDrXR2ZS4gPGEgaHJlZj1cIiVzJXNcIj5IaXRlbGVz w610c2U8L2E+IHBhcnRuZXLDqXQuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyMDggLi4vZ3RrLWRp YWxvZy5jOjEyMzkgLi4vZ3RrLWRpYWxvZy5jOjIwMjkKIzogLi4vZ3RrLWRpYWxvZy5jOjIzMDQg Li4vZ3RrLXVpLmM6ODIKbXNnaWQgIkZpbmlzaGVkIgptc2dzdHIgIkvDqXN6IgoKIzogLi4vZ3Rr LWRpYWxvZy5jOjEyMDkgLi4vZ3RrLWRpYWxvZy5jOjEyNDAgLi4vZ3RrLWRpYWxvZy5jOjIwMjYK IzogLi4vZ3RrLWRpYWxvZy5jOjIzMDEgLi4vZ3RrLXVpLmM6ODEKbXNnaWQgIlByaXZhdGUiCm1z Z3N0ciAiQml6YWxtYXMiCgojOiAuLi9ndGstZGlhbG9nLmM6MTIxMCAuLi9ndGstZGlhbG9nLmM6 MTI0MSAuLi9ndGstZGlhbG9nLmM6MjAyMwojOiAuLi9ndGstZGlhbG9nLmM6MjI5OCAuLi9ndGst dWkuYzo4MAptc2dpZCAiVW52ZXJpZmllZCIKbXNnc3RyICJFbGxlbsWRcml6ZXRsZW4iCgojOiAu Li9ndGstZGlhbG9nLmM6MTIxMSAuLi9ndGstZGlhbG9nLmM6MTI0MiAuLi9ndGstdWkuYzo3OQpt c2dpZCAiTm90IHByaXZhdGUiCm1zZ3N0ciAiTmVtIGJpemFsbWFzIgoKIzogLi4vZ3RrLWRpYWxv Zy5jOjEyMTQKbXNnaWQgIlN0YXJ0IGEgcHJpdmF0ZSBjb252ZXJzYXRpb24iCm1zZ3N0ciAiQml6 YWxtYXMgYmVzesOpbGdldMOpcyBrZXpkZW3DqW55ZXrDqXNlIgoKIzogLi4vZ3RrLWRpYWxvZy5j OjEyMTUKbXNnaWQgIlJlZnJlc2ggdGhlIHByaXZhdGUgY29udmVyc2F0aW9uIgptc2dzdHIgIkJp emFsbWFzIGJlc3rDqWxnZXTDqXMgbWVnZXLFkXPDrXTDqXNlIgoKIzogLi4vZ3RrLWRpYWxvZy5j OjEyMjAgLi4vZ3RrLWRpYWxvZy5jOjE5NzggLi4vZ3RrLWRpYWxvZy5jOjIwNzMKbXNnaWQgIlN0 YXJ0IF9wcml2YXRlIGNvbnZlcnNhdGlvbiIKbXNnc3RyICJfQml6YWxtYXMgYmVzesOpbGdldMOp cyBrZXpkZW3DqW55ZXrDqXNlIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyMjEgLi4vZ3RrLWRpYWxv Zy5jOjE5NzkKbXNnaWQgIlJlZnJlc2ggX3ByaXZhdGUgY29udmVyc2F0aW9uIgptc2dzdHIgIl9C aXphbG1hcyBiZXN6w6lsZ2V0w6lzIG1lZ2VyxZFzw610w6lzZSIKCiM6IC4uL2d0ay1kaWFsb2cu YzoxMjQ1Cm1zZ2lkICJPVFIiCm1zZ3N0ciAiT1RSIgoKIy4gVHJhbnNsYXRvcnM6IHRoZSBmb2xs b3dpbmcgZm91ciBtZXNzYWdlcyBzaG91bGQgZ2l2ZSBhbHRlcm5hdGl2ZSBzZW50ZW5jZXMuCiMu IFRoZSB1c2VyIHNlbGVjdHMgdGhlIGZpcnN0IG9yIHNlY29uZCBtZXNzYWdlIGluIGEgY29tYm8g Ym94OwojLiB0aGUgdGhpcmQgbWVzc2FnZSwgYSBuZXcgbGluZSwgYSBmaW5nZXJwcmludCwgYSBu ZXcgbGluZSwgYW5kCiMuIHRoZSBmb3VydGggbWVzc2FnZSB3aWxsIGZvbGxvdyBpdC4KIzogLi4v Z3RrLWRpYWxvZy5jOjE0NDgKbXNnaWQgIkkgaGF2ZSBub3QiCm1zZ3N0ciAiTmVtIGd5xZF6xZFk dGVtIG1lZyIKCiMuIDJuZCBtZXNzYWdlCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDUwCm1zZ2lkICJJ IGhhdmUiCm1zZ3N0ciAiTWVnZ3nFkXrFkWR0ZW0iCgojLiAzcmQgbWVzc2FnZQojOiAuLi9ndGst ZGlhbG9nLmM6MTQ1Mwptc2dpZCAiIHZlcmlmaWVkIHRoYXQgdGhpcyBpcyBpbiBmYWN0IHRoZSBj b3JyZWN0Igptc2dzdHIgIiBhcnLDs2wsIGhvZ3kiCgojLiA0dGggbWVzc2FnZQojOiAuLi9ndGst ZGlhbG9nLmM6MTQ2MwojLCBjLWZvcm1hdAptc2dpZCAiZmluZ2VycHJpbnQgZm9yICVzLiIKbXNn c3RyICJ2YWzDs2JhbiAlcyB1ampsZW55b21hdGEuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE0ODIK bXNnaWQgIiIKIklmIHlvdXIgYnVkZHkgaGFzIG1vcmUgdGhhbiBvbmUgSU0gYWNjb3VudCwgb3Ig dXNlcyBtb3JlIHRoYW4gb25lIGNvbXB1dGVyLCAiCiJoZSBtYXkgaGF2ZSBtdWx0aXBsZSBmaW5n ZXJwcmludHMuIgptc2dzdHIgIiIKIkFtZW5ueWliZW4gcGFydG5lcmUgZWd5bsOpbCB0w7ZiYiBh em9ubmFsaSDDvHplbmV0a8O8bGTFkSBmZWxoYXN6bsOhbMOzdCB2YWd5ICIKInN6w6Ftw610w7Nn w6lwZXQgaGFzem7DoWwsIHTDtmJiIHVqamxlbnlvbWF0YSBpcyBsZWhldC4iCgojOiAuLi9ndGst ZGlhbG9nLmM6MTQ4NAptc2dpZCAiIgoiSG93ZXZlciwgdGhlIG9ubHkgd2F5IGFuIGltcG9zdGVy IGNvdWxkIGR1cGxpY2F0ZSBvbmUgb2YgeW91ciBidWRkeSdzICIKImZpbmdlcnByaW50cyBpcyBi eSBzdGVhbGluZyBpbmZvcm1hdGlvbiBmcm9tIGhlci9oaXMgY29tcHV0ZXIuIgptc2dzdHIgIiIK IkF6b25iYW4gYSBzesOpbGjDoW1vcyBlZ3lldGxlbiBtw7NkamEgYXogdWpqbGVueW9tYXQgaGFt aXPDrXTDoXPDoXJhIGF6LCBob2d5ICIKInBhcnRuZXLDqW5layBzesOhbcOtdMOzZ8OpcMOpcsWR bCBhZGF0b3QgbG9wLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDg4Cm1zZ2lkICJDbGljayBoZXJl IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGZpbmdlcnByaW50cy4iCm1zZ3N0ciAiS2F0dGlu dHNvbiBpZGUgdG92w6FiYmkgaW5mb3Jtw6FjacOzw6lydCBheiB1ampsZW55b21hdG9rcsOzbC4i CgojOiAuLi9ndGstZGlhbG9nLmM6MTQ5MQptc2dpZCAiIgoiQSA8Yj5maW5nZXJwcmludDwvYj4g aXMgYSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IHlvdSBzaG91bGQgdXNlIHRvICIKImF1dGhlbnRp Y2F0ZSB5b3VyIGJ1ZGR5LiIKbXNnc3RyICIiCiJBeiA8Yj51ampsZW55b21hdDwvYj4gZWd5IG9s eWFuIGVneWVkaSBhem9ub3PDrXTDsywgbWVseWV0IHBhcnRuZXLDqW5layAiCiJoaXRlbGVzw610 w6lzw6lyZSBoYXN6bsOhbGhhdC4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTUxNAojLCBjLWZvcm1h dAptc2dpZCAiVmVyaWZ5IGZpbmdlcnByaW50IGZvciAlcyIKbXNnc3RyICIlcyB1ampsZW55b21h dMOhbmFrIGVsbGVuxZFyesOpc2UiCgojOiAuLi9ndGstZGlhbG9nLmM6MTUyNgojLCBjLWZvcm1h dAptc2dpZCAiIgoiPHNtYWxsPjxpPiVzICVzXG4iCiJcbiIKIjwvaT48L3NtYWxsPkZpbmdlcnBy aW50IGZvciB5b3UsICVzICglcyk6XG4iCiIlc1xuIgoiXG4iCiJQdXJwb3J0ZWQgZmluZ2VycHJp bnQgZm9yICVzOlxuIgoiJXNcbiIKbXNnc3RyICIiCiI8c21hbGw+PGk+JXMgJXNcbiIKIlxuIgoi PC9pPjwvc21hbGw+QXogw7ZuICglcywgJXMpIHVqamxlbnlvbWF0YTpcbiIKIiVzXG4iCiJcbiIK IiVzIGZlbHTDqXRlbGV6ZXR0IHVqamxlbnlvbWF0YTpcbiIKIiVzXG4iCgojOiAuLi9ndGstZGlh bG9nLmM6MTUzOSAuLi9ndGstdWkuYzo3ODIKbXNnaWQgIlZlcmlmeSBmaW5nZXJwcmludCIKbXNn c3RyICJVampsZW55b21hdCBlbGxlbsWRcnrDqXNlIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE1NjYK IywgYy1mb3JtYXQKbXNnaWQgIkF1dGhlbnRpY2F0aW9uIGZyb20gJXMiCm1zZ3N0ciAiJXMgaGl0 ZWxlc8OtdMOpc2UiCgojOiAuLi9ndGstZGlhbG9nLmM6MTU2OQojLCBjLWZvcm1hdAptc2dpZCAi QXV0aGVudGljYXRlICVzIgptc2dzdHIgIiVzIGhpdGVsZXPDrXTDqXNlIgoKIzogLi4vZ3RrLWRp YWxvZy5jOjE1NzkKbXNnaWQgIkF1dGhlbnRpY2F0ZSBCdWRkeSIKbXNnc3RyICJQYXJ0bmVyIGhp dGVsZXPDrXTDqXNlIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE2MTAKbXNnaWQgIkFuIGVycm9yIG9j Y3VycmVkIGR1cmluZyBhdXRoZW50aWNhdGlvbi4iCm1zZ3N0ciAiSGliYSBsw6lwZXR0IGZlbCBh IGhpdGVsZXPDrXTDqXMgc29yw6FuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNjI1Cm1zZ2lkICJB dXRoZW50aWNhdGlvbiBzdWNjZXNzZnVsLiIKbXNnc3RyICJBIGhpdGVsZXPDrXTDqXMgc2lrZXJl cy4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTYyOAptc2dpZCAiIgoiWW91ciBidWRkeSBoYXMgc3Vj Y2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZWQgeW91LiAgWW91IG1heSB3YW50IHRvIGF1dGhlbnRpY2F0 ZSAiCiJ5b3VyIGJ1ZGR5IGFzIHdlbGwgYnkgYXNraW5nIHlvdXIgb3duIHF1ZXN0aW9uLiIKbXNn c3RyICIiCiJQYXJ0bmVyZSBzaWtlcmVzZW4gaGl0ZWxlc8OtdGV0dGUgw7ZudC4gRXogbmVtIGpl bGVudGkgYXp0LCBob2d5IMO2biBpcyBiaXp0b3MgIgoibGVoZXQgcGFydG5lcmUga2lsw6l0w6li ZW4sIGV6w6lydCB0ZWd5ZW4gZmVsIMO2biBpcyBlZ3kga8OpcmTDqXN0LiIKCiM6IC4uL2d0ay1k aWFsb2cuYzoxNjM0Cm1zZ2lkICJBdXRoZW50aWNhdGlvbiBmYWlsZWQuIgptc2dzdHIgIkEgaGl0 ZWxlc8OtdMOpcyBtZWdoacO6c3VsdC4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTY2MgojLCBjLWZv cm1hdAptc2dpZCAiUHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcyBzdGFydGVkLiVzIgptc2dz dHIgIkJpemFsbWFzIGJlc3rDqWxnZXTDqXMga2V6ZMWRZMO2dHQgJXMgcGFydG5lcnJlbC4lcyIK CiM6IC4uL2d0ay1kaWFsb2cuYzoxNjY2CiMsIGMtZm9ybWF0Cm1zZ2lkICI8YSBocmVmPVwiJXMl c1wiPlVudmVyaWZpZWQ8L2E+IGNvbnZlcnNhdGlvbiB3aXRoICUlcyBzdGFydGVkLiUlcyIKbXNn c3RyICIiCiI8YSBocmVmPVwiJXMlc1wiPkVsbGVuxZFyaXpldGxlbjwvYT4gYmVzesOpbGdldMOp cyBrZXpkxZFkw7Z0dCAlJXMgcGFydG5lcnJlbC4lJXMiCgojLiBUaGlzIGxhc3QgY2FzZSBzaG91 bGQgbmV2ZXIgaGFwcGVuLCBzaW5jZSB3ZSBrbm93CiMuICogd2UncmUgaW4gRU5DUllQVEVELgoj OiAuLi9ndGstZGlhbG9nLmM6MTY3NAojLCBjLWZvcm1hdAptc2dpZCAiTm90IHByaXZhdGUgY29u dmVyc2F0aW9uIHdpdGggJXMgc3RhcnRlZC4lcyIKbXNnc3RyICJOZW0gYml6YWxtYXMgYmVzesOp bGdldMOpcyBrZXpkxZFkw7Z0dCAlcyBwYXJ0bmVycmVsLiVzIgoKIzogLi4vZ3RrLWRpYWxvZy5j OjE2ODAgLi4vZ3RrLWRpYWxvZy5jOjE3ODQKbXNnaWQgIiAgV2FybmluZzogdXNpbmcgb2xkIHBy b3RvY29sIHZlcnNpb24gMS4iCm1zZ3N0ciAiICBGaWd5ZWxtZXp0ZXTDqXM6IGVsYXZ1bHQgcHJv dG9rb2xsIGhhc3puw6FsYXRhOiAxLWVzIHZlcnppw7MuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE3 MDAKIywgYy1mb3JtYXQKbXNnaWQgIlByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMgbG9zdC4i Cm1zZ3N0ciAiTWVnc3rFsW50IGEgYml6YWxtYXMgYmVzesOpbGdldMOpcyAlcyBwYXJ0bmVycmVs LiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNzM3CiMsIGMtZm9ybWF0Cm1zZ2lkICIiCiIlcyBoYXMg ZW5kZWQgaGlzL2hlciBwcml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoIHlvdTsgeW91IHNob3VsZCBk byB0aGUgc2FtZS4iCm1zZ3N0ciAiJXMgYmVmZWplenRlIGEgYml6YWxtYXMgYmVzesOpbGdldMOp c3QuIFRlZ3llbiDDtm4gaXMgw61neS4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTc2MwojLCBjLWZv cm1hdAptc2dpZCAiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgcHJpdmF0ZSBjb252ZXJzYXRp b24gd2l0aCAlcy4lcyIKbXNnc3RyICJBIGJpemFsbWFzIGJlc3rDqWxnZXTDqXMgJXMgcGFydG5l cnJlbCBtZWdlcsWRc8OtdMOpc3JlIGtlcsO8bHQuJXMiCgojOiAuLi9ndGstZGlhbG9nLmM6MTc2 OAojLCBjLWZvcm1hdAptc2dpZCAiIgoiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgPGEgaHJl Zj1cIiVzJXNcIj51bnZlcmlmaWVkPC9hPiBjb252ZXJzYXRpb24gd2l0aCAiCiIlJXMuJSVzIgpt c2dzdHIgIiIKIkF6IDxhIGhyZWY9XCIlcyVzXCI+ZWxsZW7FkXJpemV0bGVuPC9hPiBiZXN6w6ls Z2V0w6lzICUlcyBwYXJ0bmVycmVsICIKIm1lZ2VyxZFzw610w6lzcmUga2Vyw7xsdC4lJXMiCgoj LiBUaGlzIGxhc3QgY2FzZSBzaG91bGQgbmV2ZXIgaGFwcGVuLCBzaW5jZSB3ZSBrbm93CiMuICog d2UncmUgaW4gRU5DUllQVEVELgojOiAuLi9ndGstZGlhbG9nLmM6MTc3NwojLCBjLWZvcm1hdApt c2dpZCAiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgbm90IHByaXZhdGUgY29udmVyc2F0aW9u IHdpdGggJXMuJXMiCm1zZ3N0ciAiQSBuZW0gYml6YWxtYXMgYmVzesOpbGdldMOpcyAlcyBwYXJ0 bmVycmVsIG1lZ2VyxZFzw610w6lzcmUga2Vyw7xsdC4lcyIKCiM6IC4uL2d0ay1kaWFsb2cuYzox ODA5CiMsIGMtZm9ybWF0Cm1zZ2lkICJBdHRlbXB0aW5nIHRvIHJlZnJlc2ggdGhlIHByaXZhdGUg Y29udmVyc2F0aW9uIHdpdGggJXMuLi4iCm1zZ3N0ciAiJXMgcGFydG5lcnJlbCBmb2x5w7MgYml6 YWxtYXMgYmVzesOpbGdldMOpcyBtZWdlcsWRc8OtdMOpc2XigKYiCgojOiAuLi9ndGstZGlhbG9n LmM6MTgxMQojLCBjLWZvcm1hdAptc2dpZCAiQXR0ZW1wdGluZyB0byBzdGFydCBhIHByaXZhdGUg Y29udmVyc2F0aW9uIHdpdGggJXMuLi4iCm1zZ3N0ciAiQml6YWxtYXMgYmVzesOpbGdldMOpcyBr ZXpkZW3DqW55ZXrDqXNlICVzIHBhcnRuZXJyZWzigKYiCgojOiAuLi9ndGstZGlhbG9nLmM6MjAy MCAuLi9ndGstZGlhbG9nLmM6MjI5NQptc2dpZCAiTm90IFByaXZhdGUiCm1zZ3N0ciAiTmVtIGJp emFsbWFzIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjIwNzQgLi4vZ3RrLWRpYWxvZy5jOjI0ODEKbXNn aWQgIl9FbmQgcHJpdmF0ZSBjb252ZXJzYXRpb24iCm1zZ3N0ciAiQml6YWxtYXMgYmVzesOpbGdl dMOpcyBfYmVmZWplesOpc2UiCgojLgojLiAqIERvbid0IHNob3cgdGhlIFZlcmlmeSBmaW5nZXJw cmludCBtZW51IG9wdGlvbiBhbnkgbW9yZS4gIFlvdSBjYW4KIy4gKiBzdGlsbCBnZXQgdG8gdGhl IGRpYWxvZyB0aHJvdWdoIEF1dGhlbnRpY2F0ZSBjb25uZWN0aW9uIC0+CiMuICogQWR2YW5jZWQu Li4KIy4gKgojLiBtZW51dmVyZiA9IGd0a19tZW51X2l0ZW1fbmV3X3dpdGhfbW5lbW9uaWMoXygi X1ZlcmlmeSBmaW5nZXJwcmludCIpKTsKIy4gZ3RrX21lbnVfc2hlbGxfYXBwZW5kKEdUS19NRU5V X1NIRUxMKG1lbnUpLCBtZW51dmVyZik7CiMuIGd0a193aWRnZXRfc2hvdyhtZW51dmVyZik7CiMu CiM6IC4uL2d0ay1kaWFsb2cuYzoyMDc1IC4uL2d0ay1kaWFsb2cuYzoyNDk5Cm1zZ2lkICJfQXV0 aGVudGljYXRlIGJ1ZGR5Igptc2dzdHIgIlBhcnRuZXIgX2hpdGVsZXPDrXTDqXNlIgoKIzogLi4v Z3RrLWRpYWxvZy5jOjIyOTEKIywgYy1mb3JtYXQKbXNnaWQgIiIKIlRoZSBwcml2YWN5IHN0YXR1 cyBvZiB0aGUgY3VycmVudCBjb252ZXJzYXRpb24gaXMgbm93OiA8YSBocmVmPVwiJXMlc1wiPiVz PC8iCiJhPiIKbXNnc3RyICJBIGJlc3rDqWxnZXTDqXMgYml6dG9uc8OhZ29zc8OhZ2EgamVsZW5s ZWcgPGEgaHJlZj1cIiVzJXNcIj4lczwvYT4iCgojOiAuLi9ndGstZGlhbG9nLmM6MjQ1NAptc2dp ZCAiT1RSOiIKbXNnc3RyICJPVFI6IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjI0NzQKbXNnaWQgIk9U UiBNZXNzYWdpbmciCm1zZ3N0ciAiT1RSIMO8emVuZXRrw7xsZMOpcyIKCiM6IC4uL2d0ay11aS5j OjEwMgojLCBjLWZvcm1hdAptc2dpZCAiRmluZ2VycHJpbnQ6ICUuODBzIgptc2dzdHIgIlVqamxl bnlvbWF0OiAlLjgwcyIKCiM6IC4uL2d0ay11aS5jOjEwNgojLCBjLWZvcm1hdAptc2dpZCAiTm8g a2V5IHByZXNlbnQiCm1zZ3N0ciAiTmVtIMOpcmhldMWRIGVsIGt1bGNzIgoKIzogLi4vZ3RrLXVp LmM6MTExCiMsIGMtZm9ybWF0Cm1zZ2lkICJObyBhY2NvdW50IGF2YWlsYWJsZSIKbXNnc3RyICJO ZW0gw6lyaGV0xZEgZWwgZmVsaGFzem7DoWzDsyIKCiM6IC4uL2d0ay11aS5jOjE3MQptc2dpZCAi VW51c2VkIgptc2dzdHIgIkhhc3puw6FsYXRvbiBrw612w7xsIgoKIzogLi4vZ3RrLXVpLmM6MTc3 Cm1zZ2lkICJZZXMiCm1zZ3N0ciAiSWdlbiIKCiM6IC4uL2d0ay11aS5jOjE3Nwptc2dpZCAiTm8i Cm1zZ3N0ciAiTmVtIgoKIzogLi4vZ3RrLXVpLmM6NDAzCm1zZ2lkICJFbmFibGUgcHJpdmF0ZSBt ZXNzYWdpbmciCm1zZ3N0ciAiQml6YWxtYXMgYmVzesOpbGdldMOpcyBlbmdlZMOpbHllesOpc2Ui CgojOiAuLi9ndGstdWkuYzo0MDUKbXNnaWQgIkF1dG9tYXRpY2FsbHkgaW5pdGlhdGUgcHJpdmF0 ZSBtZXNzYWdpbmciCm1zZ3N0ciAiQml6YWxtYXMgYmVzesOpbGdldMOpcyBhdXRvbWF0aWt1cyBr ZXpkZW3DqW55ZXrDqXNlIgoKIzogLi4vZ3RrLXVpLmM6NDA3Cm1zZ2lkICJSZXF1aXJlIHByaXZh dGUgbWVzc2FnaW5nIgptc2dzdHIgIkJpemFsbWFzIGJlc3rDqWxnZXTDqXMgbWVna8O2dmV0ZWzD qXNlIgoKIzogLi4vZ3RrLXVpLmM6NDEwCm1zZ2lkICJEb24ndCBsb2cgT1RSIGNvbnZlcnNhdGlv bnMiCm1zZ3N0ciAiT1RSIGJlc3rDqWxnZXTDqXNlayBuZSBrZXLDvGxqZW5layBuYXBsw7N6w6Fz cmEiCgojOiAuLi9ndGstdWkuYzo0NTQKbXNnaWQgIlNob3cgT1RSIGJ1dHRvbiIKbXNnc3RyICJP VFIgZ29tYiBtZWdqZWxlbsOtdMOpc2UiCgojOiAuLi9ndGstdWkuYzo0NTcKbXNnaWQgIlNob3cg T1RSIGJ1dHRvbiBpbiB0b29sYmFyIgptc2dzdHIgIk9UUiBnb21iIG1lZ2plbGVuw610w6lzZSBh eiBlc3prw7Z6dMOhcm9uIgoKIzogLi4vZ3RrLXVpLmM6NjAxCm1zZ2lkICJNeSBwcml2YXRlIGtl eXMiCm1zZ3N0ciAiU2Fqw6F0IHN6ZW3DqWx5ZXMga3VsY3NvayIKCiM6IC4uL2d0ay11aS5jOjYx MAptc2dpZCAiS2V5IGZvciBhY2NvdW50OiIKbXNnc3RyICJLdWxjcyBhIGvDtnZldGtlesWRIGZl bGhhc3puw6Fsw7Nob3o6IgoKIzogLi4vZ3RrLXVpLmM6NjM1Cm1zZ2lkICJHZW5lcmF0ZSIKbXNn c3RyICJHZW5lcsOhbMOhcyIKCiM6IC4uL2d0ay11aS5jOjY3Ngptc2dpZCAiRGVmYXVsdCBPVFIg U2V0dGluZ3MiCm1zZ3N0ciAiQWxhcMOpcnRlbG1lemV0dCBPVFIgYmXDoWxsw610w6Fzb2siCgoj OiAuLi9ndGstdWkuYzo3MDMKbXNnaWQgIk9UUiBVSSBPcHRpb25zIgptc2dzdHIgIk9UUiBtZWdq ZWxlbsOpc2kgYmXDoWxsw610w6Fzb2siCgojOiAuLi9ndGstdWkuYzo3MjYKbXNnaWQgIlNjcmVl bm5hbWUiCm1zZ3N0ciAiS2lqZWx6ZXR0IG7DqXYiCgojOiAuLi9ndGstdWkuYzo3MjcKbXNnaWQg IlN0YXR1cyIKbXNnc3RyICLDgWxsYXBvdCIKCiM6IC4uL2d0ay11aS5jOjcyOAptc2dpZCAiVmVy aWZpZWQiCm1zZ3N0ciAiRWxsZW7FkXJ6w7Z0dCIKCiM6IC4uL2d0ay11aS5jOjcyOQptc2dpZCAi RmluZ2VycHJpbnQiCm1zZ3N0ciAiVWpqbGVueW9tYXQiCgojOiAuLi9ndGstdWkuYzo3MzAKbXNn aWQgIkFjY291bnQiCm1zZ3N0ciAiRmVsaGFzem7DoWzDsyIKCiM6IC4uL2d0ay11aS5jOjc2Ngpt c2dpZCAiU3RhcnQgcHJpdmF0ZSBjb25uZWN0aW9uIgptc2dzdHIgIkJpemFsbWFzIGthcGNzb2xh dCBrZXpkZW3DqW55ZXrDqXNlIgoKIzogLi4vZ3RrLXVpLmM6Nzc0Cm1zZ2lkICJFbmQgcHJpdmF0 ZSBjb25uZWN0aW9uIgptc2dzdHIgIkJpemFsbWFzIGthcGNzb2xhdCBiZWZlamV6w6lzZSIKCiM6 IC4uL2d0ay11aS5jOjc5MAptc2dpZCAiRm9yZ2V0IGZpbmdlcnByaW50Igptc2dzdHIgIlVqamxl bnlvbWF0IHTDtnJsw6lzZSIKCiM6IC4uL2d0ay11aS5jOjg0MQptc2dpZCAiQ29uZmlnIgptc2dz dHIgIkJlw6FsbMOtdMOhcyIKCiM6IC4uL2d0ay11aS5jOjg0Mwptc2dpZCAiS25vd24gZmluZ2Vy cHJpbnRzIgptc2dzdHIgIklzbWVydCB1ampsZW55b21hdG9rIgoKIzogLi4vZ3RrLXVpLmM6OTQx IC4uL290ci1wbHVnaW4uYzo2MDYKbXNnaWQgIk9UUiBTZXR0aW5ncyIKbXNnc3RyICJPVFItYmXD oWxsw610w6Fzb2siCgojLiBTZXQgdGhlIHRpdGxlCiM6IC4uL2d0ay11aS5jOjk1OQojLCBjLWZv cm1hdAptc2dpZCAiT1RSIFNldHRpbmdzIGZvciAlcyIKbXNnc3RyICIlcyBPVFItYmXDoWxsw610 w6FzYWkiCgojLiBNYWtlIHRoZSBjYXNjYWRlZCBjaGVja2JveGVzCiM6IC4uL2d0ay11aS5jOjk3 Ngptc2dpZCAiVXNlIGRlZmF1bHQgT1RSIHNldHRpbmdzIGZvciB0aGlzIGJ1ZGR5Igptc2dzdHIg IkFsYXDDqXJ0ZWxtZXpldHQgT1RSLWJlw6FsbMOtdMOhc29rIGhhc3puw6FsYXRhIGV6ZW4gcGFy dG5lcmhleiIKCiM6IC4uL290ci1wbHVnaW4uYzoxMTQKIywgYy1mb3JtYXQKbXNnaWQgIllvdSBh cmUgbm90IGN1cnJlbnRseSBjb25uZWN0ZWQgdG8gYWNjb3VudCAlcyAoJXMpLiIKbXNnc3RyICJK ZWxlbmxlZyBuaW5jc2VuIGthcGNzb2zDs2R2YSAlcyAoJXMpIGZlbGhhc3puw6Fsw7MuIgoKIzog Li4vb3RyLXBsdWdpbi5jOjExOAptc2dpZCAiTm90IGNvbm5lY3RlZCIKbXNnc3RyICJLYXBjc29s YXQgbsOpbGvDvGwiCgojOiAuLi9vdHItcGx1Z2luLmM6MTYyCiMsIGMtZm9ybWF0Cm1zZ2lkICJP dXQgb2YgbWVtb3J5IGJ1aWxkaW5nIGZpbGVuYW1lcyFcbiIKbXNnc3RyICLDgWxsb23DoW55bmV2 ZWsgw7Zzc3plw6FsbMOtdMOhc2Ega8O2emJlbiBlbGZvZ3lvdHQgYSBtZW3Ds3JpYS5cbiIKCiM6 IC4uL290ci1wbHVnaW4uYzoxNjgKIywgYy1mb3JtYXQKbXNnaWQgIkNvdWxkIG5vdCB3cml0ZSBw cml2YXRlIGtleSBmaWxlXG4iCm1zZ3N0ciAiTmVtIMOtcmhhdMOzIGEgc3plbcOpbHllc2t1bGNz LcOhbGxvbcOhbnkuXG4iCgojOiAuLi9vdHItcGx1Z2luLmM6MjExCiMsIGMtZm9ybWF0Cm1zZ2lk ICJVbmtub3duIGFjY291bnQgJXMgKCVzKS4iCm1zZ3N0ciAiSXNtZXJldGxlbiBmZWxoYXN6bsOh bMOzOiAlcyAoJXMpLiIKCiM6IC4uL290ci1wbHVnaW4uYzoyMTUKbXNnaWQgIlVua25vd24gYWNj b3VudCIKbXNnc3RyICJJc21lcmV0bGVuIGZlbGhhc3puw6Fsw7MiCgojOiAuLi9vdHItcGx1Z2lu LmM6OTgzCm1zZ2lkICJPZmYtdGhlLVJlY29yZCBNZXNzYWdpbmciCm1zZ3N0ciAiQml6YWxtYXMg w7x6ZW5ldGvDvGxkw6lzIgoKIzogLi4vb3RyLXBsdWdpbi5jOjk4NAptc2dpZCAiUHJvdmlkZXMg cHJpdmF0ZSBhbmQgc2VjdXJlIGNvbnZlcnNhdGlvbnMiCm1zZ3N0ciAiQml6YWxtYXMgw6lzIGJp enRvbnPDoWdvcyBiZXN6w6lsZ2V0w6lzZWtldCB0ZXN6IGxlaGV0xZF2w6kiCgojOiAuLi9vdHIt cGx1Z2luLmM6OTg1Cm1zZ2lkICIiCiJQcmVzZXJ2ZXMgdGhlIHByaXZhY3kgb2YgSU0gY29tbXVu aWNhdGlvbnMgYnkgcHJvdmlkaW5nIGVuY3J5cHRpb24sICIKImF1dGhlbnRpY2F0aW9uLCBkZW5p YWJpbGl0eSwgYW5kIHBlcmZlY3QgZm9yd2FyZCBzZWNyZWN5LiIKbXNnc3RyICIiCiJCaXp0b3PD rXRqYSBheiBhem9ubmFsaSDDvHplbmV0ZWsgYWRhdGJpenRvbnPDoWfDoXQgdGl0a29zw610w6Fz LCBoaXRlbGVzw610w6lzLCAiCiJiaXpvbnnDrXRoYXRhdGxhbnPDoWcgw6lzIG1lZ2ZlbGVsxZEg dXTDs2xhZ29zIHRpdGtvc3PDoWcgbnnDump0w6Fzw6F2YWwuIgoKIzogLi4vdWkuYzoxMDkKIywg Yy1mb3JtYXQKbXNnaWQgIkFjY291bnQgJXMgKCVzKSBjb3VsZCBub3QgYmUgZm91bmQiCm1zZ3N0 ciAiJXMgKCVzKSBmZWxoYXN6bsOhbMOzIG5lbSB0YWzDoWxoYXTDsyIKCiM6IC4uL3VpLmM6MTEz Cm1zZ2lkICJBY2NvdW50IG5vdCBmb3VuZCIKbXNnc3RyICJBIGZlbGhhc3puw6Fsw7MgbmVtIHRh bMOhbGhhdMOzIgoKI34gbXNnaWQgIl9Nb3JlLi4uIgojfiBtc2dzdHIgIl9Ub3bDoWJi4oCmIgoK I34gbXNnaWQgIkFkdmFuY2VkLi4uIgojfiBtc2dzdHIgIkhhbGFkw7PigKYiCgojfiBtc2dpZCAi IgojfiAiSWYgeW91ciBidWRkeSB1c2VzIG11bHRpcGxlIElNIGFjY291bnRzIG9yIG11bHRpcGxl IGNvbXB1dGVycywgeW91IG1heSAiCiN+ICJoYXZlIHRvIGF1dGhlbnRpY2F0ZSBtdWx0aXBsZSB0 aW1lcy4gIEhvd2V2ZXIsIGFzIGxvbmcgYXMgdGhleSB1c2UgYW4gIgojfiAiYWNjb3VudCBhbmQg Y29tcHV0ZXIgdGhhdCB5b3UndmUgc2VlbiBiZWZvcmUsIHlvdSBkb24ndCBuZWVkIHRvICIKI34g ImF1dGhlbnRpY2F0ZSBlYWNoIGluZGl2aWR1YWwgY29udmVyc2F0aW9uLiIKI34gbXNnc3RyICIi CiN+ICJIYSBwYXJ0bmVyZSB0w7ZiYiBhem9ubmFsaSDDvHplbmV0a8O8bGTFkSBmZWxoYXN6bsOh bMOzdCB2YWd5IHN6w6Ftw610w7Nnw6lwZXQgIgojfiAiaGFzem7DoWwsIGxlaGV0c8OpZ2VzLCBo b2d5IHTDtmJiIGFsa2Fsb21tYWwgaXMgaGl0ZWxlc8OtdGVuaSBrZWxsLiBBem9uYmFuICIKI34g ImFtw61nIGF6b25vcyBzesOhbcOtdMOzZ8OpcGV0IMOpcyBmZWxoYXN6bsOhbMOzdCBoYXN6bsOh bCwgYSBoaXRlbGVzw610w6lzICIKI34gIm1lZ2lzbcOpdGzDqXNlIG5lbSBzesO8a3PDqWdlcy4i CgojfiBtc2dpZCAiQ2xpY2sgaGVyZSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBhdXRoZW50 aWNhdGlvbiBpbiBPVFIuIgojfiBtc2dzdHIgIiIKI34gIkthdHRpbnRzb24gaWRlIHRvdsOhYmJp IGluZm9ybcOhY2nDs8OpcnQgYXogT1RSIGhpdGVsZXPDrXTDqXNpIG3Ds2RzemVyw6lyxZFsLiIK CiN+IG1zZ2lkICJFbnRlciBhIHNlY3JldCBrbm93biBvbmx5IHRvICVzIGFuZCB5b3Vyc2VsZi5c biIKI34gbXNnc3RyICJBZGpvbiBtZWcgZWd5IHRpdGtvdCwgYW1lbHlldCBjc2FrIMO2biDDqXMg JXMgaXNtZXIuXG4iCg== ------=_Part_10933_23151869.1212948291654-- From ldm@gmx.at Sun Jun 8 23:17:41 2008 From: ldm@gmx.at (Markus Krainz) Date: Mon, 9 Jun 2008 00:17:41 +0200 Subject: [OTR-dev] OTR third-party miranda plugin Message-ID: <200806082218.m58MI4IH014533@paip.net> Did anyone actually read what I wrote? Because it doesn't seem so. ^^ From marti@juffo.org Mon Jun 9 01:05:07 2008 From: marti@juffo.org (Marti Raudsepp) Date: Mon, 9 Jun 2008 03:05:07 +0300 Subject: [OTR-dev] OTR third-party miranda plugin In-Reply-To: <200806082218.m58MI4IH014533@paip.net> References: <200806082218.m58MI4IH014533@paip.net> Message-ID: <54b33ccd0806081705p29301d8fq70efc3c1da74e0d2@mail.gmail.com> On Mon, Jun 9, 2008 at 1:17 AM, Markus Krainz wrote: > Did anyone actually read what I wrote? Because it doesn't seem so. ^^ I believe the Miranda OTR plug-in developer does not monitor these mailing lists, and as far as I can tell there is only one developer. Marti From orymate@gmail.com Wed Jun 11 00:13:20 2008 From: orymate@gmail.com (=?ISO-8859-2?Q?=D5ry_M=E1t=E9?=) Date: Wed, 11 Jun 2008 01:13:20 +0200 Subject: [OTR-dev] messages.c -- messages on gui without translation support Message-ID: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> Hi, I was testing my new gaim-otr translation, and found some interesting untranslated messages while chatting with Pidgin. I have grepped the gaim-otr source tree, but have not found the message. I checked out libotr, and all the untranslated messages were in messages.c -- as simple strings. What is the way of making these available for translation? Having some complicated wrapper on gaim-otr's side (I have no idea how could the messages get to the po template), or mark these for translation in messages.c. Would this cause any problems? (Could these messages ever be processed by computer?) -- Õry Máté (Mate Ory) From fnord@pentabarf.de Wed Jun 11 14:11:09 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Wed, 11 Jun 2008 15:11:09 +0200 Subject: [OTR-dev] python bindings for libotr: pyotr Message-ID: <1213189869.8384.6.camel@hegg> --=-Nv4KOJ6fctqhv0EXdnZm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, just wanted to let you know that I've created python bindings for libotr some time ago. I've called them pyotr, because I'm so extremely creative :) They're written using swig, you can find the source packages and stuff on the website [1] Suggestions, bug reports etc. can be sent either directly via mail or to the bug tracker [2]. I currently maintain a gajim branch =EF=BB=BF[3] which implements most OTR features using pyotr. [1] =EF=BB=BFhttp://pyotr.pentabarf.de/index.html [2] =EF=BB=BFhttps://bugs.launchpad.net/pyotr [3] https://code.launchpad.net/~afflux/gajim/otr Thanks, Kjell --=-Nv4KOJ6fctqhv0EXdnZm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIT87tNjvKGrx0tZgRAsPFAKCgL10piw1ryDtLsZn6beIgywkDDwCgiUZu ykHKlE4vGiqLE5AMwHfwTaY= =Kt6J -----END PGP SIGNATURE----- --=-Nv4KOJ6fctqhv0EXdnZm-- From ian@cypherpunks.ca Wed Jun 11 21:22:14 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 11 Jun 2008 16:22:14 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> Message-ID: <20080611202214.GI21852@thunk.cs.uwaterloo.ca> On Sun, Jun 08, 2008 at 08:04:51PM +0200, Åry Máté wrote: > Dear Ian, > > > Can you update your translations file to include the new text from > > the new version? See po/README for super-brief instructions, or > > email me if you're having trouble. > > I have updated the Hungarian translation of gaim-otr. I found some > messages, which ones were hard to translate to Hungarian. I've made > some comments for translators, and I have modified two messages, > because they couldn't be translated to Hungarian (which is an > agglutinating language unlike English, which is mainly isolating). > > The translation is made for the modified code. I have not tested it, > nor compiled. Thanks! I modified your patch a little bit so that only the actual text (and not the markup) was marked as the translatable string, and modified your hu.po to match. Other translators: can you send in updated translations based on what's checked in right now? Thanks, - Ian From ian@cypherpunks.ca Wed Jun 11 21:24:07 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 11 Jun 2008 16:24:07 -0400 Subject: [OTR-dev] messages.c -- messages on gui without translation support In-Reply-To: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> References: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> Message-ID: <20080611202407.GJ21852@thunk.cs.uwaterloo.ca> On Wed, Jun 11, 2008 at 01:13:20AM +0200, Åry Máté wrote: > Hi, > > I was testing my new gaim-otr translation, and found some interesting > untranslated messages while chatting with Pidgin. > > I have grepped the gaim-otr source tree, but have not found the > message. I checked out libotr, and all the untranslated messages were > in messages.c -- as simple strings. > > What is the way of making these available for translation? Having some > complicated wrapper on gaim-otr's side (I have no idea how could the > messages get to the po template), or mark these for translation in > messages.c. Would this cause any problems? (Could these messages ever > be processed by computer?) There are lots of problems with the hardcoded strings in message.c. Elsewhere on this list, you'll find the discussion of what we're planning to do about it (short answer: remove them from the library completely, and return error codes to the calling application, which will be responsible for them). So the problem will be gone in 4.0.0, but for 3.2.0 I'm afraid there's nothing that can be done. :-( - Ian From mail@code.mmsources.de Wed Jun 11 23:50:16 2008 From: mail@code.mmsources.de (Michael Meier) Date: Thu, 12 Jun 2008 00:50:16 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080611202214.GI21852@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> <20080611202214.GI21852@thunk.cs.uwaterloo.ca> Message-ID: <485056A8.7070906@code.mmsources.de> This is a multi-part message in MIME format. --------------010802090302000402080908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Thanks! I modified your patch a little bit so that only the actual text > (and not the markup) was marked as the translatable string, and modified > your hu.po to match. > > Other translators: can you send in updated translations based on what's > checked in right now? > Hello, latest revision of de.po attached Michael --------------010802090302000402080908 Content-Type: text/plain; name="de.po" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="de.po" IyBPZmYtdGhlLVJlY29yZCBNZXNzYWdpbmcgcGx1Z2luIGZvciBwaWRnaW4uCiMgQ29weXJp Z2h0IChDKSAyMDA0LTIwMDggIElhbiBHb2xkYmVyZywgUm9iIFNtaXRzLAojICAgICAgICAg ICAgICAgICAgICAgICAgICBDaHJpcyBBbGV4YW5kZXIsIE5pa2l0YSBCb3Jpc292CiMgVGhp cyBmaWxlIGlzIGRpc3RyaWJ1dGVkIHVuZGVyIHRoZSBzYW1lIGxpY2Vuc2UgYXMgdGhlIHBp ZGdpbi1vdHIgcGFja2FnZS4KIyBNaWNoYWVsIE1laWVyIDxtaWNoYWVsLm1laWVyQG1tc291 cmNlcy5kZT4sIDIwMDguCiMKbXNnaWQgIiIKbXNnc3RyICIiCiJQcm9qZWN0LUlkLVZlcnNp b246IHBpZGdpbi1vdHIgMy4yLjAtZGVcbiIKIlJlcG9ydC1Nc2dpZC1CdWdzLVRvOiBcbiIK IlBPVC1DcmVhdGlvbi1EYXRlOiAyMDA4LTA2LTEyIDAwOjM0KzAyMDBcbiIKIlBPLVJldmlz aW9uLURhdGU6IDIwMDgtMDUtMjggMDk6MTIrMDIwMFxuIgoiTGFzdC1UcmFuc2xhdG9yOiBN aWNoYWVsIE1laWVyIDxtaWNoYWVsLm1laWVyQG1tc291cmNlcy5kZT5cbiIKIkxhbmd1YWdl LVRlYW06IE1pY2hhZWwgTWVpZXIgPG1pY2hhZWwubWVpZXJAbW1zb3VyY2VzLmRlPlxuIgoi TUlNRS1WZXJzaW9uOiAxLjBcbiIKIkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD1VVEYtOFxuIgoiQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdFxuIgoKIzogLi4v Z3RrLWRpYWxvZy5jOjI5MSAuLi9ndGstZGlhbG9nLmM6MTE0NCAuLi9ndGstZGlhbG9nLmM6 MTE0OAojOiAuLi9ndGstZGlhbG9nLmM6MTMxMCAuLi9ndGstZGlhbG9nLmM6MTQ4OCAuLi9n dGstZGlhbG9nLmM6MTY2OQojOiAuLi9ndGstZGlhbG9nLmM6MTc3MiAuLi9ndGstZGlhbG9n LmM6MTg2MyAuLi9ndGstZGlhbG9nLmM6MjMwOQptc2dpZCAiP2xhbmc9ZW4iCm1zZ3N0ciAi P2xhbmc9ZGUiCgojOiAuLi9ndGstZGlhbG9nLmM6NDQwIC4uL2d0ay1kaWFsb2cuYzoyMDQz IC4uL2d0ay1kaWFsb2cuYzoyNTE3Cm1zZ2lkICJfV2hhdCdzIHRoaXM/Igptc2dzdHIgIl9X YXMgaXN0IGRhcz8iCgojOiAuLi9ndGstZGlhbG9nLmM6NDc1Cm1zZ2lkICIiCiJZb3VyIGJ1 ZGR5IGlzIGF0dGVtcHRpbmcgdG8gZGV0ZXJtaW5lIGlmIGhlIG9yIHNoZSBpcyByZWFsbHkg dGFsa2luZyB0byB5b3UsICIKIm9yIGlmIGl0J3Mgc29tZW9uZSBwcmV0ZW5kaW5nIHRvIGJl IHlvdS4gIFlvdXIgYnVkZHkgaGFzIGFza2VkIGEgcXVlc3Rpb24sICIKImluZGljYXRlZCBi ZWxvdy4gIFRvIGF1dGhlbnRpY2F0ZSB0byB5b3VyIGJ1ZGR5LCBlbnRlciB0aGUgYW5zd2Vy IGFuZCBjbGljayAiCiJPSy4iCm1zZ3N0ciAiIgoiSWhyIEJ1ZGR5IHZlcnN1Y2h0IGZlc3R6 dXN0ZWxsZW4sIG9iIGVyIHdpcmtsaWNoIG1pdCBJaG5lbiBzcHJpY2h0IG9kZXIgIgoiamVt YW5kZW0sIGRlciBzaWNoIGFscyBTaWUgYXVzZ2lidC4gRXIgaGF0IGRhenUgZGllIHVudGVu IGFuZ2VnZWJlbmUgRnJhZ2UgIgoiZ2VzdGVsbHQuIFVtIElocmVuIEJ1ZGR5IHp1IGF1dGhl bnRpZml6aWVyZW4sIGdlYmVuIFNpZSBkaWUgQW50d29ydCBlaW4gdW5kICIKImtsaWNrZW4g U2llIE9LLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo0ODIKbXNnaWQgIiIKIlRvIGF1dGhlbnRp Y2F0ZSB1c2luZyBhIHF1ZXN0aW9uLCBwaWNrIGEgcXVlc3Rpb24gd2hvc2UgYW5zd2VyIGlz IGtub3duIG9ubHkgIgoidG8geW91IGFuZCB5b3VyIGJ1ZGR5LiAgRW50ZXIgdGhpcyBxdWVz dGlvbiBhbmQgdGhpcyBhbnN3ZXIsIHRoZW4gd2FpdCBmb3IgIgoieW91ciBidWRkeSB0byBl bnRlciB0aGUgYW5zd2VyIHRvby4gIElmIHRoZSBhbnN3ZXJzIGRvbid0IG1hdGNoLCB0aGVu IHlvdSAiCiJtYXkgYmUgdGFsa2luZyB0byBhbiBpbXBvc3Rlci4iCm1zZ3N0ciAiIgoiV8Ok aGxlbiBTaWUgenVyIEF1dGhlbnRpZml6aWVydW5nIGVpbmUgRnJhZ2UgZWluLCBkZXJlbiBB bnR3b3J0IG51ciBJaG5lbiB1bmQgIgoiSWhyZW0gQnVkZHkgYmVrYW5udCBpc3QuIEdlYmVu IFNpZSBkaWUgRnJhZ2UgdW5kIEFudHdvcnQgZWluIHVuZCB3YXJ0ZW4gU2llICIKImRhbm4g ZGFyYXVmLCBkYXNzIElociBCdWRkeSBkaWVzZSBBbnR3b3J0IGViZW5mYWxscyBlaW5naWJ0 LiBTb2xsdGVuIGRpZSAiCiJBbnR3b3J0ZW4gbmljaHQgw7xiZXJlaW5zdGltbWVuLCBoYWJl biBTaWUgZXMgbcO2Z2xpY2hlcndlaXNlIG1pdCBlaW5lbSAiCiJIb2Noc3RhcGxlciB6dSB0 dW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjUwMAptc2dpZCAiVGhpcyBpcyB0aGUgcXVlc3Rp b24gYXNrZWQgYnkgeW91ciBidWRkeToiCm1zZ3N0ciAiRGllc2UgRnJhZ2Ugd3VyZGUgdm9u IElocmVtIEJ1ZGR5IGdlc3RlbGx0OiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo1MDMKbXNnaWQg IkVudGVyIHF1ZXN0aW9uIGhlcmU6Igptc2dzdHIgIkZyYWdlIGhpZXIgZWluZ2ViZW46IgoK IzogLi4vZ3RrLWRpYWxvZy5jOjUzNCAuLi9ndGstZGlhbG9nLmM6NjE4Cm1zZ2lkICJUaGlz IGJ1ZGR5IGlzIGFscmVhZHkgYXV0aGVudGljYXRlZC4iCm1zZ3N0ciAiRGllc2VyIEJ1ZGR5 IHd1cmRlIGJlcmVpdHMgYXV0aGVudGlmaXppZXJ0LiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo1 NDYKbXNnaWQgIkVudGVyIHNlY3JldCBhbnN3ZXIgaGVyZSAoY2FzZSBzZW5zaXRpdmUpOiIK bXNnc3RyICJHZWhlaW1lIEFudHdvcnQgaGllciBlaW5nZWJlbjogKEdyb8OfLS9LbGVpbnNj aHJlaWJ1bmcgcmVsZXZhbnQpIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjU4Nwptc2dpZCAiIgoi VG8gYXV0aGVudGljYXRlLCBwaWNrIGEgc2VjcmV0IGtub3duIG9ubHkgdG8geW91IGFuZCB5 b3VyIGJ1ZGR5LiAgRW50ZXIgdGhpcyAiCiJzZWNyZXQsIHRoZW4gd2FpdCBmb3IgeW91ciBi dWRkeSB0byBlbnRlciBpdCB0b28uICBJZiB0aGUgc2VjcmV0cyBkb24ndCAiCiJtYXRjaCwg dGhlbiB5b3UgbWF5IGJlIHRhbGtpbmcgdG8gYW4gaW1wb3N0ZXIuIgptc2dzdHIgIiIKIlfD pGhsZW4gU2llIHp1ciBBdXRoZW50aWZpemllcnVuZyBlaW5lIFBhc3NwaHJhc2UsIGRpZSBu dXIgSWhuZW4gdW5kIElocmVtICIKIkJ1ZGR5IGJla2FubnQgaXN0LiBHZWJlbiBTaWUgZGll c2UgUGFzc3BocmFzZSBlaW4sIHdhcnRlbiBTaWUgZGFubiBkYXJhdWYsICIKImRhc3MgSWhy IEJ1ZGR5IGRpZXNlIFBhc3NwaHJhc2UgZWJlbmZhbGxzIGVpbmdpYnQuIFdlbm4gZGllIFBh c3NwaHJhc2VuICIKIm5pY2h0IMO8YmVyZWluc3RpbW1lbiwgaGFiZW4gU2llIGVzIG3Dtmds aWNoZXJ3ZWlzZSBtaXQgZWluZW0gSG9jaHN0YXBsZXIgenUgIgoidHVuLiIKCiM6IC4uL2d0 ay1kaWFsb2cuYzo2MDEKbXNnaWQgIkVudGVyIHNlY3JldCBoZXJlOiIKbXNnc3RyICJHZWhl aW1lIFBhc3NwaHJhc2UgaGllciBlaW5nZWJlbiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo2NTIg Li4vZ3RrLWRpYWxvZy5jOjE0NzcgLi4vZ3RrLWRpYWxvZy5jOjE1MzAKbXNnaWQgIiIKIlRv IHZlcmlmeSB0aGUgZmluZ2VycHJpbnQsIGNvbnRhY3QgeW91ciBidWRkeSB2aWEgc29tZSA8 aT5vdGhlcjwvaT4gIgoiYXV0aGVudGljYXRlZCBjaGFubmVsLCBzdWNoIGFzIHRoZSB0ZWxl cGhvbmUgb3IgR1BHLXNpZ25lZCBlbWFpbC4gIEVhY2ggb2YgIgoieW91IHNob3VsZCB0ZWxs IHlvdXIgZmluZ2VycHJpbnQgdG8gdGhlIG90aGVyLiIKbXNnc3RyICIiCiJVbSBkZW4gRmlu Z2VycHJpbnQgenUgdmVyaWZpemllcmVuLCBrb250YWt0aWVyZW4gU2llIElocmVuIEJ1ZGR5 IMO8YmVyIGVpbmVuICIKIjxpPmFuZGVyZW48L2k+IHNpY2hlcmVuIEthbmFsLCB6dW0gQmVp c3BpZWwgcGVyc8O2bmxpY2gsIHBlciBHUEctIgoidmVyc2NobMO8c3NlbHRlciBFLU1haWwg b2RlciB0ZWxlZm9uaXNjaC4gU2llIHNvbGx0ZW4gU2ljaCBnZWdlbnNlaXRpZyBJaHJlICIK IkZpbmdlcnByaW50cyBtaXR0ZWlsZW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjY1NiAuLi9n dGstZGlhbG9nLmM6MTQ4MSAuLi9ndGstZGlhbG9nLmM6MTUzNAptc2dpZCAiIgoiSWYgZXZl cnl0aGluZyBtYXRjaGVzIHVwLCB5b3Ugc2hvdWxkIGluZGljYXRlIGluIHRoZSBhYm92ZSBk aWFsb2cgdGhhdCB5b3UgIgoiPGI+aGF2ZTwvYj4gdmVyaWZpZWQgdGhlIGZpbmdlcnByaW50 LiIKbXNnc3RyICIiCiJXZW5uIGFsbGVzIMO8YmVyZWluc3RpbW10LCBzb2xsdGVuIFNpZSBp bSBvYmlnZW4gRGlhbG9nIGFuZ2ViZW4sIGRhc3MgU2llIGRlbiAiCiJGaW5nZXJwcmludCA8 L2I+dGF0c8OkY2hsaWNoPC9iPiB2ZXJpZml6aWVydCBoYWJlbi4iCgojOiAuLi9ndGstZGlh bG9nLmM6NjY3IC4uL2d0ay1kaWFsb2cuYzoxNTE5Cm1zZ2lkICJbbm9uZV0iCm1zZ3N0ciAi W2tlaW5lcl0iCgojOiAuLi9ndGstZGlhbG9nLmM6Njc0IC4uL2d0ay1kaWFsb2cuYzoxMDMy IC4uL2d0ay1kaWFsb2cuYzoxNTI2CiM6IC4uL2d0ay1kaWFsb2cuYzoxNTc3IC4uL2d0ay11 aS5jOjE4MSAuLi9vdHItcGx1Z2luLmM6MTE2CiM6IC4uL290ci1wbHVnaW4uYzoyMTMgLi4v dWkuYzoxMTEKbXNnaWQgIlVua25vd24iCm1zZ3N0ciAiVW5iZWthbm50IgoKIzogLi4vZ3Rr LWRpYWxvZy5jOjY3NQojLCBjLWZvcm1hdAptc2dpZCAiIgoiRmluZ2VycHJpbnQgZm9yIHlv dSwgJXMgKCVzKTpcbiIKIiVzXG4iCiJcbiIKIlB1cnBvcnRlZCBmaW5nZXJwcmludCBmb3Ig JXM6XG4iCiIlc1xuIgptc2dzdHIgIiIKIkZpbmdlcnByaW50IGbDvHIgU2llLCAlcyAoJXMp OlxuIgoiJXNcbiIKIlxuIgoiQW5nZWdlYmVuZXIgRmluZ2VycHJpbnQgZsO8ciAlczpcbiIK IiVzXG4iCgojOiAuLi9ndGstZGlhbG9nLmM6NzI3Cm1zZ2lkICJIb3cgd291bGQgeW91IGxp a2UgdG8gYXV0aGVudGljYXRlIHlvdXIgYnVkZHk/Igptc2dzdHIgIldpZSBtw7ZjaHRlbiBT aWUgSWhyZW4gQnVkZHkgYXV0aGVudGlmaXppZXJlbj8iCgojOiAuLi9ndGstZGlhbG9nLmM6 NzM2Cm1zZ2lkICJRdWVzdGlvbiBhbmQgYW5zd2VyIgptc2dzdHIgIkZyYWdlIHVuZCBBbnR3 b3J0IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjczOQptc2dpZCAiU2hhcmVkIHNlY3JldCIKbXNn c3RyICJHZW1laW5zYW0gYmVrYW5udGUgUGFzc3BocmFzZSIKCiM6IC4uL2d0ay1kaWFsb2cu Yzo3NDIKbXNnaWQgIk1hbnVhbCBmaW5nZXJwcmludCB2ZXJpZmljYXRpb24iCm1zZ3N0ciAi TWFudWVsbGVyIEZpbmdlcnByaW50LVZlcmdsZWljaCIKCiM6IC4uL2d0ay1kaWFsb2cuYzo3 ODUKbXNnaWQgIl9BdXRoZW50aWNhdGUiCm1zZ3N0ciAiX0F1dGhlbnRpZml6aWVyZW4iCgoj OiAuLi9ndGstZGlhbG9nLmM6ODE4Cm1zZ2lkICIiCiJBdXRoZW50aWNhdGluZyBhIGJ1ZGR5 IGhlbHBzIGVuc3VyZSB0aGF0IHRoZSBwZXJzb24geW91IGFyZSB0YWxraW5nIHRvIGlzICIK IndobyBoZSBvciBzaGUgY2xhaW1zIHRvIGJlLiIKbXNnc3RyICIiCiJFaW5lbiBCdWRkeSB6 dSBhdXRoZW50aWZpemllcmVuIGhpbGZ0IHNpY2hlcnp1c3RlbGxlbiwgZGFzcyBkaWUgUGVy c29uLCBtaXQgIgoiZGVyIFNpZSBzcHJlY2hlbiBkaWUgaXN0LCBkaWUgc2llIHp1IHNlaW4g YmVoYXVwdGV0LiIKCiMuIFRyYW5zbGF0b3JzOiB5b3UgYXJlIGFza2VkIHRvIGF1dGhlbnRp Y2F0ZSB5b3Vyc2VsZgojOiAuLi9ndGstZGlhbG9nLmM6OTI3Cm1zZ2lkICJBdXRoZW50aWNh dGluZyB0byBCdWRkeSIKbXNnc3RyICJBdXRoZW50aWZpemllcmUgZ2VnZW7DvGJlciBCdWRk eSIKCiMuIFRyYW5zbGF0b3JzOiB5b3UgYXNrZWQgeW91ciBidWRkeSB0byBhdXRoZW50aWNh dGUgaGltL2hlcnNlbGYKIzogLi4vZ3RrLWRpYWxvZy5jOjkyOQptc2dpZCAiQXV0aGVudGlj YXRpbmcgQnVkZHkiCm1zZ3N0ciAiQXV0aGVudGlmaXppZXJlIEJ1ZGR5IgoKIzogLi4vZ3Rr LWRpYWxvZy5jOjk1NgojLCBjLWZvcm1hdAptc2dpZCAiQXV0aGVudGljYXRpbmcgdG8gJXMi Cm1zZ3N0ciAiQXV0aGVudGlmaXppZXJlIGdlZ2Vuw7xiZXIgJXMiCgojOiAuLi9ndGstZGlh bG9nLmM6OTU3CiMsIGMtZm9ybWF0Cm1zZ2lkICJBdXRoZW50aWNhdGluZyAlcyIKbXNnc3Ry ICJBdXRoZW50aWZpemllcmUgJXMiCgojOiAuLi9ndGstZGlhbG9nLmM6OTkwCm1zZ2lkICJX YWl0aW5nIGZvciBidWRkeS4uLiIKbXNnc3RyICJXYXJ0ZSBhdWYgQnVkZHkuLi4iCgojOiAu Li9ndGstZGlhbG9nLmM6MTAyMwptc2dpZCAiR2VuZXJhdGluZyBwcml2YXRlIGtleSIKbXNn c3RyICJHZW5lcmllcmUgcHJpdmF0ZW4gU2NobMO8c3NlbCIKCiM6IC4uL2d0ay1kaWFsb2cu YzoxMDI0Cm1zZ2lkICJQbGVhc2Ugd2FpdCIKbXNnc3RyICJCaXR0ZSB3YXJ0ZW4iCgojLiBD cmVhdGUgdGhlIFBsZWFzZSBXYWl0Li4uIGRpYWxvZwojOiAuLi9ndGstZGlhbG9nLmM6MTAz NQojLCBjLWZvcm1hdAptc2dpZCAiR2VuZXJhdGluZyBwcml2YXRlIGtleSBmb3IgJXMgKCVz KS4uLiIKbXNnc3RyICJHZW5lcmllcmUgcHJpdmF0ZW4gU2NobMO8c3NlbCBmw7xyICVzICgl cykuLi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTA4MAojLCBjLWZvcm1hdAptc2dpZCAiJXMg RG9uZS4iCm1zZ3N0ciAiJXMgRmVydGlnLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMTQyCiMs IGMtZm9ybWF0Cm1zZ2lkICIiCiIlcyBpcyBjb250YWN0aW5nIHlvdSBmcm9tIGFuIHVucmVj b2duaXplZCBjb21wdXRlci4gIFlvdSBzaG91bGQgPGEgaHJlZj1cIiVzJSIKInNcIj5hdXRo ZW50aWNhdGU8L2E+IHRoaXMgYnVkZHkuIgptc2dzdHIgIiIKIiVzIGtvbnRha3RpZXJ0IFNp ZSB2b24gZWluZW0gdW5iZWthbm50ZW4gQ29tcHV0ZXIgYXVzLiBTaWUgc29sbHRlbiBkaWVz ZW4gIgoiQnVkZHkgPGEgaHJlZj1cIiVzJXNcIj5hdXRoZW50aWZpemllcmVuPC9hPi4iCgoj OiAuLi9ndGstZGlhbG9nLmM6MTE0NgojLCBjLWZvcm1hdAptc2dpZCAiIgoiJXMgaGFzIG5v dCBiZWVuIGF1dGhlbnRpY2F0ZWQgeWV0LiAgWW91IHNob3VsZCA8YSBocmVmPVwiJXMlcyIK IlwiPmF1dGhlbnRpY2F0ZTwvYT4gdGhpcyBidWRkeS4iCm1zZ3N0ciAiIgoiJXMgd3VyZGUg bm9jaCBuaWNodCBhdXRoZW50aWZpemllcnQuIFNpZSBzb2xsdGVuIGRpZXNlbiBCdWRkeSA8 YSBocmVmPVwiJXMlcyIKIlwiPmF1dGhlbnRpZml6aWVyZW48L2E+LiIKCiM6IC4uL2d0ay1k aWFsb2cuYzoxMjA5IC4uL2d0ay1kaWFsb2cuYzoxMjQwIC4uL2d0ay1kaWFsb2cuYzoyMDMw CiM6IC4uL2d0ay1kaWFsb2cuYzoyMzA1IC4uL2d0ay11aS5jOjgyCm1zZ2lkICJGaW5pc2hl ZCIKbXNnc3RyICJCZWVuZGV0IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyMTAgLi4vZ3RrLWRp YWxvZy5jOjEyNDEgLi4vZ3RrLWRpYWxvZy5jOjIwMjcKIzogLi4vZ3RrLWRpYWxvZy5jOjIz MDIgLi4vZ3RrLXVpLmM6ODEKbXNnaWQgIlByaXZhdGUiCm1zZ3N0ciAiUHJpdmF0IgoKIzog Li4vZ3RrLWRpYWxvZy5jOjEyMTEgLi4vZ3RrLWRpYWxvZy5jOjEyNDIgLi4vZ3RrLWRpYWxv Zy5jOjIwMjQKIzogLi4vZ3RrLWRpYWxvZy5jOjIyOTkgLi4vZ3RrLXVpLmM6ODAKbXNnaWQg IlVudmVyaWZpZWQiCm1zZ3N0ciAiVW52ZXJpZml6aWVydCIKCiM6IC4uL2d0ay1kaWFsb2cu YzoxMjEyIC4uL2d0ay1kaWFsb2cuYzoxMjQzIC4uL2d0ay11aS5jOjc5Cm1zZ2lkICJOb3Qg cHJpdmF0ZSIKbXNnc3RyICJOaWNodCBwcml2YXQiCgojOiAuLi9ndGstZGlhbG9nLmM6MTIx NQptc2dpZCAiU3RhcnQgYSBwcml2YXRlIGNvbnZlcnNhdGlvbiIKbXNnc3RyICJQcml2YXRl IFVudGVyaGFsdHVuZyBzdGFydGVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyMTYKbXNnaWQg IlJlZnJlc2ggdGhlIHByaXZhdGUgY29udmVyc2F0aW9uIgptc2dzdHIgIlByaXZhdGUgVW50 ZXJoYWx0dW5nIGFrdHVhbGlzaWVyZW4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTIyMSAuLi9n dGstZGlhbG9nLmM6MTk3OSAuLi9ndGstZGlhbG9nLmM6MjA3NAptc2dpZCAiU3RhcnQgX3By aXZhdGUgY29udmVyc2F0aW9uIgptc2dzdHIgIl9Qcml2YXRlIFVudGVyaGFsdHVuZyBzdGFy dGVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyMjIgLi4vZ3RrLWRpYWxvZy5jOjE5ODAKbXNn aWQgIlJlZnJlc2ggX3ByaXZhdGUgY29udmVyc2F0aW9uIgptc2dzdHIgIl9Qcml2YXRlIFVu dGVyaGFsdHVuZyBha3R1YWxpc2llcmVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyNDYKbXNn aWQgIk9UUiIKbXNnc3RyICJPVFIiCgojLiBUcmFuc2xhdG9yczogdGhlIGZvbGxvd2luZyBm b3VyIG1lc3NhZ2VzIHNob3VsZCBnaXZlIGFsdGVybmF0aXZlIHNlbnRlbmNlcy4KIy4gVGhl IHVzZXIgc2VsZWN0cyB0aGUgZmlyc3Qgb3Igc2Vjb25kIG1lc3NhZ2UgaW4gYSBjb21ibyBi b3g7CiMuIHRoZSB0aGlyZCBtZXNzYWdlLCBhIG5ldyBsaW5lLCBhIGZpbmdlcnByaW50LCBh IG5ldyBsaW5lLCBhbmQKIy4gdGhlIGZvdXJ0aCBtZXNzYWdlIHdpbGwgZm9sbG93IGl0Lgoj OiAuLi9ndGstZGlhbG9nLmM6MTQ0OQptc2dpZCAiSSBoYXZlIG5vdCIKbXNnc3RyICJJY2gg aGFiZSBuaWNodCIKCiMuIDJuZCBtZXNzYWdlCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDUxCm1z Z2lkICJJIGhhdmUiCm1zZ3N0ciAiSWNoIGhhYmUiCgojLiAzcmQgbWVzc2FnZQojOiAuLi9n dGstZGlhbG9nLmM6MTQ1NAptc2dpZCAiIHZlcmlmaWVkIHRoYXQgdGhpcyBpcyBpbiBmYWN0 IHRoZSBjb3JyZWN0Igptc2dzdHIgIiDDvGJlcnByw7xmdCwgZGFzcyBkaWVzIHRhdHPDpGNo bGljaCBkZXIgcmljaHRpZ2UiCgojLiA0dGggbWVzc2FnZQojOiAuLi9ndGstZGlhbG9nLmM6 MTQ2NAojLCBjLWZvcm1hdAptc2dpZCAiZmluZ2VycHJpbnQgZm9yICVzLiIKbXNnc3RyICJG aW5nZXJwcmludCBmw7xyICVzIGlzdC4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTQ4Mwptc2dp ZCAiIgoiSWYgeW91ciBidWRkeSBoYXMgbW9yZSB0aGFuIG9uZSBJTSBhY2NvdW50LCBvciB1 c2VzIG1vcmUgdGhhbiBvbmUgY29tcHV0ZXIsICIKImhlIG1heSBoYXZlIG11bHRpcGxlIGZp bmdlcnByaW50cy4iCm1zZ3N0ciAiIgoiU29sbHRlIElociBCdWRkeSBtZWhyIGFscyBlaW4g SU0tS29udG8gb2RlciBtZWhyZXJlIENvbXB1dGVyIHZlcndlbmRlbiwga2FubiAiCiJlciBt ZWhyIGFscyBlaW5lbiBGaW5nZXJwcmludCBoYWJlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6 MTQ4NQptc2dpZCAiIgoiSG93ZXZlciwgdGhlIG9ubHkgd2F5IGFuIGltcG9zdGVyIGNvdWxk IGR1cGxpY2F0ZSBvbmUgb2YgeW91ciBidWRkeSdzICIKImZpbmdlcnByaW50cyBpcyBieSBz dGVhbGluZyBpbmZvcm1hdGlvbiBmcm9tIGhlci9oaXMgY29tcHV0ZXIuIgptc2dzdHIgIiIK IkRpZSBlaW56aWdlIE3DtmdsaWNoa2VpdCBmw7xyIGVpbmVuIEhvY2hzdGFwbGVyLCBkaWUg RmluZ2VycHJpbnRzIElocmVzIEJ1ZGR5cyAiCiJ6dSBrb3BpZXJlbiBpc3QgZGFzIFN0ZWhs ZW4gZGVyIEluZm9ybWF0aW9uZW4gdm9uIHNlaW5lbS9paHJlbSBDb21wdXRlci4iCgojOiAu Li9ndGstZGlhbG9nLmM6MTQ4OQptc2dpZCAiQ2xpY2sgaGVyZSBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBmaW5nZXJwcmludHMuIgptc2dzdHIgIktsaWNrZW4gU2llIGhpZXIgZsO8 ciB6dXPDpHR6bGljaGUgSW5mb3JtYXRpb25lbiDDvGJlciBGaW5nZXJwcmludHMuIgoKIzog Li4vZ3RrLWRpYWxvZy5jOjE0OTIKbXNnaWQgIiIKIkEgPGI+ZmluZ2VycHJpbnQ8L2I+IGlz IGEgdW5pcXVlIGlkZW50aWZpZXIgdGhhdCB5b3Ugc2hvdWxkIHVzZSB0byAiCiJhdXRoZW50 aWNhdGUgeW91ciBidWRkeS4iCm1zZ3N0ciAiIgoiRWluIDxiPkZpbmdlcnByaW50PC9iPiBp c3QgZWluIGVpbm1hbGlnZXMgSWRlbnRpZml6aWVydW5nc21lcmttYWwsIGRhcyBTaWUgIgoi dmVyd2VuZGVuIHNvbGx0ZW4sIHVtIElocmVuIEJ1ZGR5IHp1IGF1dGhlbnRpZml6aWVyZW4u IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE1MTUKIywgYy1mb3JtYXQKbXNnaWQgIlZlcmlmeSBm aW5nZXJwcmludCBmb3IgJXMiCm1zZ3N0ciAiRmluZ2VycHJpbnQgZsO8ciAlcyB2ZXJpZml6 aWVyZW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE1MjcKIywgYy1mb3JtYXQKbXNnaWQgIiIK IjxzbWFsbD48aT4lcyAlc1xuIgoiXG4iCiI8L2k+PC9zbWFsbD5GaW5nZXJwcmludCBmb3Ig eW91LCAlcyAoJXMpOlxuIgoiJXNcbiIKIlxuIgoiUHVycG9ydGVkIGZpbmdlcnByaW50IGZv ciAlczpcbiIKIiVzXG4iCm1zZ3N0ciAiIgoiPHNtYWxsPjxpPiVzICVzXG4iCiJcbiIKIjwv aT48L3NtYWxsPkZpbmdlcnByaW50IGbDvHIgU2llLCAlcyAoJXMpOlxuIgoiJXNcbiIKIlxu IgoiQW5nZWdlYmVuZXIgRmluZ2VycHJpbnQgZsO8ciAlczpcbiIKIiVzXG4iCgojOiAuLi9n dGstZGlhbG9nLmM6MTU0MCAuLi9ndGstdWkuYzo3ODIKbXNnaWQgIlZlcmlmeSBmaW5nZXJw cmludCIKbXNnc3RyICJGaW5nZXJwcmludCB2ZXJpZml6aWVyZW4iCgojOiAuLi9ndGstZGlh bG9nLmM6MTU2NwojLCBjLWZvcm1hdAptc2dpZCAiQXV0aGVudGljYXRpb24gZnJvbSAlcyIK bXNnc3RyICJBdXRoZW50aWZpemllcnVuZyB2b24gJXMiCgojOiAuLi9ndGstZGlhbG9nLmM6 MTU3MAojLCBjLWZvcm1hdAptc2dpZCAiQXV0aGVudGljYXRlICVzIgptc2dzdHIgIiVzIGF1 dGhlbnRpZml6aWVyZW4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTU4MAptc2dpZCAiQXV0aGVu dGljYXRlIEJ1ZGR5Igptc2dzdHIgIkJ1ZGR5IGF1dGhlbnRpZml6aWVyZW4iCgojOiAuLi9n dGstZGlhbG9nLmM6MTYxMQptc2dpZCAiQW4gZXJyb3Igb2NjdXJyZWQgZHVyaW5nIGF1dGhl bnRpY2F0aW9uLiIKbXNnc3RyICJFaW4gRmVobGVyIGlzdCBiZWkgZGVyIEF1dGhlbnRpZml6 aWVydW5nIGF1ZmdldHJldGVuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNjI2Cm1zZ2lkICJB dXRoZW50aWNhdGlvbiBzdWNjZXNzZnVsLiIKbXNnc3RyICJBdXRoZW50aWZpemllcnVuZyBl cmZvbGdyZWljaC4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTYyOQptc2dpZCAiIgoiWW91ciBi dWRkeSBoYXMgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZWQgeW91LiAgWW91IG1heSB3YW50 IHRvIGF1dGhlbnRpY2F0ZSAiCiJ5b3VyIGJ1ZGR5IGFzIHdlbGwgYnkgYXNraW5nIHlvdXIg b3duIHF1ZXN0aW9uLiIKbXNnc3RyICIiCiJJaHIgQnVkZHkgaGF0IFNpZSBlcmZvbGdyZWlj aCBhdXRoZW50aWZpemllcnQuIFVudGVyIFVtc3TDpG5kZW4gbcO2Y2h0ZW4gU2llICIKImVi ZW5mYWxscyBlaW5lIEZyYWdlIHN0ZWxsZW4gdW0gSWhyZW4gQnVkZHkgenUgYXV0aGVudGlm aXppZXJlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTYzNQptc2dpZCAiQXV0aGVudGljYXRp b24gZmFpbGVkLiIKbXNnc3RyICJBdXRoZW50aWZpemllcnVuZyBmZWhsZ2VzY2hsYWdlbi4i CgojOiAuLi9ndGstZGlhbG9nLmM6MTY2MwojLCBjLWZvcm1hdAptc2dpZCAiUHJpdmF0ZSBj b252ZXJzYXRpb24gd2l0aCAlcyBzdGFydGVkLiVzIgptc2dzdHIgIlByaXZhdGUgVW50ZXJo YWx0dW5nIG1pdCAlcyBiZWdvbm5lbi4lcyIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNjY3CiMs IGMtZm9ybWF0Cm1zZ2lkICI8YSBocmVmPVwiJXMlc1wiPlVudmVyaWZpZWQ8L2E+IGNvbnZl cnNhdGlvbiB3aXRoICUlcyBzdGFydGVkLiUlcyIKbXNnc3RyICIiCiJOaWNodCA8YSBocmVm PVwiJXMlc1wiPnZlcmlmaXppZXJ0ZTwvYT4gVW50ZXJoYWx0dW5nIG1pdCAlJXMgYmVnb25u ZW4uJSVzIgoKIy4gVGhpcyBsYXN0IGNhc2Ugc2hvdWxkIG5ldmVyIGhhcHBlbiwgc2luY2Ug d2Uga25vdwojLiAqIHdlJ3JlIGluIEVOQ1JZUFRFRC4KIzogLi4vZ3RrLWRpYWxvZy5jOjE2 NzUKIywgYy1mb3JtYXQKbXNnaWQgIk5vdCBwcml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVz IHN0YXJ0ZWQuJXMiCm1zZ3N0ciAiTmljaHQgcHJpdmF0ZSBVbnRlcmhhbHR1bmcgbWl0ICVz IGJlZ29ubmVuLiVzIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE2ODEgLi4vZ3RrLWRpYWxvZy5j OjE3ODUKbXNnaWQgIiAgV2FybmluZzogdXNpbmcgb2xkIHByb3RvY29sIHZlcnNpb24gMS4i Cm1zZ3N0ciAiICBXYXJudW5nOiBWZXJ3ZW5kZSB2ZXJhbHRldGUgUHJvdG9rb2xsdmVyc2lv biAxLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNzAxCiMsIGMtZm9ybWF0Cm1zZ2lkICJQcml2 YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVzIGxvc3QuIgptc2dzdHIgIlByaXZhdGUgVW50ZXJo YWx0dW5nIG1pdCAlcyBhYmdlYnJvY2hlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTczOAoj LCBjLWZvcm1hdAptc2dpZCAiIgoiJXMgaGFzIGVuZGVkIGhpcy9oZXIgcHJpdmF0ZSBjb252 ZXJzYXRpb24gd2l0aCB5b3U7IHlvdSBzaG91bGQgZG8gdGhlIHNhbWUuIgptc2dzdHIgIiIK IiVzIGhhdCBzZWluZS9paHJlIHByaXZhdGUgVW50ZXJoYWx0dW5nIG1pdCBJaG5lbiBiZWVu ZGV0LiBTaWUgc29sbHRlbiAiCiJkYXNzZWxiZSB0dW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5j OjE3NjQKIywgYy1mb3JtYXQKbXNnaWQgIlN1Y2Nlc3NmdWxseSByZWZyZXNoZWQgdGhlIHBy aXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuJXMiCm1zZ3N0ciAiUHJpdmF0ZSBVbnRlcmhh bHR1bmcgbWl0ICVzIGVyZm9sZ3JlaWNoIGFrdHVhbGlzaWVydC4lcyIKCiM6IC4uL2d0ay1k aWFsb2cuYzoxNzY5CiMsIGMtZm9ybWF0Cm1zZ2lkICIiCiJTdWNjZXNzZnVsbHkgcmVmcmVz aGVkIHRoZSA8YSBocmVmPVwiJXMlc1wiPnVudmVyaWZpZWQ8L2E+IGNvbnZlcnNhdGlvbiB3 aXRoICIKIiUlcy4lJXMiCm1zZ3N0ciAiIgoiTmljaHQgPGEgaHJlZj1cIiVzJXNcIj52ZXJp Zml6aWVydGU8L2E+IFVudGVyaGFsdHVuZyBtaXQgJSVzIGVyZm9sZ3JlaWNoICIKImFrdHVh bGlzaWVydC4lJXMiCgojLiBUaGlzIGxhc3QgY2FzZSBzaG91bGQgbmV2ZXIgaGFwcGVuLCBz aW5jZSB3ZSBrbm93CiMuICogd2UncmUgaW4gRU5DUllQVEVELgojOiAuLi9ndGstZGlhbG9n LmM6MTc3OAojLCBjLWZvcm1hdAptc2dpZCAiU3VjY2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUg bm90IHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuJXMiCm1zZ3N0ciAiTmljaHQgcHJp dmF0ZSBVbnRlcmhhbHR1bmcgbWl0ICVzIGVyZm9sZ3JlaWNoIGFrdHVhbGlzaWVydC4lcyIK CiM6IC4uL2d0ay1kaWFsb2cuYzoxODEwCiMsIGMtZm9ybWF0Cm1zZ2lkICJBdHRlbXB0aW5n IHRvIHJlZnJlc2ggdGhlIHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuLi4iCm1zZ3N0 ciAiVmVyc3VjaGUsIGRpZSBwcml2YXRlIFVudGVyaGFsdHVuZyBtaXQgJXMgenUgYWt0dWFs aXNpZXJlbi4uLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxODEyCiMsIGMtZm9ybWF0Cm1zZ2lk ICJBdHRlbXB0aW5nIHRvIHN0YXJ0IGEgcHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcy4u LiIKbXNnc3RyICJWZXJzdWNoZSwgZWluZSBwcml2YXRlIFVudGVyaGFsdHVuZyBtaXQgJXMg enUgYmVnaW5uZW4uLi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MjAyMSAuLi9ndGstZGlhbG9n LmM6MjI5Ngptc2dpZCAiTm90IFByaXZhdGUiCm1zZ3N0ciAiTmljaHQgcHJpdmF0IgoKIzog Li4vZ3RrLWRpYWxvZy5jOjIwNzUgLi4vZ3RrLWRpYWxvZy5jOjI0ODIKbXNnaWQgIl9FbmQg cHJpdmF0ZSBjb252ZXJzYXRpb24iCm1zZ3N0ciAiUHJpdmF0ZSBVbnRlcmhhbHR1bmcgYmVf ZW5kZW4iCgojLgojLiAqIERvbid0IHNob3cgdGhlIFZlcmlmeSBmaW5nZXJwcmludCBtZW51 IG9wdGlvbiBhbnkgbW9yZS4gIFlvdSBjYW4KIy4gKiBzdGlsbCBnZXQgdG8gdGhlIGRpYWxv ZyB0aHJvdWdoIEF1dGhlbnRpY2F0ZSBjb25uZWN0aW9uIC0+CiMuICogQWR2YW5jZWQuLi4K Iy4gKgojLiBtZW51dmVyZiA9IGd0a19tZW51X2l0ZW1fbmV3X3dpdGhfbW5lbW9uaWMoXygi X1ZlcmlmeSBmaW5nZXJwcmludCIpKTsKIy4gZ3RrX21lbnVfc2hlbGxfYXBwZW5kKEdUS19N RU5VX1NIRUxMKG1lbnUpLCBtZW51dmVyZik7CiMuIGd0a193aWRnZXRfc2hvdyhtZW51dmVy Zik7CiMuCiM6IC4uL2d0ay1kaWFsb2cuYzoyMDc2IC4uL2d0ay1kaWFsb2cuYzoyNTAwCm1z Z2lkICJfQXV0aGVudGljYXRlIGJ1ZGR5Igptc2dzdHIgIkJ1ZGR5IF9hdXRoZW50aWZpemll cmVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjIyOTIKIywgYy1mb3JtYXQKbXNnaWQgIiIKIlRo ZSBwcml2YWN5IHN0YXR1cyBvZiB0aGUgY3VycmVudCBjb252ZXJzYXRpb24gaXMgbm93OiA8 YSBocmVmPVwiJXMlc1wiPiVzPC8iCiJhPiIKbXNnc3RyICIiCiJEZXIgU3RhdHVzIGRlciBh a3R1ZWxsZW4gVW50ZXJoYWx0dW5nIGlzdCBqZXR6dDogPGEgaHJlZj1cIiVzJXNcIj4lczwv YT4iCgojOiAuLi9ndGstZGlhbG9nLmM6MjQ1NQptc2dpZCAiT1RSOiIKbXNnc3RyICJPVFI6 IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjI0NzUKbXNnaWQgIk9UUiBNZXNzYWdpbmciCm1zZ3N0 ciAiT1RSIE1lc3NhZ2luZyIKCiM6IC4uL2d0ay11aS5jOjEwMgojLCBjLWZvcm1hdAptc2dp ZCAiRmluZ2VycHJpbnQ6ICUuODBzIgptc2dzdHIgIkZpbmdlcnByaW50OiAlLjgwcyIKCiM6 IC4uL2d0ay11aS5jOjEwNgojLCBjLWZvcm1hdAptc2dpZCAiTm8ga2V5IHByZXNlbnQiCm1z Z3N0ciAiS2VpbiBTY2hsw7xzc2VsIHZvcmhhbmRlbiIKCiM6IC4uL2d0ay11aS5jOjExMQoj LCBjLWZvcm1hdAptc2dpZCAiTm8gYWNjb3VudCBhdmFpbGFibGUiCm1zZ3N0ciAiS2VpbmUg S29udGVuIHZlcmbDvGdiYXIiCgojOiAuLi9ndGstdWkuYzoxNzEKbXNnaWQgIlVudXNlZCIK bXNnc3RyICJVbmJlbnV0enQiCgojOiAuLi9ndGstdWkuYzoxNzcKbXNnaWQgIlllcyIKbXNn c3RyICJKYSIKCiM6IC4uL2d0ay11aS5jOjE3Nwptc2dpZCAiTm8iCm1zZ3N0ciAiTmVpbiIK CiM6IC4uL2d0ay11aS5jOjQwMwptc2dpZCAiRW5hYmxlIHByaXZhdGUgbWVzc2FnaW5nIgpt c2dzdHIgIlByaXZhdGVuIE5hY2hyaWNodGVudmVyc2FuZCBha3RpdmllcmVuIgoKIzogLi4v Z3RrLXVpLmM6NDA1Cm1zZ2lkICJBdXRvbWF0aWNhbGx5IGluaXRpYXRlIHByaXZhdGUgbWVz c2FnaW5nIgptc2dzdHIgIlByaXZhdGVuIE5hY2hyaWNodGVudmVyc2FuZCBhdXRvbWF0aXNj aCBha3RpdmllcmVuIgoKIzogLi4vZ3RrLXVpLmM6NDA3Cm1zZ2lkICJSZXF1aXJlIHByaXZh dGUgbWVzc2FnaW5nIgptc2dzdHIgIlByaXZhdGVuIE5hY2hyaWNodGVudmVyc2FuZCBlcnp3 aW5nZW4iCgojOiAuLi9ndGstdWkuYzo0MTAKbXNnaWQgIkRvbid0IGxvZyBPVFIgY29udmVy c2F0aW9ucyIKbXNnc3RyICJPVFItVW50ZXJoYWx0dW5nZW4gbmljaHQgc3BlaWNoZXJuIgoK IzogLi4vZ3RrLXVpLmM6NDU0Cm1zZ2lkICJTaG93IE9UUiBidXR0b24iCm1zZ3N0ciAiT1RS LUJ1dHRvbiBhbnplaWdlbiIKCiM6IC4uL2d0ay11aS5jOjQ1Nwptc2dpZCAiU2hvdyBPVFIg YnV0dG9uIGluIHRvb2xiYXIiCm1zZ3N0ciAiT1RSLUJ1dHRvbiBpbiBTeW1ib2xsZWlzdGUg YW56ZWlnZW4iCgojOiAuLi9ndGstdWkuYzo2MDEKbXNnaWQgIk15IHByaXZhdGUga2V5cyIK bXNnc3RyICJNZWluZSBwcml2YXRlbiBTY2hsw7xzc2VsIgoKIzogLi4vZ3RrLXVpLmM6NjEw Cm1zZ2lkICJLZXkgZm9yIGFjY291bnQ6Igptc2dzdHIgIlNjaGzDvHNzZWwgZsO8ciBLb250 bzoiCgojOiAuLi9ndGstdWkuYzo2MzUKbXNnaWQgIkdlbmVyYXRlIgptc2dzdHIgIkdlbmVy aWVyZW4iCgojOiAuLi9ndGstdWkuYzo2NzYKbXNnaWQgIkRlZmF1bHQgT1RSIFNldHRpbmdz Igptc2dzdHIgIlN0YW5kYXJkIE9UUi1FaW5zdGVsbHVuZ2VuIgoKIzogLi4vZ3RrLXVpLmM6 NzAzCm1zZ2lkICJPVFIgVUkgT3B0aW9ucyIKbXNnc3RyICJPVFItRXJzY2hlaW51bmdzYmls ZCIKCiM6IC4uL2d0ay11aS5jOjcyNgptc2dpZCAiU2NyZWVubmFtZSIKbXNnc3RyICJTcGl0 em5hbWUiCgojOiAuLi9ndGstdWkuYzo3MjcKbXNnaWQgIlN0YXR1cyIKbXNnc3RyICJTdGF0 dXMiCgojOiAuLi9ndGstdWkuYzo3MjgKbXNnaWQgIlZlcmlmaWVkIgptc2dzdHIgIlZlcmlm aXppZXJ0IgoKIzogLi4vZ3RrLXVpLmM6NzI5Cm1zZ2lkICJGaW5nZXJwcmludCIKbXNnc3Ry ICJGaW5nZXJwcmludCIKCiM6IC4uL2d0ay11aS5jOjczMAptc2dpZCAiQWNjb3VudCIKbXNn c3RyICJLb250byIKCiM6IC4uL2d0ay11aS5jOjc2Ngptc2dpZCAiU3RhcnQgcHJpdmF0ZSBj b25uZWN0aW9uIgptc2dzdHIgIlByaXZhdGUgVW50ZXJoYWx0dW5nIHN0YXJ0ZW4iCgojOiAu Li9ndGstdWkuYzo3NzQKbXNnaWQgIkVuZCBwcml2YXRlIGNvbm5lY3Rpb24iCm1zZ3N0ciAi UHJpdmF0ZSBVbnRlcmhhbHR1bmcgYmVlbmRlbiIKCiM6IC4uL2d0ay11aS5jOjc5MAptc2dp ZCAiRm9yZ2V0IGZpbmdlcnByaW50Igptc2dzdHIgIkZpbmdlcnByaW50IHZlcmdlc3NlbiIK CiM6IC4uL2d0ay11aS5jOjg0MQptc2dpZCAiQ29uZmlnIgptc2dzdHIgIktvbmZpZ3VyYXRp b24iCgojOiAuLi9ndGstdWkuYzo4NDMKbXNnaWQgIktub3duIGZpbmdlcnByaW50cyIKbXNn c3RyICJCZWthbm50ZSBGaW5nZXJwcmludHMiCgojOiAuLi9ndGstdWkuYzo5NDEgLi4vb3Ry LXBsdWdpbi5jOjYwNgptc2dpZCAiT1RSIFNldHRpbmdzIgptc2dzdHIgIk9UUi1FaW5zdGVs bHVuZ2VuIgoKIy4gU2V0IHRoZSB0aXRsZQojOiAuLi9ndGstdWkuYzo5NTkKIywgYy1mb3Jt YXQKbXNnaWQgIk9UUiBTZXR0aW5ncyBmb3IgJXMiCm1zZ3N0ciAiT1RSLUVpbnN0ZWxsdW5n ZW4gZsO8ciAlcyIKCiMuIE1ha2UgdGhlIGNhc2NhZGVkIGNoZWNrYm94ZXMKIzogLi4vZ3Rr LXVpLmM6OTc2Cm1zZ2lkICJVc2UgZGVmYXVsdCBPVFIgc2V0dGluZ3MgZm9yIHRoaXMgYnVk ZHkiCm1zZ3N0ciAiU3RhbmRhcmQgT1RSLUVpbnN0ZWxsdW5nZW4gZsO8ciBkaWVzZW4gQnVk ZHkgdmVyd2VuZGVuIgoKIzogLi4vb3RyLXBsdWdpbi5jOjExNAojLCBjLWZvcm1hdAptc2dp ZCAiWW91IGFyZSBub3QgY3VycmVudGx5IGNvbm5lY3RlZCB0byBhY2NvdW50ICVzICglcyku Igptc2dzdHIgIlNpZSBzaW5kIG1vbWVudGFuIG5pY2h0IG1pdCBLb250byAlcyB2ZXJidW5k ZW4oJXMpLiIKCiM6IC4uL290ci1wbHVnaW4uYzoxMTgKbXNnaWQgIk5vdCBjb25uZWN0ZWQi Cm1zZ3N0ciAiTmljaHQgdmVyYnVuZGVuIgoKIzogLi4vb3RyLXBsdWdpbi5jOjE2MgojLCBj LWZvcm1hdAptc2dpZCAiT3V0IG9mIG1lbW9yeSBidWlsZGluZyBmaWxlbmFtZXMhXG4iCm1z Z3N0ciAiS2VpbiBTcGVpY2hlciB6dW0gRXJzdGVsbGVuIHZvbiBEYXRlaW5hbWVuIVxuIgoK IzogLi4vb3RyLXBsdWdpbi5jOjE2OAojLCBjLWZvcm1hdAptc2dpZCAiQ291bGQgbm90IHdy aXRlIHByaXZhdGUga2V5IGZpbGVcbiIKbXNnc3RyICJLb25udGUgbmljaHQgaW4gZGllIFBy aXZhdGUtU2NobMO8c3NlbC1EYXRlaSBzY2hyZWliZW5cbiIKCiM6IC4uL290ci1wbHVnaW4u YzoyMTEKIywgYy1mb3JtYXQKbXNnaWQgIlVua25vd24gYWNjb3VudCAlcyAoJXMpLiIKbXNn c3RyICJVbmJla2FubnRlcyBLb250byAlcyAoJXMpLiIKCiM6IC4uL290ci1wbHVnaW4uYzoy MTUKbXNnaWQgIlVua25vd24gYWNjb3VudCIKbXNnc3RyICJVbmJla2FubnRlcyBLb250byIK CiM6IC4uL290ci1wbHVnaW4uYzo5ODMKbXNnaWQgIk9mZi10aGUtUmVjb3JkIE1lc3NhZ2lu ZyIKbXNnc3RyICJPZmYtdGhlLVJlY29yZCBNZXNzYWdpbmciCgojOiAuLi9vdHItcGx1Z2lu LmM6OTg0Cm1zZ2lkICJQcm92aWRlcyBwcml2YXRlIGFuZCBzZWN1cmUgY29udmVyc2F0aW9u cyIKbXNnc3RyICJFcm3DtmdsaWNodCBwcml2YXRlIHVuZCBzaWNoZXJlIFVudGVyaGFsdHVu Z2VuIgoKIzogLi4vb3RyLXBsdWdpbi5jOjk4NQptc2dpZCAiIgoiUHJlc2VydmVzIHRoZSBw cml2YWN5IG9mIElNIGNvbW11bmljYXRpb25zIGJ5IHByb3ZpZGluZyBlbmNyeXB0aW9uLCAi CiJhdXRoZW50aWNhdGlvbiwgZGVuaWFiaWxpdHksIGFuZCBwZXJmZWN0IGZvcndhcmQgc2Vj cmVjeS4iCm1zZ3N0ciAiIgoiQmV3YWhydCBkaWUgVmVydHJhdWxpY2hrZWl0IHZvbiBJTS1V bnRlcmhhbHR1bmdlbiBkdXJjaCBWZXJzY2hsw7xzc2VsdW5nLCAiCiJBdXRoZW50aWZpemll cnVuZywgR2xhdWJoYWZ0ZSBCZXN0cmVpdGJhcmtlaXQgdW5kIFBlcmZlY3QgRm9yd2FyZCBT ZWNyZWN5LiIKCiM6IC4uL3VpLmM6MTA5CiMsIGMtZm9ybWF0Cm1zZ2lkICJBY2NvdW50ICVz ICglcykgY291bGQgbm90IGJlIGZvdW5kIgptc2dzdHIgIktvbnRvICVzICglcykga29ubnRl IG5pY2h0IGdlZnVuZGVuIHdlcmRlbiIKCiM6IC4uL3VpLmM6MTEzCm1zZ2lkICJBY2NvdW50 IG5vdCBmb3VuZCIKbXNnc3RyICJLb250byBuaWNodCBnZWZ1bmRlbiIK --------------010802090302000402080908-- From ian@cypherpunks.ca Fri Jun 13 14:20:43 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 13 Jun 2008 09:20:43 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <485056A8.7070906@code.mmsources.de> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> <20080611202214.GI21852@thunk.cs.uwaterloo.ca> <485056A8.7070906@code.mmsources.de> Message-ID: <20080613132043.GC7861@thunk.cs.uwaterloo.ca> On Thu, Jun 12, 2008 at 12:50:16AM +0200, Michael Meier wrote: > > >Thanks! I modified your patch a little bit so that only the actual text > >(and not the markup) was marked as the translatable string, and modified > >your hu.po to match. > > > >Other translators: can you send in updated translations based on what's > >checked in right now? > > > Hello, > > latest revision of de.po attached Thanks! - Ian From paul@cypherpunks.ca Fri Jun 13 20:19:45 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 13 Jun 2008 15:19:45 -0400 (EDT) Subject: [OTR-dev] python bindings for libotr: pyotr In-Reply-To: <1213189869.8384.6.camel@hegg> References: <1213189869.8384.6.camel@hegg> Message-ID: On Wed, 11 Jun 2008, Kjell Braden wrote: > just wanted to let you know that I've created python bindings for libotr > some time ago. I've called them pyotr, because I'm so extremely > creative :) Cool! I'll have a look at them! Paul From fredrik.normann.junk@gmail.com Fri Jun 13 20:57:30 2008 From: fredrik.normann.junk@gmail.com (fredrik normann) Date: Fri, 13 Jun 2008 16:57:30 -0300 Subject: [OTR-dev] python bindings for libotr: pyotr In-Reply-To: References: <1213189869.8384.6.camel@hegg> Message-ID: ------=_Part_8904_4521933.1213387050724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Jun 13, 2008 at 4:19 PM, Paul Wouters wrote: > On Wed, 11 Jun 2008, Kjell Braden wrote: > > > just wanted to let you know that I've created python bindings for libotr > > some time ago. I've called them pyotr, because I'm so extremely > > creative :) > > Cool! I'll have a look at them! This sounds perfect for the MSN client emesene. http://www.emesene.org I thought about making a otr plugin for emesene, so this would be a nice help. -fredrik-normann- ------=_Part_8904_4521933.1213387050724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Jun 13, 2008 at 4:19 PM, Paul Wouters <paul@cypherpunks.ca> wrote:
On Wed, 11 Jun 2008, Kjell Braden wrote:

> just wanted to let you know that I've created python bindings for libotr
> some time ago. I've called them pyotr, because I'm so extremely
> creative :)

Cool! I'll have a look at them!

This sounds perfect for the MSN client emesene. http://www.emesene.org 

I thought about making a otr plugin for emesene, so this would be a nice help.

-fredrik-normann-
------=_Part_8904_4521933.1213387050724-- From damokles@ubuntu.com Tue Jun 17 13:17:14 2008 From: damokles@ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 14:17:14 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 Message-ID: <20080617121714.GG3541@lilith.spinnenwerk.de> --Rn7IEEq3VEzCw+ji Content-Type: multipart/mixed; boundary="PpAOPzA3dXsRhoo+" Content-Disposition: inline --PpAOPzA3dXsRhoo+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, after reading https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/156204 I checked the .purple/otr.* files created by pidgin-otr. They have a mode 644 which is at least for otr.private_key a security issue and breaks the design of .purple which actually makes files 0600. I wrote a small six line patch and successfully applied and tested it. Would you please check it and consider applying it to your upstream code? Patch is attached. Best, Caspar Clemens Mierau --=20 Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. --PpAOPzA3dXsRhoo+ Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="pidgin-otr-umask.diff" Content-Transfer-Encoding: quoted-printable --- otr-plugin.c.old 2008-06-17 13:24:57.000000000 +0200 +++ otr-plugin.c 2008-06-17 13:46:58.000000000 +0200 @@ -154,6 +154,7 @@ const char *protocol) { OtrgDialogWaitHandle waithandle; + mode_t mask; FILE *privf; =20 gchar *privkeyfile =3D g_build_filename(purple_user_dir(), PRIVKEYFNAM= E, NULL); @@ -161,7 +162,9 @@ fprintf(stderr, _("Out of memory building filenames!\n")); return; } + mask =3D umask (0077); privf =3D g_fopen(privkeyfile, "w+b"); + umask (mask); g_free(privkeyfile); if (!privf) { fprintf(stderr, _("Could not write private key file\n")); @@ -597,9 +600,12 @@ /* Write the fingerprints to disk. */ void otrg_plugin_write_fingerprints(void) { + mode_t mask; FILE *storef; gchar *storefile =3D g_build_filename(purple_user_dir(), STOREFNAME, N= ULL); + mask =3D umask (0077); storef =3D g_fopen(storefile, "wb"); + umask (mask); g_free(storefile); if (!storef) return; otrl_privkey_write_fingerprints_FILEp(otrg_plugin_userstate, storef); --PpAOPzA3dXsRhoo+-- --Rn7IEEq3VEzCw+ji Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIV6tKdbVIHJiaHn8RAuLpAJ4gHvCq3pASpOpe661d4KrKDZI6VQCeL7Ly hB2d2Bv5MD0xdi7KM8yLEtg= =vdEb -----END PGP SIGNATURE----- --Rn7IEEq3VEzCw+ji-- From ian@cypherpunks.ca Tue Jun 17 16:49:01 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 11:49:01 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617121714.GG3541@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> Message-ID: <20080617154901.GF6787@thunk.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 02:17:14PM +0200, Caspar Clemens Mierau wrote: > Hi, > > after reading > > https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/156204 > > I checked the .purple/otr.* files created by pidgin-otr. They have a > mode 644 which is at least for otr.private_key a security issue and > breaks the design of .purple which actually makes files 0600. > > I wrote a small six line patch and successfully applied and tested it. > Would you please check it and consider applying it to your upstream > code? > > Patch is attached. Thanks! My only concern is what happens when you try to build the Windows version of pidgin-otr with this patch. I suppose we could wrap it in a HAVE_UMASK or something? My Win32 cross-compilation environment isn't with me right now, but I'll check it later on. - Ian From damokles@ubuntu.com Tue Jun 17 19:08:18 2008 From: damokles@ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 20:08:18 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617154901.GF6787@thunk.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> Message-ID: <20080617180818.GC20817@lilith.spinnenwerk.de> --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jun 17, 2008 at 11:49:01AM -0400, Ian Goldberg wrote: > Thanks! My only concern is what happens when you try to build the > Windows version of pidgin-otr with this patch. I suppose we could wrap > it in a HAVE_UMASK or something? My Win32 cross-compilation environment > isn't with me right now, but I'll check it later on. actually I think, the glib stuff is quite Win32 safe. See: http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html "g_chmod() A wrapper for the POSIX chmod() function. The chmod() function is used to set the permissions of a file system object. Note that on Windows the file protection mechanism is not at all POSIX-like, and the underlying chmod() function in the C library just sets or clears the READONLY attribute. It does not touch any ACL. Software that needs to manage file permissions on Windows exactly should use the Win32 API." So according to the official documentation, using g_chmod under Win32 won't crash. It only seems to set a readonly flag when removing too much "w" flags. Actually I even think that you are already fine using g_fopen under Win32, but somebody needs to confirm this. Best, Caspar Clemens Mierau --=20 Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. --EY/WZ/HvNxOox07X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIV/2SdbVIHJiaHn8RArAVAJ9f+VI0e+hgodK/vrpz74bAgA4C8gCfQ6Us qQ0Vz7aRkz2qtdFf4JhSKno= =bcw5 -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From ian@cypherpunks.ca Tue Jun 17 21:30:20 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 16:30:20 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617180818.GC20817@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> Message-ID: <20080617203020.GO6787@thunk.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 08:08:18PM +0200, Caspar Clemens Mierau wrote: > Hi, > > On Tue, Jun 17, 2008 at 11:49:01AM -0400, Ian Goldberg wrote: > > Thanks! My only concern is what happens when you try to build the > > Windows version of pidgin-otr with this patch. I suppose we could wrap > > it in a HAVE_UMASK or something? My Win32 cross-compilation environment > > isn't with me right now, but I'll check it later on. > > actually I think, the glib stuff is quite Win32 safe. See: > http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html > > "g_chmod() > > A wrapper for the POSIX chmod() function. The chmod() function is used > to set the permissions of a file system object. Note that on Windows the > file protection mechanism is not at all POSIX-like, and the underlying > chmod() function in the C library just sets or clears the READONLY > attribute. It does not touch any ACL. Software that needs to manage file > permissions on Windows exactly should use the Win32 API." > > So according to the official documentation, using g_chmod under Win32 > won't crash. It only seems to set a readonly flag when removing too much > "w" flags. > > Actually I even think that you are already fine using g_fopen under > Win32, but somebody needs to confirm this. But there's no equivalent for umask, right? - Ian From damokles@ubuntu.com Tue Jun 17 22:17:14 2008 From: damokles@ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 23:17:14 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617203020.GO6787@thunk.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> Message-ID: <20080617211714.GD20817@lilith.spinnenwerk.de> --zjcmjzIkjQU2rmur Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Actually I even think that you are already fine using g_fopen under > > Win32, but somebody needs to confirm this. >=20 > But there's no equivalent for umask, right? Right. On Windows there is POSIX umask equivalent. There only exists a readonly flag which poorly acts like a 444 mode. Glib therefore mostly seems to ignore umask calls and only tries to set "readonly" when it seems equivalent to the current umask. If we want to be totally safe, we should check the platform and don't call the umask when on Win32. Otherwise trusting glib documentation actually prevents us from writing more code than actually necessary. Let's have a look at g_chmod in glib: -------snip------ /** * g_chmod: * @filename: a pathname in the GLib file name encoding (UTF-8 on Windows) * @mode: as in chmod() * * A wrapper for the POSIX chmod() function. The chmod() function is * used to set the permissions of a file system object. Note that on * Windows the file protection mechanism is not at all POSIX-like, and * the underlying chmod() function in the C library just sets or * clears the READONLY attribute. It does not touch any ACL. Software * that needs to manage file permissions on Windows exactly should * use the Win32 API. * * See the C library manual for more details about chmod(). * * Returns: zero if the operation succeeded, -1 on error. *=20 * Since: 2.8 */ int g_chmod (const gchar *filename, int mode) { #ifdef G_OS_WIN32 wchar_t *wfilename =3D g_utf8_to_utf16 (filename, -1, NULL, NULL, NULL); int retval; int save_errno; =20 if (wfilename =3D=3D NULL) { errno =3D EINVAL; return -1; } retval =3D _wchmod (wfilename, mode); save_errno =3D errno; g_free (wfilename); errno =3D save_errno; return retval; #else return chmod (filename, mode); #endif } -------snap------ Note: This has been introduced in glib 2.8 and would therefore increase the current minimum glib version from 2.6 to 2.8. Best, Caspar Clemens Mierau --=20 Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. --zjcmjzIkjQU2rmur Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIWCnadbVIHJiaHn8RAux2AKCEn31oCXYZ8Uk/ObCAhrtnR+XpmwCgkK/v 8ivOtXXBq3jyWrBxL2f6/aQ= =L7Cw -----END PGP SIGNATURE----- --zjcmjzIkjQU2rmur-- From ian@cypherpunks.ca Tue Jun 17 22:27:06 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:27:06 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617211714.GD20817@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> Message-ID: <20080617212706.GH24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 11:17:14PM +0200, Caspar Clemens Mierau wrote: > > > Actually I even think that you are already fine using g_fopen under > > > Win32, but somebody needs to confirm this. > > > > But there's no equivalent for umask, right? > > Right. On Windows there is POSIX umask equivalent. There only exists a > readonly flag which poorly acts like a 444 mode. Glib therefore mostly > seems to ignore umask calls and only tries to set "readonly" when it > seems equivalent to the current umask. > > If we want to be totally safe, we should check the platform and don't > call the umask when on Win32. Otherwise trusting glib documentation > actually prevents us from writing more code than actually necessary. But the platform is determined at compile time. So I think I'll just apply your patch, but with the new umask lines wrapped in: #ifdef HAVE_UMASK #endif /* HAVE_UMASK */ - Ian From ian@cypherpunks.ca Tue Jun 17 22:48:31 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:48:31 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617212706.GH24909@yoink.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> <20080617212706.GH24909@yoink.cs.uwaterloo.ca> Message-ID: <20080617214831.GI24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 05:27:06PM -0400, Ian Goldberg wrote: > On Tue, Jun 17, 2008 at 11:17:14PM +0200, Caspar Clemens Mierau wrote: > > > > Actually I even think that you are already fine using g_fopen under > > > > Win32, but somebody needs to confirm this. > > > > > > But there's no equivalent for umask, right? > > > > Right. On Windows there is POSIX umask equivalent. There only exists a > > readonly flag which poorly acts like a 444 mode. Glib therefore mostly > > seems to ignore umask calls and only tries to set "readonly" when it > > seems equivalent to the current umask. > > > > If we want to be totally safe, we should check the platform and don't > > call the umask when on Win32. Otherwise trusting glib documentation > > actually prevents us from writing more code than actually necessary. > > But the platform is determined at compile time. So I think I'll just > apply your patch, but with the new umask lines wrapped in: > > #ifdef HAVE_UMASK > > #endif /* HAVE_UMASK */ Ah, no, I see that that's wrong. Windows does in fact have the umask() call; it just can't do something like 077. Sorry I misunderstood earlier. So I need to wrap it in #ifndef WIN32 #endif /* WIN32 */ I suppose. - Ian From ian@cypherpunks.ca Tue Jun 17 22:59:22 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:59:22 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617214831.GI24909@yoink.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> <20080617212706.GH24909@yoink.cs.uwaterloo.ca> <20080617214831.GI24909@yoink.cs.uwaterloo.ca> Message-ID: <20080617215922.GJ24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 05:48:31PM -0400, Ian Goldberg wrote: > Ah, no, I see that that's wrong. Windows does in fact have the umask() > call; it just can't do something like 077. Sorry I misunderstood > earlier. So I need to wrap it in > > #ifndef WIN32 > > #endif /* WIN32 */ > > I suppose. Done and checked in. Thanks for the patch! - Ian From willylew@gmail.com Wed Jun 18 02:41:54 2008 From: willylew@gmail.com (Willy Lew) Date: Tue, 17 Jun 2008 21:41:54 -0400 Subject: [OTR-dev] Requirements for libotr4 Message-ID: ------=_Part_3121_10507133.1213753314536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello fellow IM devs, As some of you may already know, we are revamping the libotr API (the messaging part in particular) to address several issues that were brought up recently. The four major changes are: *** 1. Hardcoded strings *** No more hardcoded HTML error strings! We are adding a new function in OtrlMessageAppOps to let the IM handle the error according to an error code. For instance, OtrlMessageAppOps will look like this: typedef struct s_OtrlMessageAppOps { OtrlPolicy (*policy)(void *opdata, ConnContext *context); ... void (*account_name_free)(void *opdata, const char *account_name); /* Handles an error given the error code */ void (*handle_error)(void *opdata, ConnContext *context, OtrlErrorCode error_code); } OtrlMessageAppOps; Tentatively, we will provide a convenient errorcode-to-errorstring lookup function that will look like this: const char * otrl_message_errstr_en(OtrlErrorCode error_code); *** 2. Custom message stripping function *** otrl_message_sending and otrl_message_receiving will be having an extra optional argument (a callback function) to give the IMs the flexibility to strip/convert the messages that are sent/received. For example, the conversion function could strip the HTML tags out of the original message in order to be guaranteed an HTML-free message. gcry_error_t otrl_message_sending(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *recipient, const char *message, OtrlTLV *tlvs, char **messagep, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata); int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *sender, const char *message, char **newmessagep, OtrlTLV **tlvsp, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata); *** 3. Fragmentation *** We are adding a new argument (OtrlFragmentPolicy) to otrl_message_sending so that the fragmentation task is done without manually calling otrl_message_fragment_and_send. If the original messaging behaviour is preferred, the OtrlFragmentPolicy can be OTRL_FRAGMENT_DONTFRAGMENT. The new signature for otrl_message_sending (including the conversion function as described above) will look like this: gcry_error_t otrl_message_sending(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *recipient, const char *message, OtrlTLV *tlvs, char **messagep, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata, OtrlFragmentPolicy fragPolicy); Since we will not need to call otrl_message_fragment_and_send anymore, we are planning to remove that function from the public API. *** 4. Stripping ConnContext *** We are stripping down ConnContext so that it only exposes the members that are meant to be public. It will look like this: typedef struct context { char * username; char * accountname; char * protocol; OtrlMessageState msgstate; OtrlAuthInfo auth; Fingerprint fingerprint_root; Fingerprint *active_fingerprint; unsigned int protocol_version; void *app_data; void (*app_data_free)(void *); OtrlSMState *smstate; ConnContextInternal *internal_context; } ConnContext; At the end of this email you will find a list of APIs that will be kept public. I have made that list by going through the code of a few IMs that use OTR and by recording their respective otrl_* calls. If I have missed anything in that list or if you have any other concerns/issues, please let me know asap since I am in the process of gathering the requirements for the new API. Note that we are also fixing the multiple login problem and this entails a few other changes to the API but those have not been finalized yet. Cheers! - willy *** List of APIs to be kept in libotr4 *** otrl_context_disconnect otrl_context_find otrl_context_find_fingerprint otrl_context_forget_all otrl_context_forget_fingerprint otrl_context_set_trust otrl_message_abort_smp otrl_message_disconnect otrl_message_free otrl_message_initiate_smp otrl_message_initiate_smp_q otrl_message_receiving otrl_message_respond_smp otrl_message_sending otrl_privkey_fingerprint otrl_privkey_forget_all otrl_privkey_generate otrl_privkey_generate_FILEp otrl_privkey_hash_to_human otrl_privkey_read otrl_privkey_read_FILEp otrl_privkey_read_fingerprints otrl_privkey_read_fingerprints_FILEp otrl_privkey_write_fingerprints otrl_privkey_write_fingerprints_FILEp otrl_proto_default_query_msg otrl_proto_message_type otrl_tlv_find otrl_tlv_free otrl_userstate_create otrl_userstate_free ------=_Part_3121_10507133.1213753314536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello fellow IM devs,

As some of you may already know, we are revamping the libotr API (the messaging part in particular) to address several issues that were brought up recently. The four major changes are:

*** 1. Hardcoded strings ***
No more hardcoded HTML error strings! We are adding a new function in OtrlMessageAppOps to let the IM handle the error according to an error code. For instance, OtrlMessageAppOps will look like this:

typedef struct s_OtrlMessageAppOps {
    OtrlPolicy (*policy)(void *opdata, ConnContext *context);
    ...
    void (*account_name_free)(void *opdata, const char *account_name);

    /* Handles an error given the error code */
    void (*handle_error)(void *opdata, ConnContext *context, OtrlErrorCode error_code);
} OtrlMessageAppOps;


Tentatively, we will provide a convenient errorcode-to-errorstring lookup function that will look like this:

const char * otrl_message_errstr_en(OtrlErrorCode error_code);


*** 2. Custom message stripping function ***
otrl_message_sending and otrl_message_receiving will be having an extra optional argument (a callback function) to give the IMs the flexibility to strip/convert the messages that are sent/received. For example, the conversion function could strip the HTML tags out of the original message in order to be guaranteed an HTML-free message.

gcry_error_t otrl_message_sending(OtrlUserState us,
    const OtrlMessageAppOps *ops,
    void *opdata, const char *accountname, const char *protocol,
    const char *recipient, const char *message, OtrlTLV *tlvs,
    char **messagep,
    void (*add_appdata)(void *data, ConnContext *context),
    void *data,
    void (*convert_msg)(void *convertdata, char *source, char **target),
    void *convertdata);

int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops,
    void *opdata, const char *accountname, const char *protocol,
    const char *sender, const char *message, char **newmessagep,
    OtrlTLV **tlvsp,
    void (*add_appdata)(void *data, ConnContext *context),
    void *data,
    void (*convert_msg)(void *convertdata, char *source, char **target),
    void *convertdata);

*** 3. Fragmentation ***
We are adding a new argument (OtrlFragmentPolicy) to otrl_message_sending so that the fragmentation task is done without manually calling  otrl_message_fragment_and_send. If the original messaging behaviour is preferred, the OtrlFragmentPolicy can be OTRL_FRAGMENT_DONTFRAGMENT. The new signature for otrl_message_sending (including the conversion function as described above) will look like this:


gcry_error_t otrl_message_sending(OtrlUserState us,
    const OtrlMessageAppOps *ops,
    void *opdata, const char *accountname, const char *protocol,
    const char *recipient, const char *message, OtrlTLV *tlvs,
    char **messagep,
    void (*add_appdata)(void *data, ConnContext *context),
    void *data,
    void (*convert_msg)(void *convertdata, char *source, char **target),
    void *convertdata,
    OtrlFragmentPolicy fragPolicy);


Since we will not need to call otrl_message_fragment_and_send anymore, we are planning to remove that function from the public API.

*** 4. Stripping ConnContext ***
We are stripping down ConnContext so that it only exposes the members that are meant to be public. It will look like this:

typedef struct context {
    char * username;
    char * accountname;
    char * protocol;
    OtrlMessageState msgstate;
    OtrlAuthInfo auth;
    Fingerprint fingerprint_root;
    Fingerprint *active_fingerprint;
    unsigned int protocol_version;
    void *app_data;
    void (*app_data_free)(void *);
    OtrlSMState *smstate;

    ConnContextInternal *internal_context;
} ConnContext;



At the end of this email you will find a list of APIs that will be kept public. I have made that list by going through the code of a few IMs that use OTR and by recording their respective otrl_* calls. If I have missed anything in that list or if you have any other concerns/issues, please let me know asap since I am in the process of gathering the requirements for the new API. Note that we are also fixing the multiple login problem and this entails a few other changes to the API but those have not been finalized yet.

Cheers!
- willy


*** List of APIs to be kept in libotr4 ***
otrl_context_disconnect
otrl_context_find
otrl_context_find_fingerprint
otrl_context_forget_all
otrl_context_forget_fingerprint
otrl_context_set_trust

otrl_message_abort_smp
otrl_message_disconnect
otrl_message_free
otrl_message_initiate_smp
otrl_message_initiate_smp_q
otrl_message_receiving
otrl_message_respond_smp
otrl_message_sending

otrl_privkey_fingerprint
otrl_privkey_forget_all
otrl_privkey_generate
otrl_privkey_generate_FILEp
otrl_privkey_hash_to_human
otrl_privkey_read
otrl_privkey_read_FILEp
otrl_privkey_read_fingerprints
otrl_privkey_read_fingerprints_FILEp
otrl_privkey_write_fingerprints
otrl_privkey_write_fingerprints_FILEp

otrl_proto_default_query_msg
otrl_proto_message_type

otrl_tlv_find
otrl_tlv_free

otrl_userstate_create
otrl_userstate_free
------=_Part_3121_10507133.1213753314536-- From js-otrim@webkeks.org Wed Jun 18 13:06:06 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Wed, 18 Jun 2008 14:06:06 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: References: Message-ID: <20080618140606.052ef410@webkeks.org> --Sig_/f5BhxE7h_VPcCTA_xxVCcBz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable There's one thing we'd absolutely need for libotr4 to support OTR in Gajim again (this is the main reason why we removed the OTR code from it completely): When calling otrl_message_fragment_and_send, it returns the fragments and calls our inject_message method. Our inject_message method calls send_message, which returns an ID. This is the ID used by the XMPP library for the sent XMPP message stanza. We need this ID for some XEPs like for example XEP-0184 (so we can verify our message was received - note: XEP-0184 is just chosen as an example here, there are even more that require knowing the ID of our sent XMPP message stanza). With the way this is handled in libotr3, we just loose that ID and thus can't implement some XEPs (thus we removed OTR form Gajim). As you already said you're going to remove otrl_message_fragment_and_send, I'd suggest that the new API includes a way to get the return value of the inject_message function (our inject_message function could just return the ID from send_message then) so we can get the XMPP message stanza ID. --=20 Jonathan --Sig_/f5BhxE7h_VPcCTA_xxVCcBz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIWPoyAAoJEMtRg9d5cXHkT0UP/0tCRCkk23Q0RqwpIpy3iI6s eEmt1UPuM1NLYq2pl93V4hQKZ3nHufOmY6125PiIkrW0cyUW2jAPnAENKJkMRSNv TDWL5Y2zsDr69Ghq+SZm/U9vcJAv0YhLM02ahiLkl0QqJuIyR+yUQa1VC2a1bgXY YQDnymUSdlspd+8VhLo6m7NV74YKqGwiRrncHPsyXWy0lsziSek5sYs9i15H07t/ qURbLcHEVZ6QuWTvkxmBqHt4u4gKuBQ2rcmnouQ0Yhc9EEDnEMs/3xrPUMGo7if5 lYupk0lk8k4pVO+RqF7m8mES3V6/s4xHZquRHtivhnGkY8113SDgvqAZ6oT8g9bF /Y+AbUyUZzosRD2emEfuE6fZ/kqqiCzvH8W26GICIZSAHWvW2ZPDXgUe4D2wl2ss mDoKB1frHKN3Hprjp0VOeYhWycLPdIgryFMh6/BCzQ/kJh7YtZDHfDjmq/GRPkah vFebi8m5gXp0DSY9cN75e2w93vV9VJZzEKAhJ/kiLv4gc8E0uw6+mlKVyfMsjVUT ayfO/gj1DIySwGZF40Uz2SH6EcjCwqmKAhqdNAiHIksYSoMpLvc+7/9e700NS+YY M3NeAhO39wK5QrdN1OA+2X5jCWl3YPvhoCrktKWZHEx+E/89+l1OuqgYabhMfdlz pJuCsYfVsZuuCCT73VK1 =vtR9 -----END PGP SIGNATURE----- --Sig_/f5BhxE7h_VPcCTA_xxVCcBz-- From ian@cypherpunks.ca Wed Jun 18 13:56:37 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 18 Jun 2008 08:56:37 -0400 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618140606.052ef410@webkeks.org> References: <20080618140606.052ef410@webkeks.org> Message-ID: <20080618125637.GD3386@thunk.cs.uwaterloo.ca> On Wed, Jun 18, 2008 at 02:06:06PM +0200, Jonathan Schleifer wrote: > There's one thing we'd absolutely need for libotr4 to support OTR in > Gajim again (this is the main reason why we removed the OTR code from it > completely): > When calling otrl_message_fragment_and_send, it returns the fragments > and calls our inject_message method. Our inject_message method calls > send_message, which returns an ID. This is the ID used by the XMPP > library for the sent XMPP message stanza. We need this ID for some XEPs > like for example XEP-0184 (so we can verify our message was received - > note: XEP-0184 is just chosen as an example here, there are even more > that require knowing the ID of our sent XMPP message stanza). With the > way this is handled in libotr3, we just loose that ID and thus can't > implement some XEPs (thus we removed OTR form Gajim). > As you already said you're going to remove > otrl_message_fragment_and_send, I'd suggest that the new API > includes a way to get the return value of the inject_message > function (our inject_message function could just return the > ID from send_message then) so we can get the XMPP message stanza ID. Isn't that what opdata is for? inject_message returns void, because we can't predict what kinds of things you might want to return. Instead, it takes as a parameter an arbitrary void* opdata, which you can use however you want (pass &retval for example). So your inject_message function could set *(XmppId *)opdata = id and you would have access to that when the call to otrl_message_sending completes. But I thought XMPP didn't need fragmentation, anyway? If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be done, otrl_message_fragment_and_send will just return to you the (unfragmented) message to be sent, and you can send it yourself. What do you think? - Ian From js-otrim@webkeks.org Wed Jun 18 15:47:37 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Wed, 18 Jun 2008 16:47:37 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618125637.GD3386@thunk.cs.uwaterloo.ca> References: <20080618140606.052ef410@webkeks.org> <20080618125637.GD3386@thunk.cs.uwaterloo.ca> Message-ID: <20080618164737.295b463f@webkeks.org> --Sig_/WdHd9zEsHH.04mrvpvqMY=e Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ian Goldberg wrote: > Isn't that what opdata is for? inject_message returns void, because > we can't predict what kinds of things you might want to return. > Instead, it takes as a parameter an arbitrary void* opdata, which you > can use however you want (pass &retval for example). I must admit that I'm not too familiar with libotr itself as I only used the pyotr bindings of it (Gajim is written in Python). So basically, you say I should give a void *opdata to the otrl_message_fragment_and_send function and modify it in the inject_message function and get it from opdata again after calling otrl_message_fragment_and_send? I haven't tested it now, but that sounds like it should work, thanks for pointing out. But what I'd prefer is that inject_message doesn't return void but void*, so one could return arbitrary data (in this case it's the stanza ID) and then some way to get that return value from the function called. > So your inject_message function could set *(XmppId *)opdata =3D id and > you would have access to that when the call to otrl_message_sending > completes. That sounds good enough for me. > But I thought XMPP didn't need fragmentation, anyway? XMPP itself doesn't, but it's possible to use ICQ through transports via XMPP, thus you'll need it then. > If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or > OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be > done, otrl_message_fragment_and_send will just return to you the > (unfragmented) message to be sent, and you can send it yourself. I guess this will give problems with ICQ through transports. If otrl_message_fragment_and_send returns the fragments, wouldn't be another possible way to send those fragments manually? That would have the advantage that I get the ID of every sent message, not only the first / last ID. That would be a big advantage, as we could request a receipt for every fragment seperately then. --=20 Jonathan --Sig_/WdHd9zEsHH.04mrvpvqMY=e Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIWSANAAoJEMtRg9d5cXHk9xkP/1b84sRNpU3VI38Fh1UW1CSQ QZgsv1/s4orS9e1ys9V0mylReLv2mbKErfgI8HRHMV13EppxUQmHWIBkhDYOJiCB N8Vb1X3gu44+bgKIw70DhRLKzaD7A1mgF/NpeU4zbxhdPnJ8RQD+lIZOkCi8t8h2 vV5zo52d/qvaZHgzWpjauM23rvp9FpZ+Sj8vXaVNKjw/bCtWeTsrVfT5fV7Y89No dYK0D2crvYvR3e7TunvlZYOPnnFpm1qdJZSeVbaJlhxTHGk2z3owGvKMJkWQyrp4 q1TvtS0bSTuXdvjxhAfNFK9vGfw/3D0ws43bLQSg2+kERJi4UQxpf5pEebbLuNKu bDxWz/hcH0zSulIMsM+xZS223orsYJDoS+DQWR3AeoKFlE6i2Ejw3TEt2BO545FR kDMowHwLs5fCvUs+N1C6IZ7U+cTdA1qYLJI/JZnK2LXVDmquWFXpZ3//sML6zIIh BZ8s//AuiABOPn0o/XLBngkl/P92ultA7gsjW9QMeDpsqcRSLxqJkE8igMpCC0YH x4r6pXrO2/iPcgzmGQAPraHKldNJGxLBLptulSNPsBHCX0OjtIp+Ak3FViwzsLLr OI9GWZdXfjbWC2Tkl3+BXabxEqSY1qlNyjOrK54a968NWr24+VQepj15WijsWi3m aAWqgEiGnMQuChta2ntV =vDsp -----END PGP SIGNATURE----- --Sig_/WdHd9zEsHH.04mrvpvqMY=e-- From fnord@pentabarf.de Wed Jun 18 19:52:14 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Wed, 18 Jun 2008 20:52:14 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618164737.295b463f@webkeks.org> References: <20080618140606.052ef410@webkeks.org> <20080618125637.GD3386@thunk.cs.uwaterloo.ca> <20080618164737.295b463f@webkeks.org> Message-ID: <1213815134.16121.5.camel@hegg> --=-DrHXXXuP7h+HhwWbnIoa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mi, 2008-06-18 at 16:47 +0200, Jonathan Schleifer wrote: > Ian Goldberg wrote: >=20 > > If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or > > OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be > > done, otrl_message_fragment_and_send will just return to you the > > (unfragmented) message to be sent, and you can send it yourself. >=20 > I guess this will give problems with ICQ through transports. > If otrl_message_fragment_and_send returns the fragments, wouldn't be > another possible way to send those fragments manually? That would have > the advantage that I get the ID of every sent message, not only the > first / last ID. That would be a big advantage, as we could request a > receipt for every fragment seperately then. >=20 Clarification: otrl_message_fragment_and_send does return either the first or the last or no fragment, and sends all the others. It does not split the message into multiple fragments and returns all of them. The opdata thing would work, although the opdata is being abused for quite a lot of stuff in gajim-otr currently, but that's not really a problem in python (dictionaries, wooohoo!). We would need to rely on libotr not using threads when calling the callbacks, so that the opdata actually contains all the msgids when the libotr call (ie. message_fragment_and_send) finished. Gajim would have to be able to process multiple msgids and not only one, because eg. in XEP-0184 it would not be enough to know that the recipient received *one* fragment. --=-DrHXXXuP7h+HhwWbnIoa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIWVleNjvKGrx0tZgRAroCAJ9yCTsusV0IaaCGbH7Pb9L3SKRGjQCdHxj5 hOo68b9WJ+SbQZyUSQtvXM0= =J/ud -----END PGP SIGNATURE----- --=-DrHXXXuP7h+HhwWbnIoa-- From a.sporto+bee@gmail.com Wed Jun 18 23:24:23 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Wed, 18 Jun 2008 22:24:23 +0000 (UTC) Subject: [OTR-dev] Re: Requirements for libotr4 References: Message-ID: Hi, On 2008-06-18, Willy Lew wrote: > ------=_Part_3121_10507133.1213753314536 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hello fellow IM devs, > > As some of you may already know, we are revamping the libotr API (the > messaging part in particular) to address several issues that were brought up > recently. The four major changes are: I'd like to mention some things I wished for when implementing irssi-otr (irssi is an IRC client often used in conjunction with the IM-to-IRC-gateway bitlbee). I believe all those points are also interesting for other IM-clients. 1. Asynchronous key generation. On some systems key generation can take more than one hour. I don't know how other IM-clients do it but I had to create a seperate process (not thread) for key generation which is really not ideal since inter-thread communication is a lot simpler. Also key generation will just finish at some random point in time and update the keys file. What I would like to have is one thread safe function that generates a key (some opaque struct I don't care about) which I can later on(in my main thread) give to libotr for inclusion. 2. No hardcoded strings at all. I don't know if your point about error codes covers the case "The following message ... was not encrypted: [...]". Here one would need an error code plus the message that was received. 3. [resent] messages. They should be handled in the same way as the msgs I mentioned in 2., OTR shouldnt change messages at all and most certainly not inject a hardcoded "[resent]" string. 4. The 3 line spanning OTR announce message, ironically also called "better message" in the code. This is again a hardcoded string I would like to see disappear. The really really bad thing about it is that it is a 3 line message and in IRC we don't have newlines. So in order to eat this message up and not present it to the user I had to hardcode the second and third line in irssi-otr. Bad! 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see disappear. Because of it, it is impossible to transfer OTR conversations over OTR...and also complicated to talk about OTR in an OTR session...I always find myself writing "if you wanna restart OTR write OTR....". A function otr_restart would be the right thing here I believe. 6. SMP handling. Ian said this would be reworked but it's missing in the 4 points below. E.g. applications really shouldnt mess around with variables that libotr touches as well (smstate->nextExpected). 7. Maximum message size handshake. Currently, each end uses its own MMS. This is a bad thing if you use something like jabber transports because the jabber end will likely have a too large MMS for the other end (ICQ,...). For irssi-otr it's always a problem in conjunction with bitlbee since IRC has a limit of about 500 and the other end might be playing with 2k. The only reason why this currently works at all is because OTR messages (except the 'better' msg under 4.) start with "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. The solution is simple: Each end advertises its own MSS during the initial handshake and both use the minimum of the two. Thanks, Uli > > *** 1. Hardcoded strings *** > No more hardcoded HTML error strings! We are adding a new function in > OtrlMessageAppOps to let the IM handle the error according to an error code. > For instance, OtrlMessageAppOps will look like this: > > typedef struct s_OtrlMessageAppOps { > OtrlPolicy (*policy)(void *opdata, ConnContext *context); > ... > void (*account_name_free)(void *opdata, const char *account_name); > > /* Handles an error given the error code */ > void (*handle_error)(void *opdata, ConnContext *context, OtrlErrorCode > error_code); > } OtrlMessageAppOps; > > > Tentatively, we will provide a convenient errorcode-to-errorstring lookup > function that will look like this: > > const char * otrl_message_errstr_en(OtrlErrorCode error_code); > > > *** 2. Custom message stripping function *** > otrl_message_sending and otrl_message_receiving will be having an extra > optional argument (a callback function) to give the IMs the flexibility to > strip/convert the messages that are sent/received. For example, the > conversion function could strip the HTML tags out of the original message in > order to be guaranteed an HTML-free message. > > gcry_error_t otrl_message_sending(OtrlUserState us, > const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *recipient, const char *message, OtrlTLV *tlvs, > char **messagep, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata); > > int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *sender, const char *message, char **newmessagep, > OtrlTLV **tlvsp, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata); > > *** 3. Fragmentation *** > We are adding a new argument (OtrlFragmentPolicy) to otrl_message_sending so > that the fragmentation task is done without manually calling > otrl_message_fragment_and_send. If the original messaging behaviour is > preferred, the OtrlFragmentPolicy can be OTRL_FRAGMENT_DONTFRAGMENT. The new > signature for otrl_message_sending (including the conversion function as > described above) will look like this: > > > gcry_error_t otrl_message_sending(OtrlUserState us, > const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *recipient, const char *message, OtrlTLV *tlvs, > char **messagep, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata, > OtrlFragmentPolicy fragPolicy); > > > Since we will not need to call otrl_message_fragment_and_send anymore, we > are planning to remove that function from the public API. > > *** 4. Stripping ConnContext *** > We are stripping down ConnContext so that it only exposes the members that > are meant to be public. It will look like this: > > typedef struct context { > char * username; > char * accountname; > char * protocol; > OtrlMessageState msgstate; > OtrlAuthInfo auth; > Fingerprint fingerprint_root; > Fingerprint *active_fingerprint; > unsigned int protocol_version; > void *app_data; > void (*app_data_free)(void *); > OtrlSMState *smstate; > > ConnContextInternal *internal_context; > } ConnContext; > > > > At the end of this email you will find a list of APIs that will be kept > public. I have made that list by going through the code of a few IMs that > use OTR and by recording their respective otrl_* calls. If I have missed > anything in that list or if you have any other concerns/issues, please let > me know asap since I am in the process of gathering the requirements for the > new API. Note that we are also fixing the multiple login problem and this > entails a few other changes to the API but those have not been finalized > yet. > > Cheers! > - willy > > > *** List of APIs to be kept in libotr4 *** > otrl_context_disconnect > otrl_context_find > otrl_context_find_fingerprint > otrl_context_forget_all > otrl_context_forget_fingerprint > otrl_context_set_trust > > otrl_message_abort_smp > otrl_message_disconnect > otrl_message_free > otrl_message_initiate_smp > otrl_message_initiate_smp_q > otrl_message_receiving > otrl_message_respond_smp > otrl_message_sending > > otrl_privkey_fingerprint > otrl_privkey_forget_all > otrl_privkey_generate > otrl_privkey_generate_FILEp > otrl_privkey_hash_to_human > otrl_privkey_read > otrl_privkey_read_FILEp > otrl_privkey_read_fingerprints > otrl_privkey_read_fingerprints_FILEp > otrl_privkey_write_fingerprints > otrl_privkey_write_fingerprints_FILEp > > otrl_proto_default_query_msg > otrl_proto_message_type > > otrl_tlv_find > otrl_tlv_free > > otrl_userstate_create > otrl_userstate_free From fnord@pentabarf.de Thu Jun 19 12:22:53 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Thu, 19 Jun 2008 13:22:53 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <1213874573.7202.22.camel@hegg> --=-GuuE5ToIrJg/sxRzeHhq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > 2. No hardcoded strings at all. I don't know if your point about error > codes covers the case "The following message ... was not encrypted: > [...]". Here one would need an error code plus the message that was > received. >=20 -snip- >=20 > 4. The 3 line spanning OTR announce message, ironically also called > "better message" in the code. This is again a hardcoded string I would > like to see disappear. The really really bad thing about it is that it > is a 3 line message and in IRC we don't have newlines. So in order to > eat this message up and not present it to the user I had to hardcode > the second and third line in irssi-otr. Bad! >=20 4. should be part of 2. It would be best if we had an additional function in OtrlMessageAppOps that is used for translating codes to any human-readable string that may occur in the whole lib, which will then be used by the lib, eg. passed to notify() or similar. > 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > disappear. Because of it, it is impossible to transfer OTR > conversations over OTR...and also complicated to talk about OTR in an > OTR session...I always find myself writing "if you wanna restart OTR > write OTR....". A function otr_restart would be the > right thing here I believe. This will probably complicated: we need something that the lib can use to identify it's messages, and since we don't know what kind of protocol will be used, it's hard to find some sort of tag that a.) is protocol independent (an additional stanza in XMPP will not work on OSCAR/IRC/whatever) b.) will never interfere with messages manually written by the user > 6. SMP handling. Ian said this would be reworked but it's missing in > the 4 points below. E.g. applications really shouldnt mess around with > variables that libotr touches as well (smstate->nextExpected). IMO SMP should just call a callback (or return a TLV or similar which can be identified by the client) from otlr_message_receiving for a SMP request (on TLV_SMP1*), abort (something went wrong, like SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The implementation can then check the SMProgState and display the results. > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. Sounds like a good thing to me. If I read that correctly it wouldn't even need work from the clients, the lib can do this on it's own. > > *** 2. Custom message stripping function *** > > otrl_message_sending and otrl_message_receiving will be having an > extra > > optional argument (a callback function) to give the IMs the > flexibility to > > strip/convert the messages that are sent/received. For example, the > > conversion function could strip the HTML tags out of the original > message in > > order to be guaranteed an HTML-free message. I don't think the receiver should remove HTML from the message. What if I want to send a HTML-snippet to my friend using jabber? Currently, pidgin would escape the HTML tags to < and >, and proper clients would display those entities in plaintext, which is very bad. If we would implement a stripping method on the receiving side, they would change that back to < and >, but they would also strip anything which was initially in < and >. So if a proper client sends HTML tags (in plaintext, not intended to be formatted!) to another proper client, they would strip the HTML tags, which is even worse. The right thing to do here would be to make the sender send information about what kind of message it is (maybe using MIME-Types or whatever, so they would send text/html or text/plain or text/x-aolrtf) and to make the receiver convert them to the right format. So that means: purple-client sends text/html to gajim: gajim would convert this to text/plain gajim sends text/plain to another gajim: no conversion necessary. Thanks, Kjell --=-GuuE5ToIrJg/sxRzeHhq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIWkGNNjvKGrx0tZgRAocQAJ9c8f6eWoRIrtgSiV4907sVbYUkPQCffjvG r6lm/m+0b82W7JjhbFw7mUc= =u+h5 -----END PGP SIGNATURE----- --=-GuuE5ToIrJg/sxRzeHhq-- From ian@cypherpunks.ca Thu Jun 19 14:17:58 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 09:17:58 -0400 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <20070220111018.GB19501@yoink.cs.uwaterloo.ca> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> <45DA6C3D.6040001@gmail.com> <20070220111018.GB19501@yoink.cs.uwaterloo.ca> Message-ID: <20080619131758.GG26418@thunk.cs.uwaterloo.ca> On Tue, Feb 20, 2007 at 06:10:18AM -0500, Ian Goldberg wrote: > On Mon, Feb 19, 2007 at 08:34:21PM -0700, Berg, Michael wrote: > > > > Steve Langasek wrote: > > > Well, this problem indeed doesn't seem to be reproducible on i386 or amd64 > > > when not using nss_ldap. Given that users of other gnutls- or gcrypt-using > > > packages aren't reporting similar problems, it seems likely that this is a > > > bug in gaim-otr or libotr, but I don't think it's one that should block the > > > package from being released; it is generally usable, just not in certain > > > system configurations. > > > > Yeah, I do have a system configuration that you don't run across every day ;-) > > > > > > Ian Goldberg wrote: > > > Is it reproducible on other systems that *do* use nss_ldap? Can you > > > turn nss_ldsp on on one of those other systems you tested, and try > > > again? > > > > I did a clean install of Debian unstable onto a x86 (32-bit) laptop, tested > > gaim with and without gaim-otr installed. gaim and gaim+otr both worked > > properly. > > > > Then I installed libnss-ldap and libpam-ldap and configured them for my > > network setup. gaim (without otr) worked, but gaim+otr had the same errors > > as I reported for my amd64 system (and the 32-bit chroot I also tested > > there). So I can duplicate the bug when nss_ldap is in use. > > > > Valgrind output is attached for the following 4 test cases: > > 1) gaim (without otr or nss_ldap): gaim.9110.gz > > 2) gaim+otr (without nss_ldap): gaim+otr.9180.gz > > 3) gaim with nss_ldap in use: gaim+ldap.10134.gz > > 4) gaim+otr with nss_ldap in use: gaim+otr+ldap.10038.gz > > > > Unfortunately, all of these valgrind runs on that x86 laptop have a TON of > > ===== > > Conditional jump or move depends on uninitialised value(s) > > at 0x5C55DC7: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C56243: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C56471: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C566D8: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C445C4: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C44721: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5B9B7C2: (within /usr/lib/libnss3.so.0d) > > by 0x5B9B8C2: (within /usr/lib/libnss3.so.0d) > > by 0x5BA4133: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > > by 0x5BA428A: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > > by 0x5B8342D: (within /usr/lib/libnss3.so.0d) > > ===== > > that occur in each capture. > > I didn't see these on the amd64 system or the x86 chroot I set up on that > > system. Do you guys get pages and pages of that output when you run > > valgrind on gaim on a 32-bit x86 system? If not, I'll try to figure out > > what's causing it on that freshly installed laptop. > > OK, I think I see the problem. libldap_r.so.2.0.130 and gaim-otr both > use libgcrypt. libgcrypt has a well-known problem that it can't be > used as a shared library by more than one client in the same program. > This is because it uses global variables that the two clients (gaim-otr > and libldap) both need to use in different ways. We also see this > problem, for example, if you try to use gaim-otr and another encrypting > plugin that uses libgcrypt. > > One solution would be to statically link libgcrypt into gaim-otr (so it > gets its own copies of global data). Can one of the Debian people try > to build a package like that? > > A better solution, of course, would be to make libgcrypt > sharing-friendly. This had been discussed on libgcrypt's mailing list > a while back, but I don't know what, if anything, became of it. Has this been resolved in the debian package? The upstream source has a "Makefile.static" that statically links libgcrypt into pidgin-otr.so. [D'oh. The version of Makefile.static in the 3.2.0 release forgot to link in the new tooltipmenu.o file. It's fixed in cvs.] - Ian From a.sporto+bee@gmail.com Thu Jun 19 16:04:15 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Thu, 19 Jun 2008 15:04:15 +0000 (UTC) Subject: [OTR-dev] Re: Requirements for libotr4 References: <1213874573.7202.22.camel@hegg> Message-ID: On 2008-06-19, Kjell Braden wrote: -snip- >> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see >> disappear. Because of it, it is impossible to transfer OTR >> conversations over OTR...and also complicated to talk about OTR in an >> OTR session...I always find myself writing "if you wanna restart OTR >> write OTR....". A function otr_restart would be the >> right thing here I believe. > > This will probably complicated: we need something that the lib can use > to identify it's messages, and since we don't know what kind of protocol > will be used, it's hard to find some sort of tag that > a.) is protocol independent (an additional stanza in XMPP will not > work on OSCAR/IRC/whatever) > b.) will never interfere with messages manually written by the user As far as I can tell ?OTR? is used for two different things: 1. OTR initiation. I agree that you need something like ?OTR? here. 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation which I think is totally unneccessary. Here you could easily use a protocol internal message to restart OTR. That way anything can be transmitted over OTR, including OTR. One would only have to add a function otr_restart() to the library. >> 6. SMP handling. Ian said this would be reworked but it's missing in >> the 4 points below. E.g. applications really shouldnt mess around with >> variables that libotr touches as well (smstate->nextExpected). > > IMO SMP should just call a callback (or return a TLV or similar which > can be identified by the client) from otlr_message_receiving for a SMP > request (on TLV_SMP1*), abort (something went wrong, like > SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The > implementation can then check the SMProgState and display the results. Sounds good to me. >> 7. Maximum message size handshake. Currently, each end uses its own >> MMS. This is a bad thing if you use something like jabber transports >> because the jabber end will likely have a too large MMS for the other >> end (ICQ,...). For irssi-otr it's always a problem in conjunction with >> bitlbee since IRC has a limit of about 500 and the other end might be >> playing with 2k. The only reason why this currently works at all is >> because OTR messages (except the 'better' msg under 4.) start with >> "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. >> The solution is simple: Each end advertises its own MSS during the >> initial handshake and both use the minimum of the two. > > Sounds like a good thing to me. If I read that correctly it wouldn't > even need work from the clients, the lib can do this on it's own. yes, that's what I thought. >> > *** 2. Custom message stripping function *** - snip - About that whole HTML discussion and also concerning previous discussions about character encodings: I simply think it is not OTRs business, hence functions such as HTML stripping should - if at all - only be there for convenience. I hope you don't mind if I refer to the OSI reference model, but in that sense OTR is on the transport or maybe the session layer. The presentation layer (which is above the session layer) or if absent the application layer takes care of stuff like character encodings and...well...presentation as in text/plain or text/html. To provide an analogy, you wouldn't want TCP to do character set conversion or html stripping for you either because TCP doesnt care and I believe OTR shouldn't care either what people are transferring. For OTR it should be the same as for TCP: Deliver some octets from A to B, no matter what it is. If you try to do anything else you'll run into the problems such as those Kjell describes below. Thanks, Uli >> > otrl_message_sending and otrl_message_receiving will be having an >> extra >> > optional argument (a callback function) to give the IMs the >> flexibility to >> > strip/convert the messages that are sent/received. For example, the >> > conversion function could strip the HTML tags out of the original >> message in >> > order to be guaranteed an HTML-free message. > > I don't think the receiver should remove HTML from the message. What if > I want to send a HTML-snippet to my friend using jabber? Currently, > pidgin would escape the HTML tags to < and >, and proper clients > would display those entities in plaintext, which is very bad. If we > would implement a stripping method on the receiving side, they would > change that back to < and >, but they would also strip anything which > was initially in < and >. So if a proper client sends HTML tags (in > plaintext, not intended to be formatted!) to another proper client, they > would strip the HTML tags, which is even worse. > The right thing to do here would be to make the sender send information > about what kind of message it is (maybe using MIME-Types or whatever, so > they would send text/html or text/plain or text/x-aolrtf) and to make > the receiver convert them to the right format. > > So that means: > purple-client sends text/html to gajim: gajim would convert this to > text/plain > gajim sends text/plain to another gajim: no conversion necessary. > > > Thanks, > Kjell > > --=-GuuE5ToIrJg/sxRzeHhq > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > > --=-GuuE5ToIrJg/sxRzeHhq-- From js-otrim@webkeks.org Thu Jun 19 16:09:08 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 17:09:08 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <20080619170908.417dbde4@webkeks.org> --Sig_/6Cv7h6gS/lthvjlO51Bnf.N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Uli M wrote: > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. This has one problem: What if two users chat via ICQ for example and both use a Jabber transport? Both would announce that they don't need fragmentation, but they do. We would need some way to define what we support *PER CONTACT*. So the client could for example limit it's own capability if it knows it's a gateway contact and announce that it needs fragmentation. --=20 Jonathan --Sig_/6Cv7h6gS/lthvjlO51Bnf.N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIWnaYAAoJEMtRg9d5cXHkR4sP/A/QMuhx3EeIBCo1Oh8TMBcI ClVsOV5O+t2e1PCafuua8XA9jdc5ZKhTxf8uhePJx2jeboTjG+fZJjwAxoFY1bvF ppVxetWAq9Lv10iatouZAFazOdPr+TQqz/P/XFXCAP2yrjh+VrTMpFvnN3YfqooH GMMSsxTiWJlweP7XN8T/Zmb6NH01zg6jhKCIKcReT7D5s7tA4ym28Rie9EbrmsPN ZY87VEwSqHeCPSpv4zGC6wgnpucP+Ea/1my7WBsEhsmc+AYIb/8WtQ2J/IiI1Lvq 376F7Aw+RSFYdrRjtbvxEn+rqfznt+ttk2SpKtacJojVRqndb313dWKR9L1a1YbN YQzFko3a0+sm6o/RKArNLcNnhjLJfaxnX40JclyLwtuYVaN7oHQuruxyF8q//s6b xFuf+r6T2f6Bj4JY3hblogEdjWegYh/pdG0H3vKi1iQPcQb5oJ4N7rqb0hijx8Zc +nySMqLsb7Qs6183/2/TMgg/nPbTRnIJo3tvBYmbC2LPfK/swfvtE2Lbz+n/UidH nk6qWFll7YmvB+TIQwhUtreYqd2EpcMavJEWFXET59rf5MbhQh/7pZbochjqoL6t fWqhx2HufQ3F2H1p/vybPzS+MR5G0MmTf14/JDLKGtZiWAwpLweyx1ZRF9bxbQej NPVnee28knPTfEK1Rw5i =Tfdo -----END PGP SIGNATURE----- --Sig_/6Cv7h6gS/lthvjlO51Bnf.N-- From js-otrim@webkeks.org Thu Jun 19 16:12:38 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 17:12:38 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213874573.7202.22.camel@hegg> References: <1213874573.7202.22.camel@hegg> Message-ID: <20080619171238.1da0fbfd@webkeks.org> --Sig_/YR/YFena_6rVuMPxoUArjzv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kjell Braden wrote: > I don't think the receiver should remove HTML from the message. What > if I want to send a HTML-snippet to my friend using jabber? Currently, > pidgin would escape the HTML tags to < and >, and proper clients > would display those entities in plaintext, which is very bad. If we > would implement a stripping method on the receiving side, they would > change that back to < and >, but they would also strip anything which > was initially in < and >. So if a proper client sends HTML tags (in > plaintext, not intended to be formatted!) to another proper client, > they would strip the HTML tags, which is even worse. Ian already said that the client can specify if it's want HTML or not on sending and receiving. So if a non-HTML client gives a message to libotr, libotr will escape it and on receiving, a non-HTML client will get an unescaped message from libotr. > The right thing to do here would be to make the sender send > information about what kind of message it is (maybe using MIME-Types > or whatever, so they would send text/html or text/plain or > text/x-aolrtf) and to make the receiver convert them to the right > format. The client would still need to handle HTML stripping then - with Ian's proposal, the client would just specify it it supports HTML or not and libotr will do all the rest. Oh, btw: text/x-aolrtf died - finally! It's not supported anymore since ICQ 6. IMO a very good thing. --=20 Jonathan --Sig_/YR/YFena_6rVuMPxoUArjzv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIWndpAAoJEMtRg9d5cXHkascQAJKEmzvc7H+FgClL3DZxahCU Q4s9M0wuGizxNz8AZeVQ2plSNUYTFPDO+BOo36RPGX9zkHkqnBDL3/N/5xzKjq8t qHCyCCeL2GDKBfKcjSKYrr7yBdNfuSSiyF5KmSYudqB4+bCxmLrjeFHQLOdTbzT/ ljm0NC4PEhMZwezpqa7E478ND6TD2C0EkGZaSuye35GPTH5E/kHeu4NU3iMia111 Btcf5B0th+GFnsfqevUCbKsHRHLJskUuFRNDAjX/B6nBNHx2PzNdt6OZ6gB9+ELj LDEviCQN51kmCgXe8aw3rnlslT0JrxK5c95Kkxe+IYm3a7OvEeaQBdgbXNIizwco K7rytvqk+2JWLjBWSCgECW5gBRc4Rp/cfFqMADu/+quV4RjSHNrZQxOhcqDv+O14 07IQ3SYDMvZqLocXs8Li70tCXJmjrzbETgUF+7pHhRxvJEcAw09VwaEAI8y+kq/q Z3yGMaLbclCfMM63x5GoU3SFm0C3JYU8+mLPcSEYkFQNzOvQHz7q8tosJjYIFLkg Abomy5z9kYlOag8Lp1oD8NFQ6x/bmOedtoxnJ6S/1IYY0nzWogC49dyIytu2u2O7 OGEmvXEh1M7TFYdDypzOaX9Jq7jUkuWX9C3HWoxNpglyfpQahKjq5bD1QRB/5Oci drKuBDxcduHIfG6e8T9E =BW3t -----END PGP SIGNATURE----- --Sig_/YR/YFena_6rVuMPxoUArjzv-- From paul@cypherpunks.ca Thu Jun 19 16:23:26 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Thu, 19 Jun 2008 11:23:26 -0400 (EDT) Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <1213874573.7202.22.camel@hegg> Message-ID: > As far as I can tell ?OTR? is used for two different things: > > 1. OTR initiation. I agree that you need something like ?OTR? here. > 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation > which I think is totally unneccessary. Here you could easily use a > protocol internal message to restart OTR. That way anything can be > transmitted over OTR, including OTR. One would only have to add a > function otr_restart() to the library. Some clients or servers prepend garbage to your message, so the client also needs to be able to trigger on ?OTR? within the message, as aposed to only at the start of the message. Paul From fnord@pentabarf.de Thu Jun 19 16:26:18 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Thu, 19 Jun 2008 17:26:18 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619170908.417dbde4@webkeks.org> References: <20080619170908.417dbde4@webkeks.org> Message-ID: <1213889178.6456.11.camel@hegg> --=-rZcekymdzqNcLPHn8W+I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > This has one problem: What if two users chat via ICQ for example and > both use a Jabber transport? Both would announce that they don't need > fragmentation, but they do.=20 This does not in any way conflict with what Uli suggested before. Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, but chats with Alice using the transport) answers with the same value and the lib saves that value in the context on both sides. The only necessary change would be that the max_message_size Op would need the context or the accountname, username and protocol for that contact. On Do, 2008-06-19 at 17:12 +0200, Jonathan Schleifer wrote: > Ian already said that the client can specify if it's want HTML or not > on sending and receiving. So if a non-HTML client gives a message to > libotr, libotr will escape it and on receiving, a non-HTML client will > get an unescaped message from libotr. That doesn't seem to be what the initial post on this thread says: a conversion callback passed to the message_{sending,receiving} functions. > > The right thing to do here would be to make the sender send > > information about what kind of message it is (maybe using MIME-Types > > or whatever, so they would send text/html or text/plain or > > text/x-aolrtf) and to make the receiver convert them to the right > > format. >=20 > The client would still need to handle HTML stripping then - with Ian's > proposal, the client would just specify it it supports HTML or not and > libotr will do all the rest. >=20 Let me clarify my proposal: The sending *client* (ie. user of libotr) passes the type to otrl_message_sending, the message and the type gets sent to the receiver, the receiving client passes it's requested type to otrl_message_receiving and otrl_message_receiving calls *something* (libotr internal would mean that it's not very flexible, a callback would mean that the implementing client would have to be *very* flexible) that converts the message to the requested type. --=-rZcekymdzqNcLPHn8W+I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIWnqaNjvKGrx0tZgRAoyWAJ4kjrIhKxkU9Bgp3qIYiT7GbpaiAgCeIPMg ccv4K6QvA4cGefCgSPSe0tY= =PpqZ -----END PGP SIGNATURE----- --=-rZcekymdzqNcLPHn8W+I-- From ian@cypherpunks.ca Thu Jun 19 19:37:38 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 14:37:38 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote: > Hi, > > On 2008-06-18, Willy Lew > wrote: > > ------=_Part_3121_10507133.1213753314536 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > Hello fellow IM devs, > > > > As some of you may already know, we are revamping the libotr API (the > > messaging part in particular) to address several issues that were brought up > > recently. The four major changes are: > > I'd like to mention some things I wished for when implementing > irssi-otr (irssi is an IRC client often used in conjunction with the > IM-to-IRC-gateway bitlbee). I believe all those points are also > interesting for other IM-clients. > > 1. Asynchronous key generation. On some systems key generation can > take more than one hour. I don't know how other IM-clients do it but I > had to create a seperate process (not thread) for key generation which > is really not ideal since inter-thread communication is a lot simpler. > Also key generation will just finish at some random point in time and > update the keys file. What I would like to have is one thread safe > function that generates a key (some opaque struct I don't care about) > which I can later on(in my main thread) give to libotr for inclusion. OK, that's an interesting request. I think we can do that. Willy, write that down. ;-) I don't want to put anything thready into libotr, but we can have a call like: gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void (*call_when_done)(void *newkey, void *data), void *data); which (after some time) will call call_when_done with a pointer to the new key and whatever data you passed in. Then there can be: gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); which writes the newkey into the FILE (and frees newkey). Your call_when_done routine can call that directly if you're single-threaded, or signal the main thread that it's ready, or whatever. What do you think of that? > 2. No hardcoded strings at all. I don't know if your point about error > codes covers the case "The following message ... was not encrypted: > [...]". Here one would need an error code plus the message that was > received. > > 3. [resent] messages. They should be handled in the same way as the > msgs I mentioned in 2., OTR shouldnt change messages at all and most > certainly not inject a hardcoded "[resent]" string. Agreed on both counts. The appropriate handler routine will in fact need to take some extra params, as you point out. > 4. The 3 line spanning OTR announce message, ironically also called > "better message" in the code. This is again a hardcoded string I would > like to see disappear. The really really bad thing about it is that it > is a 3 line message and in IRC we don't have newlines. So in order to > eat this message up and not present it to the user I had to hardcode > the second and third line in irssi-otr. Bad! We want to display *something* to the other user if he doesn't have OTR installed, though. Are you suggesting each IM client can provide its own text here? That would be OK, I suppose. We'd need another OtrlMessageUiOps callback for that. > 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > disappear. Because of it, it is impossible to transfer OTR > conversations over OTR...and also complicated to talk about OTR in an > OTR session...I always find myself writing "if you wanna restart OTR > write OTR....". A function otr_restart would be the > right thing here I believe. I'll address this downthread. > 6. SMP handling. Ian said this would be reworked but it's missing in > the 4 points below. E.g. applications really shouldnt mess around with > variables that libotr touches as well (smstate->nextExpected). Oh, right. Yes, this will also be cleaned up. > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. Downthread as well. - Ian From ian@cypherpunks.ca Thu Jun 19 20:14:30 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 15:14:30 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <1213874573.7202.22.camel@hegg> Message-ID: <20080619191430.GX26418@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 03:04:15PM +0000, Uli M wrote: > On 2008-06-19, Kjell Braden wrote: > -snip- > >> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > >> disappear. Because of it, it is impossible to transfer OTR > >> conversations over OTR...and also complicated to talk about OTR in an > >> OTR session...I always find myself writing "if you wanna restart OTR > >> write OTR....". A function otr_restart would be the > >> right thing here I believe. > > > > This will probably complicated: we need something that the lib can use > > to identify it's messages, and since we don't know what kind of protocol > > will be used, it's hard to find some sort of tag that > > a.) is protocol independent (an additional stanza in XMPP will not > > work on OSCAR/IRC/whatever) > > b.) will never interfere with messages manually written by the user > > As far as I can tell ?OTR? is used for two different things: > > 1. OTR initiation. I agree that you need something like ?OTR? here. Definitely. > 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation > which I think is totally unneccessary. Here you could easily use a > protocol internal message to restart OTR. That way anything can be > transmitted over OTR, including OTR. One would only have to add a > function otr_restart() to the library. The latter is already there (it's what pidgin-otr does when you click "Refresh private conversation" for example). The reason libotr treats a typed "?OTR?" as an signal to start/refresh the private conversation is that for some clients (iChat?) that may be the only way to do it. There may be no UI in the client itself to control OTR. But I suppose we could make it an option. If you've got OTR support in your UI, let libotr know that, and it will treat a typed "?OTR?" just as any other 5 chars. [And maybe an option to treat "?OTR?" as the start-OTR command if you're not currently encrypted, but as regular text if you are, hmm.] - Ian From ian@cypherpunks.ca Thu Jun 19 20:32:50 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 15:32:50 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213889178.6456.11.camel@hegg> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> Message-ID: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 05:26:18PM +0200, Kjell Braden wrote: > On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > > This has one problem: What if two users chat via ICQ for example and > > both use a Jabber transport? Both would announce that they don't need > > fragmentation, but they do. > > This does not in any way conflict with what Uli suggested before. > > Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) > that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, > but chats with Alice using the transport) answers with the same value > and the lib saves that value in the context on both sides. The only > necessary change would be that the max_message_size Op would need the > context or the accountname, username and protocol for that contact. I'm not too familiar with this concept of transporting ICQ within XMPP. Right now, clients can tell libotr what their MMS is for any given conversation. You're saying that the client might not know, because he's speaking XMPP to a gateway which converts it to ICQ? What happens if the gateway gets a message that's too big? In general, determining the MSS is highly non-trivial. > > The client would still need to handle HTML stripping then - with Ian's > > proposal, the client would just specify it it supports HTML or not and > > libotr will do all the rest. > > > Let me clarify my proposal: > The sending *client* (ie. user of libotr) passes the type to > otrl_message_sending, the message and the type gets sent to the > receiver, the receiving client passes it's requested type to > otrl_message_receiving and otrl_message_receiving calls *something* > (libotr internal would mean that it's not very flexible, a callback > would mean that the implementing client would have to be *very* > flexible) that converts the message to the requested type. My proposal was made exactly to solve that (very inflexible) vs (forcing clients to be too flexible) problem. What I proposed is that clients tell libotr what the content-type of the message is (for sending) and what they would like out (for receiving). If it's not a standard type, the client needs to provide converter functions (as Willy wrote), but only to and from one fixed, common type: UTF-8 text/xhtml. That way, anyone can talk to anyone, and if client X supports some weird markup method or character encoding, only it has to know about it, and only it needs to write the converters to/from UTF-8 text/xhtml. I think this gives exactly the right amount of flexibility: the library is flexible, because it can support anything, and the application doesn't have to be ridiculously flexible and accept every possible format. I explained my reasoning in this message: http://www.cypherpunks.ca/pipermail/otr-dev/2008-May/000772.html Does this clarify my thinking? Your proposal is #2 in the above-referenced message, and I explain there why I think #1 is better. But API-wise, it's indeed just what you suggest: pass the type you have/want into otrl_message_sending/receiving, and libotr will do the conversion for you. - Ian From stpeter@stpeter.im Thu Jun 19 20:41:32 2008 From: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 19 Jun 2008 13:41:32 -0600 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> <20080619193250.GY26418@thunk.cs.uwaterloo.ca> Message-ID: <485AB66C.7040709@stpeter.im> This is a cryptographically signed message in MIME format. --------------ms020303060409020306010903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/19/2008 1:32 PM, Ian Goldberg wrote: > On Thu, Jun 19, 2008 at 05:26:18PM +0200, Kjell Braden wrote: >> On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: >>> This has one problem: What if two users chat via ICQ for example and >>> both use a Jabber transport? Both would announce that they don't need >>> fragmentation, but they do. >> This does not in any way conflict with what Uli suggested before. >> >> Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) >> that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, >> but chats with Alice using the transport) answers with the same value >> and the lib saves that value in the context on both sides. The only >> necessary change would be that the max_message_size Op would need the >> context or the accountname, username and protocol for that contact. > > I'm not too familiar with this concept of transporting ICQ within XMPP. Strictly speaking, it's not ICQ-in-XMPP, it's ICQ on one side of the wormhole ^H^H^H gateway and XMPP on the other side. > Right now, clients can tell libotr what their MMS is for any given > conversation. You're saying that the client might not know, because > he's speaking XMPP to a gateway which converts it to ICQ? What happens > if the gateway gets a message that's too big? It probably returns an error. If you're lucky. > In general, determining the MSS is highly non-trivial. > >>> The client would still need to handle HTML stripping then - with Ian's >>> proposal, the client would just specify it it supports HTML or not and >>> libotr will do all the rest. >>> >> Let me clarify my proposal: >> The sending *client* (ie. user of libotr) passes the type to >> otrl_message_sending, the message and the type gets sent to the >> receiver, the receiving client passes it's requested type to >> otrl_message_receiving and otrl_message_receiving calls *something* >> (libotr internal would mean that it's not very flexible, a callback >> would mean that the implementing client would have to be *very* >> flexible) that converts the message to the requested type. > > My proposal was made exactly to solve that (very inflexible) vs (forcing > clients to be too flexible) problem. What I proposed is that clients > tell libotr what the content-type of the message is (for sending) and > what they would like out (for receiving). If it's not a standard type, > the client needs to provide converter functions (as Willy wrote), but > only to and from one fixed, common type: UTF-8 text/xhtml. > > That way, anyone can talk to anyone, and if client X supports some weird > markup method or character encoding, only it has to know about it, and > only it needs to write the converters to/from UTF-8 text/xhtml. > > I think this gives exactly the right amount of flexibility: the library > is flexible, because it can support anything, and the application > doesn't have to be ridiculously flexible and accept every possible > format. > > I explained my reasoning in this message: > > http://www.cypherpunks.ca/pipermail/otr-dev/2008-May/000772.html +1 to UTF-8 -- we've been using it in Jabber since 1999. Will you support a subset of XHTML, or the whole thing? For XMPP we defined a subset: http://www.xmpp.org/extensions/xep-0071.html (Basically, no , scripts, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020303060409020306010903 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTkxOTQxMzJaMCMGCSqG SIb3DQEJBDEWBBQOETPrgBWQX0ftvlc4aShoMC2lITBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQCuSLsViXclXaSJeQ6k8sJGPbQbWkauc++sYgsX8JiKLmZvPihb/ee8QGlMjNZrpebF4s9b 4MFxz5GwOF+W/L0F2gGpue8ZrkMpYEtATV36V4rNHo0pHAPm9mITvOuCHTD6hDVWm7kNR0lw aGYYE9yKTIReuFq/RSjTZkAUgMVBZfFbPAOmr9P5godMk8V3BMUcin1HlwNKgKeQlCHA3Xox Dg4rfxdzlMvITMl6FeKTkw3OkS/dpZQLw/dWnnJcAA+1Fh9iVe4Yb/LtntyG1eEsNLW+OW3r zYijCe4DUWU7bERGEjyECB3dyu2Abz3mwYUsZub2uP/4NMO0/JKKAXl5AAAAAAAA --------------ms020303060409020306010903-- From js-otrim@webkeks.org Thu Jun 19 21:42:46 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 22:42:46 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> <20080619193250.GY26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619224246.63b6c71c@webkeks.org> Ian Goldberg wrote: > I'm not too familiar with this concept of transporting ICQ within > XMPP. > > Right now, clients can tell libotr what their MMS is for any given > conversation. You're saying that the client might not know, because > he's speaking XMPP to a gateway which converts it to ICQ? What > happens if the gateway gets a message that's too big? > > In general, determining the MSS is highly non-trivial. The client *DOES* now the maximium MMS, so if it's per-conversation, it works. If a message is too long, it's silently dropped by the ICQ gateway. This is really bad behaviour anyway, but all gateways seem to handle it like this. The max. MSS seems to be really small on ICQ without direct connections. And I don't know of any ICQ gateway taht uses direct connections. -- Jonathan From a.sporto+bee@gmail.com Thu Jun 19 21:43:35 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Thu, 19 Jun 2008 20:43:35 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619191430.GX26418@thunk.cs.uwaterloo.ca> References: <1213874573.7202.22.camel@hegg> <20080619191430.GX26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619204341.GA8251@nets.rwth-aachen.de> On Thu 19.06.08 15:14, Ian Goldberg wrote: - snip - > But I suppose we could make it an option. If you've got OTR support in > your UI, let libotr know that, and it will treat a typed "?OTR?" just as > any other 5 chars. [And maybe an option to treat "?OTR?" as the > start-OTR command if you're not currently encrypted, but as regular text > if you are, hmm.] Yeah, that sounds reasonable. Uli From a.sporto+bee@gmail.com Thu Jun 19 23:58:36 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Thu, 19 Jun 2008 22:58:36 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619170908.417dbde4@webkeks.org> References: <20080619170908.417dbde4@webkeks.org> Message-ID: <20080619225842.GB8251@nets.rwth-aachen.de> On Thu 19.06.08 17:09, Jonathan Schleifer wrote: > Uli M wrote: > > > 7. Maximum message size handshake. Currently, each end uses its own > > MMS. This is a bad thing if you use something like jabber transports > > because the jabber end will likely have a too large MMS for the other > > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > > bitlbee since IRC has a limit of about 500 and the other end might be > > playing with 2k. The only reason why this currently works at all is > > because OTR messages (except the 'better' msg under 4.) start with > > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > > The solution is simple: Each end advertises its own MSS during the > > initial handshake and both use the minimum of the two. > > This has one problem: What if two users chat via ICQ for example and > both use a Jabber transport? Both would announce that they don't need > fragmentation, but they do. The jabber clients are probably aware that their contact uses an ICQ transport, so they know better and should announce that they need fragmentation. If you assume that the clients themselves don't know the appropriate MMS you need more elaborate schemes to determine it (e.g. measuring it). But I think that's not the case with jabber transports and I can't think of any other setting where this applies. Therefore, using the smaller of the two maximum message sizes should cover all cases. > We would need some way to define what we support *PER CONTACT*. So the > client could for example limit it's own capability if it knows it's a > gateway contact and announce that it needs fragmentation. That is already the case. MMS is checked per context in otrl_message_fragment_and_send: int (*max_message_size)(void *opdata, ConnContext *context); I didn't see any caching for this in libotr so applications can freely choose the MMS for each context. Uli From a.sporto+bee@gmail.com Fri Jun 20 00:00:40 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Thu, 19 Jun 2008 23:00:40 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <1213889178.6456.11.camel@hegg> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> Message-ID: <20080619230046.GC8251@nets.rwth-aachen.de> On Thu 19.06.08 17:26, Kjell Braden wrote: > On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > > This has one problem: What if two users chat via ICQ for example and > > both use a Jabber transport? Both would announce that they don't need > > fragmentation, but they do. > > This does not in any way conflict with what Uli suggested before. > > Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) > that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, > but chats with Alice using the transport) answers with the same value > and the lib saves that value in the context on both sides. The only > necessary change would be that the max_message_size Op would need the > context or the accountname, username and protocol for that contact. Which is already the case (see also my previous post): int (*max_message_size)(void *opdata, ConnContext *context); Uli From a.sporto+bee@gmail.com Fri Jun 20 00:36:08 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Thu, 19 Jun 2008 23:36:08 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619233612.GD8251@nets.rwth-aachen.de> On Thu 19.06.08 14:37, Ian Goldberg wrote: > On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote: - snip - > > 1. Asynchronous key generation. On some systems key generation can > > take more than one hour. I don't know how other IM-clients do it but I > > had to create a seperate process (not thread) for key generation which > > is really not ideal since inter-thread communication is a lot simpler. > > Also key generation will just finish at some random point in time and > > update the keys file. What I would like to have is one thread safe > > function that generates a key (some opaque struct I don't care about) > > which I can later on(in my main thread) give to libotr for inclusion. > > OK, that's an interesting request. I think we can do that. Willy, > write that down. ;-) great! ;) > I don't want to put anything thready into libotr, but we can have a > call like: > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_done)(void *newkey, void *data), void *data); > > which (after some time) will call call_when_done with a pointer to the > new key and whatever data you passed in. > > Then there can be: > > gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); > > which writes the newkey into the FILE (and frees newkey). Your > call_when_done routine can call that directly if you're single-threaded, > or signal the main thread that it's ready, or whatever. > > > What do you think of that? That sounds good. But I'm guessing the finish() function would besides saving the key also have to do the other duties of the old otrl_privkey_generate function, namely updating OtrlUserState: /* Generate a private DSA key for a given account, storing it into a * file on disk, and loading it into the given OtrlUserState. Overwrite any * previously generated keys for that account in that OtrlUserState. */ - snip - > > 4. The 3 line spanning OTR announce message, ironically also called > > "better message" in the code. This is again a hardcoded string I would > > like to see disappear. The really really bad thing about it is that it > > is a 3 line message and in IRC we don't have newlines. So in order to > > eat this message up and not present it to the user I had to hardcode > > the second and third line in irssi-otr. Bad! > > We want to display *something* to the other user if he doesn't have OTR > installed, though. Are you suggesting each IM client can provide its > own text here? That would be OK, I suppose. We'd need another > OtrlMessageUiOps callback for that. Yes, I think it would be good if each IM-client could provide its own text here and decide whether it's english, vietnamese, text/plain, text/html, or image/svg+xml ;) And should there be a default it should be text/plain and only *one* line. (Personally, I'd simply use ?OTR? as the default since people can probably guess what's going on or even more likely already talked about using OTR now) As I tried to explain before with the current 3 line message an IRC client gets in fact 3 distinct messages. He gives the first received msg to libotr containing the ?OTR? and libotr does fancy stuff with it. Then it gives it the second and third line and libotr will just give it back those two lines as they were, the result being that the IRC client displays the last two lines to the user "nick@somewhere/resource wants to do otr but you cant do it" although OTR is actually going to start in a few seconds. The only way around this (I saw) is to hardcode line 2 and 3 and eat them when they come. Uli From paul@cypherpunks.ca Fri Jun 20 04:15:06 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Thu, 19 Jun 2008 23:15:06 -0400 (EDT) Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: > I don't want to put anything thready into libotr, but we can have a Please remember to put a method in the API to send over symmetric session keys for support of file transfers, voice/video talk etc. Paul From fnord@pentabarf.de Fri Jun 20 07:39:38 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Fri, 20 Jun 2008 08:39:38 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619224246.63b6c71c@webkeks.org> References: Message-ID: <20080620063938.A6D921D88916@pentabarf.de> <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> <20080619193250.GY26418@thunk.cs.uwaterloo.ca> <20080619224246.63b6c71c@webkeks.org> Message-ID: <99a928e49b72aba7079d61c910a216b1@localhost> X-Sender: fnord@pentabarf.de Received: from p4FD94FA3.dip.t-dialin.net [79.217.79.163] with HTTP/1.1 (POST); Fri, 20 Jun 2008 08:39:38 +0200 User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 19 Jun 2008 22:42:46 +0200, Jonathan Schleifer wrote: > The client *DOES* now the maximium MMS, so if it's per-conversation, i > works. > If a message is too long, it's silently dropped by the ICQ gateway. > This is really bad behaviour anyway, but all gateways seem to handle > it like this. The max. MSS seems to be really small on ICQ without > direct connections. And I don't know of any ICQ gateway taht uses direct > connections. As Uli pointed out, this is my fault: I statically returned 0 from the MMS calback. Looks like I forgot a TODO-comment. Ian wrote: > We want to display *something* to the other user if he doesn't have OTR > installed, though. Are you suggesting each IM client can provide its > own text here? That would be OK, I suppose. We'd need another > OtrlMessageUiOps callback for that. no! It's enough to just switch to *one* callback that translates *all* strings (forgive me if I got you wrong and this is what you're suggesting). We would use it to do error messages as well as this announce message. Thanks for clarifying the conversion issue, I think I finally got it. This resolution seems okay with me. Thanks, Kjell From ian@cypherpunks.ca Fri Jun 20 14:26:10 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:26:10 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080620132610.GC18999@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 11:15:06PM -0400, Paul Wouters wrote: > > > I don't want to put anything thready into libotr, but we can have a > > Please remember to put a method in the API to send over symmetric session > keys for support of file transfers, voice/video talk etc. How's this: To tell the other side to use a symmetric key (chosen by libotr), attach an OTRL_TLV_SYMKEY TLV to a Data message. The contents of that TLV can be anything you like (an id identifying the key, a filename, whatever). The receiver will get a callback: /* We received a request from the buddy to use the current "extra" * symmetric key. The key will be passed in symkey, of length * OTRL_EXTRAKEY_BYTES. The TLV which carried the request will be * passed in tlv, so that the applications can communicate other * identifiers (some id for the data transfer, for example). */ void (*received_symkey)(void *opdata, ConnContext *context, OtrlTLV *tlv, const unsigned char *symkey); [OTRL_EXTRAKEY_BYTES is currently 32, so you can use, say, the first half as an encryption key and the second half as a MAC key. Or encryption keys for two directions, or whatever you like.] But note that there are no other semantics defined. How will Bob's IM application know what to do when it receives this key? Do you have a use case for this feature in mind? I suppose the spec could say "unless you have some (secure) mechanism telling you what you're supposed to do with this key, you must ignore this TLV." Note that this secure mechanism can be the information in the TLV, so long as there's common agreement on what the values mean. But that seems a little tricky. I guess whoever wants to use this feature (to implement encrypted file transfers, say), should define the meaning of the contents of the TLV. Say the first 4 bytes are an identifier of the semantic use of the key (00000001 == file transfer, 00000002 == encrypted voice, etc.) and the format of the rest depends on that value? Any thoughts? - Ian From ian@cypherpunks.ca Fri Jun 20 14:37:25 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:37:25 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620063938.A6D921D88916@pentabarf.de> References: <20080620063938.A6D921D88916@pentabarf.de> Message-ID: <20080620133725.GD18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 08:39:38AM +0200, Kjell Braden wrote: > On Thu, 19 Jun 2008 22:42:46 +0200, Jonathan Schleifer > wrote: > > The client *DOES* now the maximium MMS, so if it's per-conversation, i > > works. > > If a message is too long, it's silently dropped by the ICQ gateway. > > This is really bad behaviour anyway, but all gateways seem to handle > > it like this. The max. MSS seems to be really small on ICQ without > > direct connections. And I don't know of any ICQ gateway taht uses direct > > connections. > > > As Uli pointed out, this is my fault: I statically returned 0 from the MMS > calback. Looks like I forgot a TODO-comment. Ah, OK. :-) > Ian wrote: > > We want to display *something* to the other user if he doesn't have OTR > > installed, though. Are you suggesting each IM client can provide its > > own text here? That would be OK, I suppose. We'd need another > > OtrlMessageUiOps callback for that. > > no! It's enough to just switch to *one* callback that translates *all* > strings (forgive me if I got you wrong and this is what you're suggesting). > We would use it to do error messages as well as this announce message. The callback won't be translating strings at all; libotr won't contain any strings. [Exception: we'll supply default strings (or maybe just a default callback) for the aid of client implementors that don't want to have to deal with it themselves.] For weird conditions that have to be reported to the user, the client will get a callback like report_event(opdata, context, OTRL_EVENT_UNENCRYPTED, message) and it's up to the callback implementor to do whatever is necessary (display "The following message was not encrypted: [%s]" to the user, for example). A separate issue is that when libotr wants to start an OTR session, it sends an OTR Query message to the other side. This has to contain the query string (?OTR?v2? for example), but can also contain whatever other helpful text that the buddy will see if she doesn't have OTR support. Right now, it calls the routine otrl_proto_default_query_msg(ourname, policy) to generate this message. What I'm suggesting is that an application can optionally override this with a callback. [The callback would be responsible only for the text, not for the ?OTR?v2? part.] Is that clearer? > Thanks for clarifying the conversion issue, I think I finally got it. This > resolution seems okay with me. Great. - Ian From fnord@pentabarf.de Fri Jun 20 14:43:57 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Fri, 20 Jun 2008 15:43:57 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620133725.GD18999@thunk.cs.uwaterloo.ca> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> Message-ID: <1213969437.7688.2.camel@hegg> > The callback won't be translating strings at all; libotr won't contain > any strings. [Exception: we'll supply default strings (or maybe just a > default callback) for the aid of client implementors that don't want > to have to deal with it themselves.] > > For weird conditions that have to be reported to the user, the client > will get a callback like > > report_event(opdata, context, OTRL_EVENT_UNENCRYPTED, message) > > and it's up to the callback implementor to do whatever is necessary > (display "The following message was not encrypted: [%s]" to the user, > for example). > > > A separate issue is that when libotr wants to start an OTR session, > it sends an OTR Query message to the other side. This has to contain > the query string (?OTR?v2? for example), but can also contain whatever > other helpful text that the buddy will see if she doesn't have OTR > support. Right now, it calls the routine > otrl_proto_default_query_msg(ourname, policy) to generate this message. > What I'm suggesting is that an application can optionally override this > with a callback. [The callback would be responsible only for the text, > not for the ?OTR?v2? part.] > > Is that clearer? My idea was this: The lib calls a callback like: humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) and send the resulting human_message to display_otr_message. Same for the Query Message: otrl_proto_default_query_msg (or whoever) goes like: humanize_string(&human_message, OTRL_MSG_QUERY) and returns the resulting human_message. From ian@cypherpunks.ca Fri Jun 20 14:55:48 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:55:48 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213969437.7688.2.camel@hegg> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> <1213969437.7688.2.camel@hegg> Message-ID: <20080620135548.GE18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 03:43:57PM +0200, Kjell Braden wrote: > My idea was this: > > The lib calls a callback like: > > humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) > and send the resulting human_message to display_otr_message. But the application may not want the result to just be a string passed to display_otr_message. It might want to change some chrome in the UI, pop up a message box, or do something else entirely. Your suggestion also has the effect of forcing there to be a second callback to free the memory allocated by the first callback. (See the account_name and account_name_free callbacks, for example; hey--come to think of it, those will be able to go away with the new scheme. Nice!) > Same for the Query Message: otrl_proto_default_query_msg (or whoever) > goes like: > humanize_string(&human_message, OTRL_MSG_QUERY) > and returns the resulting human_message. I suppose this could be done the above way as well: then it would be up to the callback to actually transmit the Query Message after it constructs it. It would be passed the "?OTR?v2?" prefix. I like that, actually. - Ian From evan.s@dreskin.net Fri Jun 20 16:10:11 2008 From: evan.s@dreskin.net (Evan Schoenberg) Date: Fri, 20 Jun 2008 11:10:11 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620135548.GE18999@thunk.cs.uwaterloo.ca> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> <1213969437.7688.2.camel@hegg> <20080620135548.GE18999@thunk.cs.uwaterloo.ca> Message-ID: On Jun 20, 2008, at 9:55 AM, Ian Goldberg wrote: > On Fri, Jun 20, 2008 at 03:43:57PM +0200, Kjell Braden wrote: >> My idea was this: >> >> The lib calls a callback like: >> >> humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) >> and send the resulting human_message to display_otr_message. > > But the application may not want the result to just be a string passed > to display_otr_message. It might want to change some chrome in the > UI, > pop up a message box, or do something else entirely. > > Your suggestion also has the effect of forcing there to be a second > callback to free the memory allocated by the first callback. (See the > account_name and account_name_free callbacks, for example; hey--come > to > think of it, those will be able to go away with the new scheme. > Nice!) I agree strongly with Ian. libotr shouldn't care about getting human- readable strings from the UI in at least the vast majority of cases if not all cases. The UI gets a value out of an enum via a callback and presents this information however it chooses. Only with the 'default OTR' message do I see a need for returning a human-readable string. I have no problem with the current default string, but on the basis that one's contacts most likely speak one's language it makes sense for this to be localized by the sending client. Cheers, Evan From js-otrim@webkeks.org Fri Jun 20 16:14:52 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Fri, 20 Jun 2008 17:14:52 +0200 Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619233612.GD8251@nets.rwth-aachen.de> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> Message-ID: <20080620171452.5ffcc1a7@webkeks.org> --Sig_/I_z=NC/Kvs4Z5DSigFYe3Ft Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Uli M wrote: > And should there be a default it should be text/plain and only *one* > line. =20 I hope you mean the encrypted data and not the actual message? I understand that the encrypted data should be one line, but why the plaintext? --=20 Jonathan --Sig_/I_z=NC/Kvs4Z5DSigFYe3Ft Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIW8lwAAoJEMtRg9d5cXHktX4QALWsQ6KA2Z0XbgU71h66Ib1S Mn9EW6ENzv6Wz6OTBl3LQ4Dn0WdKfAEnFCNvmUuxOexa4EXJdLA2iEJhMP+E0rDF L0Yq62yp3IKtSYVMVfgBsA1K0ZeFtw8mAA8OA+SiVUkEULU87d8offPPNtVRB0kp sfsKruxslwYcfOIxSzYJ0WwDoOXfnV/EO8tsO4rfI3NgccpLyEYre4nMi0qQehKo Fxaf1GxehpEs2v7fUHD2+fVcCJUK2ZmOrUkzQKU+DnvrERYKOxClBdbi71vzTtYe l2L/hWVAj6UN8Mod0ZA/wDxs2/qPrEfJeTfuTy+8Iz5fCw6/cKkse8Ts7SylD2OE TiADH0ifR82sogDsyDIkGyFr/r5s/DKEv3Cix8lxj9JSM/acTIsAfqQ7LNV4SU/O HivtuEY+aGCZhTxsT0Hzt90uHzlfI+YVTYIilRjrqx1gTi0Jlw0OCjO8E7USJ+lK XcMSJe4Pv6W+2pi97UWeJyAzn3y+/89PWNWpTRCYYw3+qOwsQnizxYfvGMjpHbDe sdIKKygIhKNt+66Kq/r9C/lOuima060MKEPRQt+aB2x0UWKup/PG4X2G/GwzlRiU tl3aCGQRJUMTlRtYhYXkHknD4BupxEC+UQ4tt8W2rGgfepTznyyV5hnziR2n48wP bgxjOJkTBuyM9XlQ8VQL =H7qz -----END PGP SIGNATURE----- --Sig_/I_z=NC/Kvs4Z5DSigFYe3Ft-- From ian@cypherpunks.ca Fri Jun 20 18:44:15 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 13:44:15 -0400 Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080620171452.5ffcc1a7@webkeks.org> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> Message-ID: <20080620174415.GG18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > Uli M wrote: > > > And should there be a default it should be text/plain and only *one* > > line. > > I hope you mean the encrypted data and not the actual message? I > understand that the encrypted data should be one line, but why the > plaintext? We're talking about the OTR Query message, which is not encrypted. It's the message that's sent to trigger the other side to start OTR (if it supports it). Right now, it looks like this: const char *format = "?OTR%s\n%s has requested an " "Off-the-Record " "private conversation. However, you do not have a plugin " "to support that.\nSee " "http://otr.cypherpunks.ca/ for more information."; But, as has been pointed out, it's (1) in English, which is bad for many people, and (2) it's multiple lines, which is bad for IRC (at least). So I think the above will stay the default, but applications will be able to override it. libotr will provide the application with the appropriate magic string (the "?OTR?v2?" for example), and the application can build whatever message it wants around that. - Ian From ian@cypherpunks.ca Sat Jun 21 14:42:10 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 21 Jun 2008 09:42:10 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080621134210.GR6417@yoink.cs.uwaterloo.ca> Note: this message is long, and will only be of interest to Uli and others who care about asynchronous privkey generation. On Thu, Jun 19, 2008 at 02:37:38PM -0400, Ian Goldberg wrote: > > 1. Asynchronous key generation. On some systems key generation can > > take more than one hour. I don't know how other IM-clients do it but I > > had to create a seperate process (not thread) for key generation which > > is really not ideal since inter-thread communication is a lot simpler. > > Also key generation will just finish at some random point in time and > > update the keys file. What I would like to have is one thread safe > > function that generates a key (some opaque struct I don't care about) > > which I can later on(in my main thread) give to libotr for inclusion. > > OK, that's an interesting request. I think we can do that. Willy, > write that down. ;-) > > I don't want to put anything thready into libotr, but we can have a > call like: > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_done)(void *newkey, void *data), void *data); > > which (after some time) will call call_when_done with a pointer to the > new key and whatever data you passed in. > > Then there can be: > > gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); > > which writes the newkey into the FILE (and frees newkey). Your > call_when_done routine can call that directly if you're single-threaded, > or signal the main thread that it's ready, or whatever. > > > What do you think of that? I was thinking about it a bit more, and wondered who would be responsible for checking that we don't have multiple simultaneous key generations going on for the same account. If it's the application (i.e. calling the above otrl_privkey_generate_start with the same (us, accountname, protocol) triple is just illegal), then the above is fine. But it would seem to make more sense for libotr to check whether a generation is in progress. However, that check involves accessing the us data structure, so it has to be done on the main thread, not on the key generation thread. So the actual API would have to have three calls, not two: /* Call this from the main thread only. call_when_ready will be called * in the main thread. */ gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void (*call_when_ready)(void *newkey, void *data), void *data); /* You can call this from a different thread. call_when_done will be * called in the different thread. */ gcry_error_t otrl_privkey_generate_calculate(void *newkey, void (*call_when_done)(void *newkey, void *data), void *data); /* Call this from the main thread only. */ gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, void *newkey, FILE *fp); The application calls otrl_privkey_generate_start in the main thread, and passes the callback function call_when_ready. otrl_privkey_generate_start checks to see if a generation for this account is already in progress. If so, it returns a particular error code, and the application should free any data state it allocated before calling this routine. If not, otrl_privkey_generate_start will create an opaque data structure newkey, and pass it to call_when_ready, along with the data the application handed it. call_when_ready (code you write) should spawn a new thread and in it, call otrl_privkey_generate_calculate with the newkey it was passed, and a callback call_when_done. call_when_done will be called in the subthread. You can choose to pass the same data you received (which is what you passed into otrl_privkey_generate_start), or to free that data, and pass something else into otrl_privkey_generate_calculate; whatever works for you is fine. otrl_privkey_generate_calculate guarantees that will eventually call call_when_done. call_when_done (also code you write) is called from the subthread. It should deallocate any state you allocated as the data parameter, and signal the main thread that key generation is complete, handing it the newkey pointer. Whatever in your main thread receives this signal will call otrl_privkey_generate_finish to write the privkeys file and update us. How this signalling is done will depend on your application, of course. ********************* **NOTE** that the existing routines will continue to exist (though internally they may just call the above), so if you're not planning to use threads, don't worry about this at all. ********************* But I've got a question for you, Uli: key generation usually happens when you get an incoming OTR Query or OTR Commit message. If you spawn off a thread to generate the key, how will you keep around the state you need in order to remember to continue the AKE when you're done the key generation? In some languages, call-with-current-completion would probably suffice, but otherwise it seems like a real pain. In fact, I think libotr has to know this, since message.c will be the one that has to deal with this, since it calls ops->create_privkey. If that routine spawns a thread to generate the key and return immediately, libotr will be very confused. So: even assuming we do the above, your create_privkey callback *must not* return until the key generation is complete. You can still perform the key generation in a subthread, though, and your main thread can handle UI events to avoid appearing frozen, but it *must not* call any libotr functions (even in the UI handlers, hmm). Now what do you think? - Ian From ian@cypherpunks.ca Sat Jun 21 15:52:05 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 21 Jun 2008 10:52:05 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080621134210.GR6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> Message-ID: <20080621145205.GT6417@yoink.cs.uwaterloo.ca> See what happens when I post too early in the morning? ;-) On Sat, Jun 21, 2008 at 09:42:10AM -0400, Ian Goldberg wrote: > /* Call this from the main thread only. call_when_ready will be called > * in the main thread. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_ready)(void *newkey, void *data), void *data); > > /* You can call this from a different thread. call_when_done will be > * called in the different thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey, > void (*call_when_done)(void *newkey, void *data), void *data); > > /* Call this from the main thread only. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, FILE *fp); With the specified division of threads, the callbacks are now unnecessary. /* Call this from the main thread only. It will set *newkeyp, and * then you can spawn a new thread if you wish, and call * otrl_privkey_generate_calculate. */ gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void **newkeyp); /* You can call this from a different thread. When it completes, call * otrl_privkey_generate_finish from the _main_ thread. */ gcry_error_t otrl_privkey_generate_calculate(void *newkey); /* Call this from the main thread only. */ gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, void *newkey, FILE *fp); But the questions about how to deal with keys autogenerated during the AKE are still important: > But I've got a question for you, Uli: key generation usually happens > when you get an incoming OTR Query or OTR Commit message. If you spawn > off a thread to generate the key, how will you keep around the state you > need in order to remember to continue the AKE when you're done the key > generation? In some languages, call-with-current-completion would > probably suffice, but otherwise it seems like a real pain. In fact, I > think libotr has to know this, since message.c will be the one that has > to deal with this, since it calls ops->create_privkey. If that routine > spawns a thread to generate the key and return immediately, libotr will > be very confused. > > > So: even assuming we do the above, your create_privkey callback *must > not* return until the key generation is complete. You can still perform > the key generation in a subthread, though, and your main thread can > handle UI events to avoid appearing frozen, but it *must not* call > any libotr functions (even in the UI handlers, hmm). > > > Now what do you think? - Ian From fnord@pentabarf.de Sun Jun 22 15:42:03 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Sun, 22 Jun 2008 16:42:03 +0200 Subject: [OTR-dev] ConnContext.username in XMPP Message-ID: <1214145723.6647.3.camel@hegg> --=-ZLyGmnhcDqbAzuq5nolR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I'm writing this to both otr-dev and . Please CC both lists on replying. I recently came across an issue about the addressing of conversation contexts in the XMPP protocol. IMO, the most sensible way to identify a user in a context is to use the full jid (ie. with resource: "user@server.tld/resource"), because you could have multiple conversations to one user, where one resource knows OTR and another doesn't. OTOH, we have a problem when the local user does not know the resources of the remote user for any reason. This can be the case when they are not subscribed to each other, or when the remote user is invisible. The remote user could start an OTR session and the stanza would contain a resource (from=3D"user@server.tld/resource"). Now the local user receives the message and creates a context for "user@server.tld/resource". But since the local user does not know about any resources, the messages he sends have to be sent to "user@server.tld". The OTR lib now checks for the context with the remote user "user@server.tld" and will find nothing, as it only knows the full JID. So, it will not encrypt the sent message to the remote user, because it does not find any conversation context. The remote user will see the message as "not encrypted though we should be encrypted", because he started the encrypted conversation. Any ideas/thoughts on how to handle this case? Kjell --=-ZLyGmnhcDqbAzuq5nolR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXmS7NjvKGrx0tZgRAsTKAKCZcO41dJ+FzohfHzz3inuFHmfyUwCgiC9z Dv0mOB7Pjsds2/85auo47f0= =NU4R -----END PGP SIGNATURE----- --=-ZLyGmnhcDqbAzuq5nolR-- From fnord@pentabarf.de Sun Jun 22 15:45:12 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Sun, 22 Jun 2008 16:45:12 +0200 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <1214145723.6647.3.camel@hegg> References: <1214145723.6647.3.camel@hegg> Message-ID: <1214145912.6647.4.camel@hegg> --=-gK452ythdF+RqG+Ouqxl Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On So, 2008-06-22 at 16:42 +0200, Kjell Braden wrote: > Hi, >=20 > I'm writing this to both otr-dev and . Please CC both lists on replying. otr-dev and jdev, that is. Sorry. --=-gK452ythdF+RqG+Ouqxl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIXmV4NjvKGrx0tZgRAjfmAJ9OdDIeh0kyeC0Y7mUxKcHPSDRkhQCfSRld Wp3VwJIcFC60uLa52LDudck= =uKeq -----END PGP SIGNATURE----- --=-gK452ythdF+RqG+Ouqxl-- From js-otrim@webkeks.org Sun Jun 22 16:25:00 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Sun, 22 Jun 2008 17:25:00 +0200 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <1214145723.6647.3.camel@hegg> References: <1214145723.6647.3.camel@hegg> Message-ID: <20080622172500.65dd61c6@webkeks.org> --Sig_/xpbFnr54T6_6gY+IyY7S6bZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kjell Braden wrote: > Now the local user receives the message and creates a context for > "user@server.tld/resource". But since the local user does not know > about any resources, the messages he sends have to be sent to > "user@server.tld". Not exactly. That's no problem at all. If you receive a message from a resource, you can very well answer to that resource. The problem you'll get is when you first send a message, don't know the resource and thus send to the bare JID, but get an answer from the full JID. --=20 Jonathan --Sig_/xpbFnr54T6_6gY+IyY7S6bZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIXm7QAAoJEMtRg9d5cXHki9gP/RQKRhAbABhNa6HTvIgdw0K+ kYtC6/BiEnkUnoNo1pHD2h/d3gGbNxDqOZHt2U8wsVPhcwjtfHJv2cubKFEq2RF1 D/8mn4Dczj1PyapaX6Tmp9U7rECOxAhAlkh6tHt9KTL7miA2lRhnR93MZvySZz1h pb0ZMNerjk9H+G6YjZDVqiB0Ieh/DMLBZY46HzmKo6JVk3IorfiryDK3lvFjeZCS Q5kA/IKV8nyLiQGGazlD4/fE2m/x7RuR+TWTAFsOgp2+X9AlLyocevmsZcclLxM3 Xzm+JcN49g/3pEdlU1flFRQAuVR8MIQ+mNF+v1xuYf3NvxbDti7PvQE72v8jj4XX oQxlXENjs9h8GZ5I0gZvWELZRB6RMy24EfzppVc1rxJl0yxew5Tt4Ock9GAY0kiH UAdOJX52wkco9qF2GU6ubdQZpECACLFyPTWr4IB6KvaQo0JH6chUZzG0VtVCEtvX Jv4gjcJa7vrSL07166+6sL1G64FiKkyukkbKUu7J/xN6L8Q9HVrUOy8fCG416d2e 5zSwFqwHMyTuJd9JHg/BhX7BZwFNlp2QkS/CHv86mE1kwRpoPreXfO0dt68QnESD yepffFG4wxwdpBVjPP16tYNWzE/FLJMaKorIjmliJswqfCYzz1Muk0eYxP8r7u6j ReK0/8rLW8IOQGP8KWP6 =v5p6 -----END PGP SIGNATURE----- --Sig_/xpbFnr54T6_6gY+IyY7S6bZ-- From varenet@debian.org Sun Jun 22 22:23:07 2008 From: varenet@debian.org (Thibaut VARENE) Date: Sun, 22 Jun 2008 23:23:07 +0200 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <20080619131758.GG26418@thunk.cs.uwaterloo.ca> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> <45DA6C3D.6040001@gmail.com> <20070220111018.GB19501@yoink.cs.uwaterloo.ca> <20080619131758.GG26418@thunk.cs.uwaterloo.ca> Message-ID: <7d01f9f00806221423m20e6dbf3vacc9abebd2fd7c64@mail.gmail.com> On Thu, Jun 19, 2008 at 3:17 PM, Ian Goldberg wrote: >> One solution would be to statically link libgcrypt into gaim-otr (so it >> gets its own copies of global data). Can one of the Debian people try >> to build a package like that? >> >> A better solution, of course, would be to make libgcrypt >> sharing-friendly. This had been discussed on libgcrypt's mailing list >> a while back, but I don't know what, if anything, became of it. > > Has this been resolved in the debian package? The upstream source has a > "Makefile.static" that statically links libgcrypt into pidgin-otr.so. > > [D'oh. The version of Makefile.static in the 3.2.0 release forgot to > link in the new tooltipmenu.o file. It's fixed in cvs.] I still didn't get any feedback on the opportunity to statically link something as security-sensitive as libgcrypt into the package... HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ From ian@cypherpunks.ca Sun Jun 22 22:39:59 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 22 Jun 2008 17:39:59 -0400 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <20080622172500.65dd61c6@webkeks.org> References: <1214145723.6647.3.camel@hegg> <20080622172500.65dd61c6@webkeks.org> Message-ID: <20080622213959.GY6417@yoink.cs.uwaterloo.ca> On Sun, Jun 22, 2008 at 05:25:00PM +0200, Jonathan Schleifer wrote: > Kjell Braden wrote: > > > Now the local user receives the message and creates a context for > > "user@server.tld/resource". But since the local user does not know > > about any resources, the messages he sends have to be sent to > > "user@server.tld". > > Not exactly. That's no problem at all. If you receive a message from a > resource, you can very well answer to that resource. > The problem you'll get is when you first send a message, don't know the > resource and thus send to the bare JID, but get an answer from the full > JID. In particular, the OTR Query message (the "?OTR?v2?") will be send to the un-resourced address, but you'll get back the Commit Message from the resourced address, and all will be well, I'd think. - Ian From a.sporto+bee@gmail.com Mon Jun 23 20:05:16 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Mon, 23 Jun 2008 19:05:16 +0000 (UTC) Subject: [OTR-dev] Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080620174415.GG18999@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> Message-ID: <20080623190523.GB25190@nets.rwth-aachen.de> On Fri 20.06.08 13:44, Ian Goldberg wrote: > On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > > Uli M wrote: > > > > > And should there be a default it should be text/plain and only *one* > > > line. > > > > I hope you mean the encrypted data and not the actual message? I > > understand that the encrypted data should be one line, but why the > > plaintext? > > We're talking about the OTR Query message, which is not encrypted. > It's the message that's sent to trigger the other side to start OTR (if > it supports it). Right now, it looks like this: > > const char *format = "?OTR%s\n%s has requested an " > "Off-the-Record " > "private conversation. However, you do not have a plugin " > "to support that.\nSee " > "http://otr.cypherpunks.ca/ for more information."; > > But, as has been pointed out, it's (1) in English, which is bad for many > people, and (2) it's multiple lines, which is bad for IRC (at least). (3) it's HTML which is bad for a whole lot of people and clients. > So I think the above will stay the default, Hmmmm...shouldn't a default be as compatible as possible? I agree that English is the right choice concerning the language but wouldn't that also imply one line and no HTML as in: const char *format = "?OTR%s. %s has requested an " "Off-the-Record private conversation. " "However, you do not have a plugin " "to support that. See http://otr.cypherpunks.ca/ " "for more information."; I think if a client detects HTML capabilities on the other end it can easily choose the fancier message and everyone's happy. If HTML stays the default I bet implementations capable of HTML won't change a thing and OTR will keep its reputation for causing HTML garbage which actually keeps people from using it. (also this is not always OTRs fault as in that adium or libpurple bug where HTML stripping couldn't be done with OTR on). Uli From ian@cypherpunks.ca Mon Jun 23 20:57:17 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 23 Jun 2008 15:57:17 -0400 Subject: [OTR-dev] Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080623190523.GB25190@nets.rwth-aachen.de> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> <20080623190523.GB25190@nets.rwth-aachen.de> Message-ID: <20080623195717.GA6417@yoink.cs.uwaterloo.ca> On Mon, Jun 23, 2008 at 07:05:16PM +0000, Uli M wrote: > On Fri 20.06.08 13:44, Ian Goldberg wrote: > > On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > > > Uli M wrote: > > > > > > > And should there be a default it should be text/plain and only *one* > > > > line. > > > > > > I hope you mean the encrypted data and not the actual message? I > > > understand that the encrypted data should be one line, but why the > > > plaintext? > > > > We're talking about the OTR Query message, which is not encrypted. > > It's the message that's sent to trigger the other side to start OTR (if > > it supports it). Right now, it looks like this: > > > > const char *format = "?OTR%s\n%s has requested an " > > "Off-the-Record " > > "private conversation. However, you do not have a plugin " > > "to support that.\nSee " > > "http://otr.cypherpunks.ca/ for more information."; > > > > But, as has been pointed out, it's (1) in English, which is bad for many > > people, and (2) it's multiple lines, which is bad for IRC (at least). > > (3) it's HTML which is bad for a whole lot of people and clients. > > > So I think the above will stay the default, > > Hmmmm...shouldn't a default be as compatible as possible? I agree that > English is the right choice concerning the language but wouldn't that > also imply one line and no HTML as in: > > const char *format = "?OTR%s. %s has requested an " > "Off-the-Record private conversation. " > "However, you do not have a plugin " > "to support that. See http://otr.cypherpunks.ca/ " > "for more information."; Sounds reasonable. We can do that. Thanks, - Ian From a.sporto+bee@gmail.com Mon Jun 23 21:03:34 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Mon, 23 Jun 2008 20:03:34 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080621145205.GT6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> Message-ID: <20080623200341.GC25190@nets.rwth-aachen.de> On Sat 21.06.08 10:52, Ian Goldberg wrote: > See what happens when I post too early in the morning? ;-) > > On Sat, Jun 21, 2008 at 09:42:10AM -0400, Ian Goldberg wrote: > > /* Call this from the main thread only. call_when_ready will be called > > * in the main thread. */ > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > > const char *accountname, const char *protocol, > > void (*call_when_ready)(void *newkey, void *data), void *data); > > > > /* You can call this from a different thread. call_when_done will be > > * called in the different thread. */ > > gcry_error_t otrl_privkey_generate_calculate(void *newkey, > > void (*call_when_done)(void *newkey, void *data), void *data); > > > > /* Call this from the main thread only. */ > > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > > void *newkey, FILE *fp); > > With the specified division of threads, the callbacks are now > unnecessary. > > /* Call this from the main thread only. It will set *newkeyp, and > * then you can spawn a new thread if you wish, and call > * otrl_privkey_generate_calculate. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void **newkeyp); > > /* You can call this from a different thread. When it completes, call > * otrl_privkey_generate_finish from the _main_ thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey); > > /* Call this from the main thread only. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, FILE *fp); > That looks like what I had in mind. Although I didn't expect the extra convenience of libotr checking for the presence of other key generations ;) Currently in irssi-otr I'm checking myself whether a key generation is already going on. With current libotr there can't be two generations at the same time anyway since a second key generation process would overwrite the result of the first. > > But the questions about how to deal with keys autogenerated during the > AKE are still important: > > > But I've got a question for you, Uli: key generation usually happens > > when you get an incoming OTR Query or OTR Commit message. If you spawn > > off a thread to generate the key, how will you keep around the state you > > need in order to remember to continue the AKE when you're done the key > > generation? In some languages, call-with-current-completion would > > probably suffice, but otherwise it seems like a real pain. In fact, I > > think libotr has to know this, since message.c will be the one that has > > to deal with this, since it calls ops->create_privkey. If that routine > > spawns a thread to generate the key and return immediately, libotr will > > be very confused. > > That's exactly the way I do it and with current libotr I don't think there is any other way to do it. The confusion you speak of seems to disappear quite quickly though once the key has been generated ;) Although the reason for that might be that I call otrl_privkey_read after generation (since the key is generated in another process) which implies IIRC otrl_privkey_forget_all(). > > > > So: even assuming we do the above, your create_privkey callback *must > > not* return until the key generation is complete. You can still perform > > the key generation in a subthread, though, and your main thread can > > handle UI events to avoid appearing frozen, but it *must not* call > > any libotr functions (even in the UI handlers, hmm). That is really not an option at all. To give an example on the WLAN router of a friend of mine key generation takes more than an hour. Now should one use different keys for different IM networks that would really induce an inacceptable downtime. On my PC it takes about 6 minutes (unless I do du / or something) and even then it would really annoy me if I'd loose messages during that time. I had a look at libotr-3.1.0 message.c:755 and I don't see why libotr should be confused if create_privkey() doesn't generate a key. Won't otrl_privkey_find just return NULL in line 758 and we're back in the same code path as when ops->create_privkey is not implemented? There won't be a private conversation till a key is available but that is probably to be expected ;) Uli From a.sporto+bee@gmail.com Mon Jun 23 21:09:50 2008 From: a.sporto+bee@gmail.com (Uli M) Date: Mon, 23 Jun 2008 20:09:50 +0000 (UTC) Subject: [OTR-dev] Re: Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080623195717.GA6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> <20080623190523.GB25190@nets.rwth-aachen.de> <20080623195717.GA6417@yoink.cs.uwaterloo.ca> Message-ID: <20080623201000.GD25190@nets.rwth-aachen.de> On Mon 23.06.08 15:57, Ian Goldberg wrote: - snip - > > const char *format = "?OTR%s. %s has requested an " > > "Off-the-Record private conversation. " > > "However, you do not have a plugin " > > "to support that. See http://otr.cypherpunks.ca/ " > > "for more information."; > > Sounds reasonable. We can do that. Great! Thanks a lot! Uli From p5aabelle@tempel.com Sun Jun 8 01:52:34 2008 From: p5aabelle@tempel.com (foss gonzalo) Date: Sun, 08 Jun 2008 00:52:34 +0000 Subject: [OTR-dev] MSG ID:59924 Thousands of branded footwear Message-ID: <000901c8c910$06ad6c42$9cc0fe9a@qydvyte> The world's largest luxury store for shoes and bags is just one click away. Recommended by thousands of satisfied customers worldwide, we carry dozens of famous brands including: ~ Louis Vuitton ~ Armani ~ Gucci ~ Prada ~ Hermes Here you will find thousands of stunning designs for shoes, and leather products, at rock bottom pricing. Prices range from just $39 to $199; quality is assured and satisfaction absolutely guaranteed. Sale ends this week, so visit us today and start pampering yourself and your loved ones! - Visit our site: www.shoesquality[DOT]com (copy this link and then replace "[DOT]" to ".")