From alex323@gmail.com Sat Apr 8 15:18:00 2006 From: alex323@gmail.com (Alex) Date: Sat, 08 Apr 2006 10:18:00 -0400 Subject: [OTR-dev] Fragmenting? Message-ID: <4437C618.3070106@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0992A4B5115294DA1D61A01F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have come to the point where I need to have fragmenting for OTR on IRC. However, I am unable to locate the fragmenting APIs to do so. I can see otrl_proto_fragment_accumulate, but where is the code that actually fragments messages? - Alex --------------enig0992A4B5115294DA1D61A01F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBRDfGHINsvbPFJtOPAQp7rA//Srr03dl/9GhuYmuyLPby9fUJa20jLNff 2b5MK9ycpoO4sBNFdvbLGataUJsR36aui9qppTPoqnejoq+T7nTtIrDvCtFNGov1 RKw540r/h3JVYXxGyn4bfV5N/APJDdsLMFT6/iuZuYizNHOF7gbT+7MYNYhyK2tl 5eqk0f7+H89Hl7FscLCovYkUlc+M1jolqXktfpLITearYmwnU1M2N6CH381WEIAg BMOi5uggzB+K8pbRX8MwIouF1XtOp2oYrDvoMPLYR9xL86f6A11GylLqCGU1dSyg qOFPTKn+4n5gnOpv5DsHYfZDx94eCNNBOlhXHYf0AWJ+c5pxSj9F0gTjo/BrwtH0 3/lIcs9QTDKyFEwbgi8i03qvA44bHYBGsk0PlN0ld2dMeQdzE1glHhEvHabPqJ8u LCbxmmXPqlvIGMo57WIBRevgMMsWALJvv9aS1E+VNNVcgxTU/RZYJH0AwQI3Wh7y 4YF72v0j9H3f4pvdv01FGk/tV3aH4+wd2fT3NNONnpAV7G3p+kXtjI0/UfzRA6U2 L8TqPbC9oy/bGbFFcAtbjo/eAM+JqiljlKpsIur5v61opKTGZU/y8skP/BiTlDgo ORP5+QSe6eg1EVOY70mLXgNkuZF4mOQrkS9jEZbL/EYbMzCRfDYCPcS8FkL2LyHx Db1fclVOwLA= =oFD+ -----END PGP SIGNATURE----- --------------enig0992A4B5115294DA1D61A01F-- From ian@cypherpunks.ca Sat Apr 8 21:07:05 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 8 Apr 2006 16:07:05 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <4437C618.3070106@gmail.com> References: <4437C618.3070106@gmail.com> Message-ID: <20060408200705.GQ31646@smtp.paip.net> On Sat, Apr 08, 2006 at 10:18:00AM -0400, Alex wrote: > I have come to the point where I need to have fragmenting for OTR on > IRC. However, I am unable to locate the fragmenting APIs to do so. I can > see otrl_proto_fragment_accumulate, but where is the code that actually > fragments messages? It's not in the current version. The plan was to let version 3.0 get out there for a while, so that it's likely people will be able to *accept* fragments before trying to figure out the annoying bits of how to pick a MMS (maximum message size). When there's a version that supports fragmentation, it's likely that you'll make a callback that, given the account/username/protocol triplet, returns an appropriate MMS to use, and otrl_message_sending() will take care of things, just as otrl_message_receiving() already takes care of fragment accumulation. - Ian From alex323@gmail.com Sun Apr 9 03:12:23 2006 From: alex323@gmail.com (Alex) Date: Sat, 08 Apr 2006 22:12:23 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <20060408200705.GQ31646@smtp.paip.net> References: <4437C618.3070106@gmail.com> <20060408200705.GQ31646@smtp.paip.net> Message-ID: <44386D87.4090003@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C61A38DB33767D19807F0DD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Goldberg wrote: >When there's a version that supports fragmentation, it's likely that >you'll make a callback that, given the account/username/protocol >triplet, returns an appropriate MMS to use, and otrl_message_sending() >will take care of things, just as otrl_message_receiving() already takes >care of fragment accumulation. > Has development of this started yet? - Alex --------------enig7C61A38DB33767D19807F0DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBRDhti4NsvbPFJtOPAQooYQ/9EzY62u9XUsIIS//FrQeTZ3vOWYdvYZxR 7JjxK9I3HVyvgRRXEfNuJA06FZLlKrPfNkgFMVGkOWtQQMVrFq7l/o79Pk++S31t Ot6T7QiurRRNq2G3Vcu7IdMZLA22wah7ivtCwKHE9YIfUeohVUfDXcIwHdfWQoBg AvLK0wj6qdrjTM0HqjuKKn8xJaltaeFS/f6rUL6XEPHR9ltZY1WE1s7lut7YAodb WLLDCp+K4nmIB9RslgOhUZ3QRMW9HFZlGkpt2JlLpJvaCshEtekPfCz6OHv+/zzj 8imRHcEC3UKyDSx6ai2DVfoCC1hg+nmgoc4nRXutHjTslRByYyCjlcqCuSTuAkbe orsyqG4q2YuGCuWX+3ZXW/QJdveXdJyR7Jb63Ly0nVVD07p9Y9PMxC3kxr75YZbv yFb6Z2oUA1uG9M6I5guqpnkwMCc2pWs0AuiakELI6DdWMmUzKnK9FLHwtz9F6eG3 ZODpcIj+Wt1IKcpZfKLrxMyZBWDiEX22TNI9b/mexgr5FRUUGBoQ8rSWnFkmJuSg wnnxyFHD3+gTNQaDKE+k7e9X4IcOCScK+4raZWmbNNuo2b0L79goyWJyNSs7lGHO MIUowsI1pefNxqoA8w3rsv6BIL0yO0rpDwWXPjxIby/B/NKMTWGkoIIVcmovra9+ D0pEm/b7uYg= =mVx5 -----END PGP SIGNATURE----- --------------enig7C61A38DB33767D19807F0DD-- From ian@cypherpunks.ca Sun Apr 9 17:39:07 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 9 Apr 2006 12:39:07 -0400 Subject: [OTR-dev] Fragmenting? In-Reply-To: <44386D87.4090003@gmail.com> References: <4437C618.3070106@gmail.com> <20060408200705.GQ31646@smtp.paip.net> <44386D87.4090003@gmail.com> Message-ID: <20060409163907.GR31646@smtp.paip.net> On Sat, Apr 08, 2006 at 10:12:23PM -0400, Alex wrote: > Ian Goldberg wrote: > > >When there's a version that supports fragmentation, it's likely that > >you'll make a callback that, given the account/username/protocol > >triplet, returns an appropriate MMS to use, and otrl_message_sending() > >will take care of things, just as otrl_message_receiving() already takes > >care of fragment accumulation. > > > Has development of this started yet? No. - Ian From alex323@gmail.com Wed Apr 12 18:47:55 2006 From: alex323@gmail.com (Alex) Date: Wed, 12 Apr 2006 13:47:55 -0400 Subject: [OTR-dev] OTR Fragmenting Support Message-ID: <443D3D4B.5090702@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DEC2D8D9998992DEEE361EC Content-Type: multipart/mixed; boundary="------------080204030003040601060604" This is a multi-part message in MIME format. --------------080204030003040601060604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey. I created a patch for limited fragmenting support in libotr. It only works with in the AKE, but that's where many of the longest messages are sent. I have not modified the library to include support for data messages, as I do not know how the fragmented messages should be returned. to the application. Attached is a README and the patch. You can also download the patch at sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=1469420&group_id=128860&atid=713090 - Alex --------------080204030003040601060604 Content-Type: application/x-bzip; name="otr_fragmenting_patch.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="otr_fragmenting_patch.tar.bz2" QlpoOTFBWSZTWWCI4PMABSb/hPowAEBzf////8/9vv//3/oAAKAIYAofPPWVy93u6u3qpCIB QAACgAGEoQmhTxBpGmTKYTaajTRp+qZDaTaQNAZAMTRpkGqn4ozVT1PynqCaaYgDQDI0MQGg DIAANNDQaqf6qfpMmono1MEZMmQGExBowTTIAMgxAMTQZpJKZo1R6n6kPUHqA0GgAAAAAAAA A4Gg0yGmjQwgZDQwRoaZNGgGQYgADQSJAgIAgyp5MAptEamE9TQ9Q0DNE00NDagZPcfT6eY/ GZjAh1EIzQgZ5uiQWAgZMJC0OGkEMSgSYENEhEIOVHO0EIoDUORSKAjiSuAjXm9QMVndaXKn QkUKCqKAxiEOoqkpnJ2dWzwVW+nlt+/5sPJOcEUpNWI3SIgRanMT4QKeblhNLWOkrDj7qIQQ QCtCwKEGAWQnn++GjNmes8+WS+qUEa61ii11MhE83jl7sTmChgXBpMsL8eTlb4m/hmEhabZZ fZ9pKv27jYJJEkjcMhAj3DSSA3HIwBptibQpqQiI4MYJACjjSjencbz4Y1xdGrUstlnV5tAP qZ6Kr5o91Zipgk1+drtZmD8PjZs6vhA79aa2A92kauzfbEZu9dQ37acAO0fyP5+u036gNo67 9d0YwmYYXhzm5lmVLFyXw43ENRuZQ8NWM2LJ3yJoV7ThzrKUrUiqdS8l3jGMs64FrjqjD3Xl MWiklimHS1M4RQ+K3ylcKQEwHivcHg3UAp6eI7cgx5FHRSlA1lpqAEFKIhPgTVpXOdK2Qtfg Hnvu/GiHUwMCE4W9AAV25eOXTo/Jg8bh2hI52DqZWkqJgT4qAFLBCPqlPNjERXJ7YAgoFuEt Yva3E6HSUnabdwZQXOVDArLqxu2pxzOOp4ZfNIznV02JztU2TXLCdKWEo0ajke2pWOEbWTXz 6qoACIGa84EuqNW5yRNl6tskX64mczKpptzIHE+xucaCc5giQxQyJgmDPFOQoN4PSKTZjRFg dFTFNAx2/IiEDN/hEMLw4HTmbLjkybDfgGga0+GozXieKQ06AbcR+aERyDSIDiAC5Ej1nZIN 7DXZg1VyA5VhES8SF5sjn9y4pHSgSo8N1KZ4K/FyYB5BbkcEIDl3PE6PW3jDe43+oCA9gEgP mAYaGtoZCYvqkHkFukKLruutpkXbib2C3m+AXCm8+ewUVVxUDnCiqsdIB2oB7e/534yNPeQx zZP1AHycwxjGMYrysLpn1mBB6MdT9YgCXwFBOb91GmAoPCIDDBx2ZABRwDA6kHh4L0kTglSx Yy8tqSaSaTEG3UkFAkG2qh353c4Fcdzf12uwvxmZOTsXL6yRopZ1gCwwJMeZVhBCLglVyW+5 WA1lbr7FsspBfeEE51CmNCR8ZbTMPV5/PE87A6+E2Dv8f2+UHd8spIxebDQwbhhinV1H6fKW 2d+vAcTLiQyqgkVzqhnR+64wAFNKb/uAgEQxtZwMj5RgNlFtAKnIp6PsZm/hteckSjnatZzp t8PRLROSyTB0dj+XeGQ6Fv1JmnvbBIFSxqtozlOlk0drVUxPds5Upueq0bd6wHf5pSVGNjCK M7p2AmUUtzIuYeTptM7YVLqILoix7dWseLAaCcdb+tQTlcUReADECv0xiWJ6D78j/Jj6NuKz nIDCF7GoP4JBk3aRMaGwan7aFJ+HII9/sFkrIawpGv98xngHLzZU0rQByjYLJq/2sA67qzyS DaJjOhXAElmgKI8hmpBjoSxPI4HphSIaJS580aKUdRja+hNgw+ic5C0eYyaawnNVovbp0osn vvCEXmyKQiCNrjnamMJMdgMZSy4Aanvz0YPG7Z8HMo1aHefTL2FeoYUKxtZcXYyZNNk/tGGR +ooUVMSM0YEaXzrGDimaqMGtFFIjCUUks1NqLTyuqgo03a6qlc51JbyH/aqDmQfgiMkVK6oJ SCMcagp017icIrpgVHnQlAJXmuARpxK6ttS5UPvzOkJZ9cZsM0g+IYDZHR8Jjrz1Cm9qCYsE kvtPg5kw0KE2ptSYtRbt2B09zjwlCCoFDkoE2UgoUpSakvuGEXFVYuaifF9rMdwXJNJNmmCZ 2IaYC5WSGLdS3LYuF+iwgVEadJRE8O4XScjUEUZIbBGAQJD7YD1jojV/cqcow/Ba7K3vCCDu iHuSn5IPRx3DTY3cK7qsjf2Pv3FZFM/sWtG5+ZlqdBwLsKHYYl3wBsxJRsHHMRL5zO51TwS8 N+UFGr4zpqkF26hr11NhWQE0WNU4OHvwSu1D4LrmiBoJa+NLHV0InfeBxrqRiflIcrWFAgi0 YcKQDU3muSkS7zM7MODrvjCqxI06dCxlC6DtjU73pAuSSODkGsGfcA4UiEZmfP5pqG2NNHCd 6QTpnuabtNkREsn0uc6tdSNIZLHbbaotshUypZzHORAwkGE7MvnJveBWmSuWwnFywB3zstiM PPxAnYqCswJIK6OmU1VECiCqcKE2MThMIYpJoTElBCRJQoBOufewG/kYg4po7KK0zrS6UaAO nr3T9b0YNG5S89AJyQQAxI6FxB8/Hmc8HksmnVm3unp6RsnB0SgiokfqMggdtGgolKnbl79a AyYdXXMZdquHXQlRsATWn7umynCbz8ca6I4skHrPEyOfg9XkA0HoWBs/WMWeXPkC5WgzSpIq pygMpOaAciEz2dSR/gaENgidEBuAO62GDR72efcMLZGQimJs5yX5HtezWcy73snMAzlrA2Ke jQFwkTRcgKkBYVvCNalPjDueJfSBs4xQ64qNpWGmHxUFNTmM6I+Fyd5wADScB7ruYemSmneA F0B6b7ClXZB5IfCPTf1gGsALO8WdMDDlJ8bTRk4M7/Uk1w4smKRtlBT0waH7zIziTMGWY7uQ kYXapazJQybAMZCqw52p5IoIknQhIYQCKt5TJXDgAJl+96gQ7QEUKVItdCvJlIn3UAuQxp2E idMZJIpM7USQQFULDEDAoazXq8/4xlxNLMxrOQXb1jrLlycs0Eo/0SN4O86GmAyq8U/I4WDJ reu/zrR8hv50GKWlhrkLABpJM/HdC2Xdrh6poho2677lMMQlrAhaWs2jSMJEoghybIzHh0m/ +LuSKcKEgwRHB5g= --------------080204030003040601060604-- --------------enig0DEC2D8D9998992DEEE361EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBRD09UINsvbPFJtOPAQoTCQ//YeyjvOaL1puLuZwhGo2I+IgMGxOP/iqr jEFMWjv+A95QNhVpY46v6rkNtIV57OgdXtp2VW62ZQyZiLULdm/jFlvKqCKXpSZe VOo9Djy/UtwizWW7+N0AGdIWicqdkTrkQP9Bd47lLskcLxZx8PA/sSS1QgLn+Eql H+biQgW2Owv/Bu4+eGpER1ufnCI/bu2UrdV7cWoCD19ziCP3pO9eM3SKjNrI4Wop o+V5s3TPjSAht82soa6BrDqkzIJXfxcHTuYwYdfmpzCZWLMbvbkpcGvl2vdEtbEJ vX3d30gp2zkUsVb5iead5qOShsQ44Kh3CfeHSLQQeRizUUZGL2LOqsaEbTNCEjdQ bwktmj/FjGc1RMZi4ZvDbdl6GapgzcaudlqFrODeI3v0bUGxVIsLFtg0v8nXOLBW TnNxL/5JhHHN/JAICgNgaW3TVukP/vNomoMYECHtjgzQuHhsTAgXG/d3iIOBF8xC DM/iM14ivSA9I8570iZRKJZFW0koSbEoH8GWaJXkwMCrwk3FhofPJcckYfq8lc4j cwPA3EnnXd7AQhS9/Ja0p+PQFDEHlmlEdIM9N7fbYhwNCGzu37iHbfa77b9/XXsh 4FWcs7lGKHIVWUFQgfZfcKOmCNW+VqU3bmU6e6kAc67p8gn+ZTF+hv0sx/A44aGf Ll3CjTdpwoM= =jMnq -----END PGP SIGNATURE----- --------------enig0DEC2D8D9998992DEEE361EC-- From ian@cypherpunks.ca Wed Apr 12 19:27:30 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 12 Apr 2006 14:27:30 -0400 Subject: [OTR-dev] OTR Fragmenting Support In-Reply-To: <443D3D4B.5090702@gmail.com> References: <443D3D4B.5090702@gmail.com> Message-ID: <20060412182730.GG14888@smtp.paip.net> On Wed, Apr 12, 2006 at 01:47:55PM -0400, Alex wrote: > Hey. I created a patch for limited fragmenting support in libotr. It > only works with in the AKE, but that's where many of the longest > messages are sent. I have not modified the library to include support > for data messages, as I do not know how the fragmented messages should > be returned. to the application. Attached is a README and the patch. You > can also download the patch at sourceforge: A good start. Thanks! There are a few problems with it (mms is never initialized; your fragments are too large (they don't take into account the size of the header); you don't free memory properly in the event of an error; etc.), but it's definitely in line with what was intended. I probably won't get a chance to work on OTR too much until after the Computers, Freedom, and Privacy conference (www.cfp2006.org), but I should have some time after that. Data messages are a little tricky, since it's unclear whether messages sent with inject_message() will go out before or after the message left in *messagep at the end of otrl_message_sending() [this will depend on the structure of the application using libotr]. But I suppose all fragments *could* be sent using inject_message(). - Ian From alex323@gmail.com Wed Apr 12 22:34:42 2006 From: alex323@gmail.com (Alex) Date: Wed, 12 Apr 2006 17:34:42 -0400 Subject: [OTR-dev] OTR Fragmenting Support In-Reply-To: <20060412182730.GG14888@smtp.paip.net> References: <443D3D4B.5090702@gmail.com> <20060412182730.GG14888@smtp.paip.net> Message-ID: <443D7272.1070003@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F84E2963D74052A749548EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Goldberg wrote: >On Wed, Apr 12, 2006 at 01:47:55PM -0400, Alex wrote: > > >>Hey. I created a patch for limited fragmenting support in libotr. It >>only works with in the AKE, but that's where many of the longest >>messages are sent. I have not modified the library to include support >>for data messages, as I do not know how the fragmented messages should >>be returned. to the application. Attached is a README and the patch. You >>can also download the patch at sourceforge: >> >> > >A good start. Thanks! > >There are a few problems with it (mms is never initialized; your >fragments are too large (they don't take into account the size of the >header); you don't free memory properly in the event of an error; etc.), >but it's definitely in line with what was intended. > This was my first real C project I've done, so any suggestions/tips are appreciated. Thanks. - Alex --------------enig4F84E2963D74052A749548EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBRD1ydoNsvbPFJtOPAQpjmRAAsjXbk97/TEsnv4zovH6bSbDN7oJ8vLzy jZtTcKxa7D7/eMij1BuwOVOsU7bxe1KdiYIFiFn9liaBbNRp1ee0aIg08wGn0031 ak80clLpFma0XA8sqru+4fETaYFHnYQO7MijMBM6lpXVg/IklLYZDNLZtf1XAxq6 FeaGqHuav+H6vkUWEV+HOpR1S1i+mT4dFxGXlj3mYvOP7K7FRomunbHPjuNUn3eq FtfcdUzd/G3+qTrhkVVW5vLhPpEbulVlJvDHcfHY8J7EEqxBR9byHuNJq8yHecI7 niuyNlzSGOxy3+zfC1z1gqkfSDrdKdluO2z/SYJ3VD6LpEWT1GXlI+yr3j7clU5Y ugQk5S+2cpwz4aIh1Vq3AYrHY7/g44YOakj1JBBYmBbgeDrAKr/9Sw4ExRIUbhgL Y6uq2ETWlnkapb65/Q4BiWce3z/Efmb1mJY85djg6hNtImHgRNbfEmO6ZQquuch5 YEBCANcHLsf4HR5kAknL2UJ3KPsN5TrdHAZuSYHpEnGyCU8RVZo/iw3Re6BHoUjP ZMIIc71skPwBT/lBg+pg1IeOz1jTbZUsgXKcjMIpmzyki4FV3RvOzz278Mr2UJOc tNtXOxrOQohuj2d7SDgnf4mWJoo/J5aa1GH3V/3fO+RnqN8gmQ5dVOKKG8h6shkF xWaCW+8i9HE= =Ekql -----END PGP SIGNATURE----- --------------enig4F84E2963D74052A749548EF-- From twanfox@gmail.com Thu Apr 13 19:57:51 2006 From: twanfox@gmail.com (Twan Fox) Date: Thu, 13 Apr 2006 13:57:51 -0500 Subject: [OTR-dev] Self-referencing structure Message-ID: <443E9F2F.2030905@gmail.com> Greetings, While I understand that most don't work with Visual Studio .Net, I am running into a problem with that compiler as it relates to the Trillian OTR plugin I am writing. Specifically, this segment of code from the context.h file is giving it/me fits: typedef struct fingerprint { struct fingerprint *next; /* The next fingerprint in the list */ struct fingerprint **tous; /* A pointer to the pointer to us */ unsigned char *fingerprint; /* The fingerprint, or NULL */ struct context *context; /* The context to which we belong */ char *trust; /* The trust level of the fingerprint */ } Fingerprint; The error: c:\TrillCrypt\libotr.head\libotr\src\context.h(45): error C2461: 'fingerprint' : constructor syntax missing formal parameters I know what the compiler is complaining of. It believes that the 'unsigned char *fingerprint;' line is a constructor function for the struct 'fingerprint', but structs don't have constructor functions. I am, unfortunately, at a loss as to how to tell it to treat it as a regular C structure. I've attempted an extern "C" {} bracket around the included header files, but that seems to only work with functions, not data structures. Any insight anyone has would be appreciated. Thanks, Twan From ian@cypherpunks.ca Thu Apr 13 20:22:05 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 13 Apr 2006 15:22:05 -0400 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <443E9F2F.2030905@gmail.com> References: <443E9F2F.2030905@gmail.com> Message-ID: <20060413192205.GR14888@smtp.paip.net> On Thu, Apr 13, 2006 at 01:57:51PM -0500, Twan Fox wrote: > Greetings, > > While I understand that most don't work with Visual Studio .Net, I am > running into a problem with that compiler as it relates to the Trillian > OTR plugin I am writing. Specifically, this segment of code from the > context.h file is giving it/me fits: > > typedef struct fingerprint { > struct fingerprint *next; /* The next fingerprint in the > list */ > struct fingerprint **tous; /* A pointer to the pointer to us */ > unsigned char *fingerprint; /* The fingerprint, or NULL */ > struct context *context; /* The context to which we belong */ > char *trust; /* The trust level of the > fingerprint */ > } Fingerprint; Try changing the three instances of "struct fingerprint" to "struct _fingerprint". Someone suggested this a while back, but it didn't make it into CVS. Let us know if that works, and if it does, I'll check it in. The rest of the code references this type by its typedef "Fingerprint", so the struct name is completely arbitrary. - Ian From ian@cypherpunks.ca Thu Apr 13 22:27:50 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 13 Apr 2006 17:27:50 -0400 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <20060413192205.GR14888@smtp.paip.net> References: <443E9F2F.2030905@gmail.com> <20060413192205.GR14888@smtp.paip.net> Message-ID: <20060413212750.GS14888@smtp.paip.net> Twan reported it worked, so I committed the change (using "struct s_fingerprint"). C++ compilers should now be happier. ;-) - Ian From twanfox@gmail.com Fri Apr 14 04:38:54 2006 From: twanfox@gmail.com (Twan Fox) Date: Thu, 13 Apr 2006 22:38:54 -0500 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <007201c65f3d$91816d20$0301000a@cheshire> References: <443E9F2F.2030905@gmail.com> <007201c65f3d$91816d20$0301000a@cheshire> Message-ID: <443F194E.8070806@gmail.com> mike davis wrote: > this is always a bit of a pain, you run into this a bit with linked > list stuff.. > > im curious though, because i got this code to build with vc 6.0 before: > > typedef struct pending_connection{ > char cookie[SLINK_COOKIE_SIZE]; > int socka; > pthread_t threadid; > struct pending_connection *pNext; > struct pending_connection *pPrev; > }pending_connection; > > which vc++ 6.0 seems to think is a perfectly valid syntax >> >> typedef struct fingerprint { >> struct fingerprint *next; /* The next fingerprint in the >> list */ >> struct fingerprint **tous; /* A pointer to the pointer to >> us */ >> unsigned char *fingerprint; /* The fingerprint, or NULL */ >> struct context *context; /* The context to which we >> belong */ >> char *trust; /* The trust level of the >> fingerprint */ >> } Fingerprint; >> The issue is not so much with the VS.NET 2003 being incapable or unwilling to understand the whole notion of a self-referenced structure. The issue relates to the conflict between the 'struct fingerprint' structure and the 'unsigned char *fingerprint' line. For a C++ compiler, that basic syntax is grounds for a constructor function. As in: class A { A::A; // This would generate the invalid constructor function A::A(); // This is proper syntax for a constructor function } ref: http://msdn2.microsoft.com/en-us/library/77e603b6.aspx What is terribly stupid about this issue is the notion that VS.NET 2003 seems to believe that a struct is somehow the same as a class, and should imply that any member that shares the same name as the structure is a constructor function. Because I wound up having issues rebuilding my plugin from scratch, setting out to make use of the Windows Template Library for the UI, this problem came up as well as a failure to link in the libotr library I had made. Ultimately, and I think this might've taken care of my problem had I done it first, doing the following would have allowed me to merge a library written in C to a project written in C++ extern "C" { #include #include } This would have told VS that the headers are true "C" syntax and should be treated as such. This also allowed me to link the library I built for libotr v3.0.0 into the resulting .dll from my project. Seems, as I kind of expected, this is a case of programmer error, with the programmer being me. Thanks for the feedback and assistance. - Twan From arodland@entermail.net Fri Apr 14 16:22:38 2006 From: arodland@entermail.net (Andrew Rodland) Date: Fri, 14 Apr 2006 10:22:38 -0500 Subject: [OTR-dev] Self-referencing structure In-Reply-To: <443F194E.8070806@gmail.com> References: <443E9F2F.2030905@gmail.com> <007201c65f3d$91816d20$0301000a@cheshire> <443F194E.8070806@gmail.com> Message-ID: <200604141022.38556.arodland@entermail.net> On Thursday 13 April 2006 22:38, Twan Fox wrote: > What is terribly stupid about this issue is the notion that VS.NET 2003 > seems to believe that a struct is somehow the same as a class, and > should imply that any member that shares the same name as the structure > is a constructor function. A struct _is_ somehow the same as a class. The only _real_ difference between the two is that members of structs are public by default, while members of classes are private by default. Any other difference between the two is strictly in your head, and a matter of convention. To the compiler, they're exactly the same except for a matter of access. Andrew From twanfox@gmail.com Thu Apr 20 02:17:54 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 20:17:54 -0500 Subject: [OTR-dev] Libgcrypt slowness in generation of keys Message-ID: <4446E142.6010500@gmail.com> Greetings, I know I've seen this issue around time and again, but after actually making a run at having libotr actually generate me a key for my Trillian OTR plugin, I found the whole process took 22 minutes before it finally returned. Obviously, this is unacceptable. I am currently using the libgcrypt v1.2.2 (as that is the only one that seems to be well supported by the Visual Studio .NET environment from s0rr0w") and have applied the patch as suggested on the main site in order to limit the heap walking. However, either I applied the patch wrong (since I applied it by hand, though after checking, I seem to have pegged it in the right place), or some other fix is needed in order to improve this. Now, I understand that Gaim happily builds private keys very quickly with the Gaim OTR plugin. However, I have no idea what libgcrypt version or patches were applied in order to make it work like it does. I am also not terribly sure that compiling the libgcrypt library via mingw will provide me a library capable of being used within Visual Studio, and unfortunately, I am not presently willing to divert from that compiler as I need it for the UI functionality it provides for me. I know there is something out there that is the probable fix, but I can't seem to locate it again. Any assistance or information is appreciated. Thanks, Twan From twanfox@gmail.com Thu Apr 20 02:49:32 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 20:49:32 -0500 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys Message-ID: <4446E8AC.5050007@gmail.com> All, I might've been slightly hasty in my prior posting. Seems a full clean and rebuild of my plugin brought the time down to something more reasonable (sub-60 seconds or so), though part of me is a little bothered still by the way it the program was made unresponsive during the entropy gathering phase of the key generation. Sorry, Twan From ian@cypherpunks.ca Thu Apr 20 03:11:29 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 19 Apr 2006 22:11:29 -0400 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys In-Reply-To: <4446E8AC.5050007@gmail.com> References: <4446E8AC.5050007@gmail.com> Message-ID: <20060420021129.GU1474@smtp.paip.net> On Wed, Apr 19, 2006 at 08:49:32PM -0500, Twan Fox wrote: > All, > > I might've been slightly hasty in my prior posting. Seems a full clean > and rebuild of my plugin brought the time down to something more > reasonable (sub-60 seconds or so), though part of me is a little > bothered still by the way it the program was made unresponsive during > the entropy gathering phase of the key generation. If your UI thread is the one doing the key generation, then it will naturally make the app unresponsive. Just do appropriate locking in a separate thread. But 60 seconds still seems crazy. What happens if you just make a trivially small app that just calls otrl_privkey_generate with appropriate arguments? Can you track down what's causing the problem? - Ian From twanfox@gmail.com Thu Apr 20 04:08:34 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 19 Apr 2006 22:08:34 -0500 Subject: [OTR-dev] Re: Libgcrypt slowness in generation of keys In-Reply-To: <20060420021129.GU1474@smtp.paip.net> References: <4446E8AC.5050007@gmail.com> <20060420021129.GU1474@smtp.paip.net> Message-ID: <4446FB32.5080003@gmail.com> Ian Goldberg wrote: > On Wed, Apr 19, 2006 at 08:49:32PM -0500, Twan Fox wrote: > >> All, >> >> I might've been slightly hasty in my prior posting. Seems a full clean >> and rebuild of my plugin brought the time down to something more >> reasonable (sub-60 seconds or so), though part of me is a little >> bothered still by the way it the program was made unresponsive during >> the entropy gathering phase of the key generation. >> > > If your UI thread is the one doing the key generation, then it will > naturally make the app unresponsive. Just do appropriate locking in a > separate thread. > > But 60 seconds still seems crazy. What happens if you just make a > trivially small app that just calls otrl_privkey_generate with > appropriate arguments? Can you track down what's causing the problem? > A trivially small app generates a key file pretty fast. I'd say around 5 seconds or so. It was a debug variant of the program, and for some reason, the libgcrypt program makes use of a set of dummy va_list args for one of it's calls when generating a key. Sends pop-up messages that kind of disrupt the process of generation and make accurate timekeeping difficult. I rebuilt the libraries (libgpg-error, libgcrypt, libotr) as a release version and compiled my plugin as a release version. Eliminating the pop-up warnings, I think it takes somewhere on the order of 10 seconds to generate a key for one account. Environment: Trillian |----> Plugins loaded: AIM/ICQ medium plugin Audio/Video Plugin (default) Trillian OTR plugin A pretty lean environment to test in. When I said 'sub-60 seconds,' I was making an out of my rear guestimation. It was no more than 60 seconds, but it was long enough for me to have noticed. I think 10 seconds is acceptable for key generation. I'm not sure what Gaim OTR's lag is on it. And, while I'd love to thread the key generation off into something behind the scenes, I'm not entirely sure just how, within Windows. :( Once again, this looks like it is programmer error, with the programmer being me. Thanks, Twan From rich.griffin@gmail.com Tue Apr 25 22:17:53 2006 From: rich.griffin@gmail.com (Rich Griffin) Date: Tue, 25 Apr 2006 17:17:53 -0400 Subject: [OTR-dev] OTR security analysis? Message-ID: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> All: Does anyone know what the action items are in response to the OTR security analysis (http://www.stanford.edu/~amo/otr_analysis.pdf)? Can these issues be addressed? Is there a roadmap for this? I'm not at all being critical, just very eager to enjoy the use of the nicest security system I've yet seen. Anxiously awaiting, -- Rich Griffin From asm@CS.Stanford.EDU Wed Apr 26 01:29:43 2006 From: asm@CS.Stanford.EDU (Andrew S. Morrison) Date: Tue, 25 Apr 2006 17:29:43 -0700 Subject: [OTR-dev] OTR security analysis? In-Reply-To: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> References: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> Message-ID: <20060426002942.GA22961@xenon.Stanford.EDU> --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm still around to discuss the analysis with anyone willing to listen to me :) --=20 Andrew S. Morrison asm@cs.stanford.edu (650) 575 9261 On 0, Rich Griffin wrote: > All: >=20 > Does anyone know what the action items are in response to the OTR > security analysis (http://www.stanford.edu/~amo/otr_analysis.pdf)? >=20 > Can these issues be addressed? Is there a roadmap for this? >=20 > I'm not at all being critical, just very eager to enjoy the use of the > nicest security system I've yet seen. >=20 > Anxiously awaiting, >=20 > -- > Rich Griffin >=20 > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFETr70F3ck4uEX/ycRAtk6AJ4x4MYBSLh9CYdGYq0KU055VU7TvACfcN8T 18RzhjbY5Hlbn4yvfTtvrvs= =cgvc -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From me@nikita.ca Wed Apr 26 04:53:02 2006 From: me@nikita.ca (Nikita Borisov) Date: Tue, 25 Apr 2006 22:53:02 -0500 Subject: [OTR-dev] OTR security analysis? In-Reply-To: <20060426002942.GA22961@xenon.Stanford.EDU> References: <2984fd620604251417g5e7e2760u96a0a225d88d4e2d@mail.gmail.com> <20060426002942.GA22961@xenon.Stanford.EDU> Message-ID: <16f0378d0604252053x1d1ace27r3dfd5f4c8dea8602@mail.gmail.com> >From what I read in the analysis, the only dangerous attack is the message integrity failure. But from what Ian has said, the libotr implementation is secure, but the spec is not. So it seems that the major action item is to rev the spec to match the implementation. - Nikita On 4/25/06, Andrew S. Morrison wrote: > I'm still around to discuss the analysis with anyone willing to listen to > me :) > > -- > Andrew S. Morrison > asm@cs.stanford.edu > (650) 575 9261 > > > On 0, Rich Griffin wrote: > > All: > > > > Does anyone know what the action items are in response to the OTR > > security analysis (http://www.stanford.edu/~amo/otr_analysis.pdf)? > > > > Can these issues be addressed? Is there a roadmap for this? > > > > I'm not at all being critical, just very eager to enjoy the use of the > > nicest security system I've yet seen. > > > > Anxiously awaiting, > > > > -- > > Rich Griffin > > > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev@lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > From twanfox@gmail.com Fri Apr 28 19:29:35 2006 From: twanfox@gmail.com (Twan Fox) Date: Fri, 28 Apr 2006 13:29:35 -0500 Subject: [OTR-dev] app_find subroutine for otrl_context_find Message-ID: <44525F0F.6050603@gmail.com> Greetings, Drawing ever closer to a full Trillian plugin, I find myself wanting for an application-based extension to the otrl_context_find() function. What I mean by that is simple, and similar to how the otrl_message_receiving() and _sending() functions accept both a new_context function and app_data structure in the event a new context is created, to allow the app_data and app_data_free members of the ConnContext structure to be populated. The otrl_context_find() should take a 2 additional arguments, a function reference that points to a search subroutine and a data structure that holds data the additional search routine can use to match context to app_data. The returned value is likely to be the located ConnContext pointer. If there is merit in the idea of extending the otrl_context_find() function in that way, and it is necessary, I can draft up some code to make the appropriate call. It is just so much simpler than attempting to walk the userstate->context_root list myself and search through each app_data structure for what I want. Alternatively, I suppose that I can just write the subroutine and call it myself if otrl_context_find() returns nothing. Just seeking feedback. Thanks, Twan