Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Mon, Oct 01, 2012 at 05:35:06PM +, Jacob Appelbaum wrote: Thibaut VARENE: On Mon, Oct 1, 2012 at 7:24 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did libotr5, per soname. other OTR software get ported to 4.x already? Or will it just break? libotr5 has been in experimental for a month now. If packages haven't been updated, they'll break, since libotr5 conflicts with libotr2. They'll need a rebuild against the new library package anyway. Wait: libotr2 should *not* conflict with libotr5. The *-dev* packages should conflict, since they provide conflicting header files, and the *-bin* packages similarly. But the runtime libotr2 and libotr5 packages should be able to coexist, no? This would certainly prevent breakage of existing packages. - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Hi, I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it appears the calls exit() issue has moved to pidgin-otr. I don't know enough of pidgin plugin system to know whether this is a false positive or not, but I thought I might blow the whistle anyway... HTH Thibaut X: pidgin-otr: shlib-calls-exit usr/lib/pidgin/pidgin-otr.so N: N:The listed shared library calls the C library exit() or _exit() N:functions. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did other OTR software get ported to 4.x already? Or will it just break? Interested, because I hadn't yet uploaded libotr3, and if most software has been ported in debian, then I would just skip that and push libotr-4 and pidgin-otr-4 into fedora rawhide. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Mon, Oct 1, 2012 at 7:24 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did libotr5, per soname. other OTR software get ported to 4.x already? Or will it just break? libotr5 has been in experimental for a month now. If packages haven't been updated, they'll break, since libotr5 conflicts with libotr2. They'll need a rebuild against the new library package anyway. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Thibaut VARENE: On Mon, Oct 1, 2012 at 7:24 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did libotr5, per soname. other OTR software get ported to 4.x already? Or will it just break? libotr5 has been in experimental for a month now. If packages haven't been updated, they'll break, since libotr5 conflicts with libotr2. They'll need a rebuild against the new library package anyway. I think this has already been discussed but... I think this is a rather terrible idea without hearing from most, if not all, of the app developers. I'd suggest that libotr2 and libotr5 are both in the archive and that they *conflict* as Debian packages. We should try to convince the developers to release new versions but if they can't or don't - an older libotr2 package shouldn't simply revert all communications to plaintext. A broken package will probably cause that kind of issue and that is _far_ worse than OTRv3 handshakes... Is there a list of packages that will be broken by this change? Has anyone reached out to those developers? All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
I looked at the -S output. Basically, I built each way, and then did: rm auth.lo auth.o gmake -n | sed -e 's/ -c / -S /' | sh which put the source in auth.o (and then the link failed). Compilation with -O1/-O2 and with/without the gcc hardening are at: http://www.lexort.com/pkgsrc/libotr/ The files are somewhat similar in size, but otrl_auth_handle_revealsig is only about 1/4 as long in the O2/with case, and it seems it just left out a lot of the function. So this is 99.9% clearly a gcc bug. Using built-in specs. Target: i386--netbsdelf Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.72 --host=i386--netbsdelf --target=i386--netbsdelf --enable-__cxa_atexit Thread model: posix gcc version 4.1.3 20080704 prerelease (NetBSD nb3 2007) pgpwaOOUYsjQ7.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Ian Goldberg i...@cypherpunks.ca writes: On Mon, Sep 03, 2012 at 06:40:08PM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: OK, then I guess the thing to do is just to turn off hardening for that build environment? [I believe the hardening is only actually enabled when -O2 is on, regardless of whether the compiler options are specified or not, so turning it to -O1 or -O0 will also turn off hardening, so you may as well just turn off the hardening and leave it at -O2.] I was going to leave on SSP and use -O1, but if SSP really needs -O2, I might as well use -O2 and no SSP. That's my understanding. I'll look into this more; probably when libotr is really released and I update - then I can point people to it easily. I plan to just do that for all of pkgsrc to start; it doesn't seem that harmful (or -O1 didn't). There's still a tiny chance there's something sick going on where the code is buggy and with SSP things can be proved to always overwrite so it just returns, and thus the compiler is right. But I'll give that only 2 in 10^4, esp. since I'd expect an abort if SSP triggers. If that were the case, I'd expect later versions of gcc to behave the same way, though? Well, I guess not necessarily. But if gcc 4.1.3 is _correctly_ optimizing away a good chunk of the whole function, then something is wrong in the common case, and valgrind would have reported it, I'd think? Yes, that's why I am giving that scenario (buggy code, defensible gcc) vanishingly small odds. It would be really nice to have a test case run with make check. Perhaps just creating two contexts and having them communicate and see if it ends up with transferred plaintext. Then it's much easier to test this. pgpGyRD6a75G5.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Mon, Sep 03, 2012 at 07:40:54PM -0400, Greg Troxel wrote: I'll look into this more; probably when libotr is really released and I update - then I can point people to it easily. OK. My plan is to release it for real tomorrow morning. It would be really nice to have a test case run with make check. Perhaps just creating two contexts and having them communicate and see if it ends up with transferred plaintext. Then it's much easier to test this. Fair enough. In the git repo, there's a test_suite directory that contains code much like that, but it also tests interoperability with past versions of OTR, tests Alice and/or Bob running multiple clients at once, etc. It's not in the tarball, though; perhaps it (or a simplified version) should be. Not for tomorrow, though. Thanks, - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Sun, Sep 02, 2012 at 10:27:04AM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: On Sun, Sep 02, 2012 at 09:38:21AM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: Can you confirm that the 1.5.0 in pkgsrc already has the above patch applied to it? No, it doesn't. I can add it. But I assumed 1.5.0 was a real release and if there was a bug there would have been another real release of libgcrypt. Well that's certainly a clue. But the 1.5.0 release I see here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 *does* already have the above patch applied. Yours doesn't? Very odd... Sorry, I thought you meant that I would have to carry that as a local patch. I looked, and the 1.5.0 release tarball already has that change. I rebuilt, and ran the tests and they all passed. Ah, good, then. So that's not the issue. We should try to start an OTR session between us to track this down. (Details off-list.) Thanks, - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
One of my paranoid friends showed up, and the new library did not work. I did 'start private' and got a malformed message. I then changed settings to 'default' (vs 'always') and then to 'never', but still was not able to interoperate, even with OTR disabled (the other person probably is setup to force OTR, as I had been before). The other end is likely Adium. (20:29:09) Attempting to start a private conversation with john...@example.com... (20:29:10) Error setting up private conversation: Malformed message received (20:29:15) Attempting to start a private conversation with john...@example.com/john-does-puter... (20:29:16) Error setting up private conversation: Malformed message received (20:29:23) Attempting to start a private conversation... (20:29:23) g...@example.com/alpha: can you hear me w/o otr? (20:29:24) Error setting up private conversation: Malformed message received Also, in the pidgin chat window, i have multiple tabs. Two people don't do OTR, and that otr tab has 'start', other things greyed, a separator, their jid, and 'not private'. That's all fine. The other person has done OTR (johndoe@ above), and is set to 'no otr', and looks the same - but has the most recently looked at of the other parties' JID!!! It seems that it's enough to select the tab and come back, and that changes the JID in the OTR menu for the otr-troubled contact. pgp8KaNHmDHKa.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Sat, Sep 1, 2012 at 6:22 PM, Ian Goldberg i...@cypherpunks.ca wrote: On Sat, Sep 01, 2012 at 11:55:33AM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: This looks a lot like one of you is logged in more than once. Could this possibly be the case? (If the other person is using Adium, you'd have fallen back to the OTRv2 protocol, so you don't get the protection from multiple logins that the new protocol added.) That could have been true, but I've been doing otr (v2 obviously) with this person for years, and not having trouble. I just picked someone else, and tried to initiate. That person shows (in pidgin) as being logged in only once. I got (11:52:08) Error setting up private conversation: Malformed message received same as before. It would be nice to print out the malformed message, but I don't know how (other than reading the source and changing the code). Weird. I believe if you run pidgin -d, it will show all of the Jabber messages it's sending and receiving. Give that a try? Also, in the pidgin chat window, i have multiple tabs. Two people don't do OTR, and that otr tab has 'start', other things greyed, a separator, their jid, and 'not private'. That's all fine. The other person has done OTR (johndoe@ above), and is set to 'no otr', and looks the same - but has the most recently looked at of the other parties' JID!!! It seems that it's enough to select the tab and come back, and that changes the JID in the OTR menu for the otr-troubled contact. I'll need to look into this. Is it replicatable on your end? It seems to be, at least with this person. setting otr to 'use default' fixes the problem. unchecking 'use default' and then unchecking 'enable' makes the OTR menu go away. But then selecting someone else's tab and then coming back makes the OTR menu re-appear, with the wrong jid. Yup, I've replicated it here, too, and I see the problem in the source. It shouldn't be too tough to fix, but I'm thinking Target: 4.0.1 for that one. Would the various packagers prefer a last-last-minute change to 4.0.0, or just to put this fix into the next version? As far as I (debian/ubuntu) is concerned, I'll let 4.0.0 live in experimental for a little while so at to leave time for dependencies to upgrade. Don't feel extraordinarily urged to push fixes tho. I'd rather upload a rock solid 4.0.1 to unstable a bit later. Cheers -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Fri, Aug 31, 2012 at 2:09 AM, Ian Goldberg i...@cypherpunks.ca wrote: On Thu, Aug 30, 2012 at 06:33:48PM -0400, Paul Wouters wrote: On Thu, 30 Aug 2012, Ian Goldberg wrote: So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. Since they're using the libotr 3 API, shouldn't they require libotr == 3? And the new libotr package will supply libotr == 4, and the new pidgin-otr package will require libotr == 4? (As opposed to = 4?) I think all that is relatively pointless. Ian: libotr2 will no longer be actively maintained/developed when libotr5 is released, right? If so, I plan to move on with the current state of things in Debian: libotr 4.0.0 (source package providing libotr5, -dev and -bin) will *replace* libotr 3.2.1 (source package providing libotr2, -dev and -bin) at which point packages that still require libotr2 will simply break, and their respective maintainers will have to take action. I don't think libotr has that many dependencies nor is that a critical package that it warrants the maintaining of 2 different versions over the lifetime of major linux and BSD distributions just for the sake of easing dependencies' transitions. At least for Debian, that's how things will be done. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Fri, Aug 31, 2012 at 2:14 PM, Ian Goldberg i...@cypherpunks.ca wrote: On Fri, Aug 31, 2012 at 12:43:58PM +0200, Thibaut VARENE wrote: Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. Since they're using the libotr 3 API, shouldn't they require libotr == 3? And the new libotr package will supply libotr == 4, and the new pidgin-otr package will require libotr == 4? (As opposed to = 4?) I think all that is relatively pointless. Ian: libotr2 will no longer be actively maintained/developed when libotr5 is released, right? If there's a security release needed, I'll consider pushing out a 3.x security update for at least a little while, but I haven't set a firm timeline policy or anything like that. OK. That confirms what I was expecting. If so, I plan to move on with the current state of things in Debian: libotr 4.0.0 (source package providing libotr5, -dev and -bin) will *replace* libotr 3.2.1 (source package providing libotr2, -dev and -bin) at which point packages that still require libotr2 will simply break, and their respective maintainers will have to take action. Isn't that impolite to those maintainers? Or will you give them a heads-up in advance? The notion of politeness in FOSS makes me chuckle ;-) The heads up they have is 1) (for upstream) your release announcement: after all, they're writing code that uses your library, so they should know what they have to do already; and 2) (as far as Debian maintainers are concerned), the upload of the new version of the library to 'experimental', which has already happened and is pending validation. It appears people are already well aware of the upcoming change too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685664 Again, we're not breaking libc here. From what I read, I don't think the new version of libotr will impose a complete rewrite of dependent software, right? ;-P I don't think libotr has that many dependencies nor is that a critical package that it warrants the maintaining of 2 different versions over the lifetime of major linux and BSD distributions just for the sake of easing dependencies' transitions. At least for Debian, that's how things will be done. Sounds reasonable. I plan to build the test releases of 4.0.0 today, including the patch to fix the exit() issue, and an extremely minor remove whitespace at the ends of a handful of lines source cleanup patch. OK. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Fri, Aug 31, 2012 at 03:38:59PM +0200, Thibaut VARENE wrote: I plan to build the test releases of 4.0.0 today, including the patch to fix the exit() issue, and an extremely minor remove whitespace at the ends of a handful of lines source cleanup patch. They're built. http://otr.cypherpunks.ca/libotr-4.0.0.tar.gz http://otr.cypherpunks.ca/libotr-4.0.0.tar.gz.asc http://otr.cypherpunks.ca/pidgin-otr-4.0.0.tar.gz http://otr.cypherpunks.ca/pidgin-otr-4.0.0.tar.gz.asc http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/libotr;a=shortlog;h=refs/heads/master http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/pidgin-otr;a=shortlog;h=refs/heads/master http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.0-0.exe http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.0-0.exe.asc http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.0.zip http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.0.zip.asc I'll be updating the website and sending out the official announcment on Tuesday, as previously stated. Thanks, all! - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
[Rearranging...] On Thu, Aug 30, 2012 at 01:55:16PM -0400, Greg Troxel wrote: (Sorry if I sound cranky; I'm not really trying to complain about how things are, just to point out that the questions I'm asking are the key questions one needs to have answered to decide what to do, and that they are missing from the pre-release announcement.) Oh, they're good questions. I guess my lack of experience with pkgsrc (and *bsd in general) is showing. :-p Ian Goldberg i...@cypherpunks.ca writes: On Mon, Aug 27, 2012 at 08:22:17PM -0400, Greg Troxel wrote: ok, but do the current releases of all those build against libotr-4? If so, there is no issue in pkgsrc (even if they were all packaged, which they're not). If not, then there are bigger problems. No, this is a major version number increment, which means that the API and ABI have changed from the application's point of view. That's why That doesn't all logically follow (beyond ABI). It seems you mean major version number increment, without backwards-compatible API support (which can be coped with), but that was not at all clear earlier. Fair enough. Yes, libotr follows the bump major when ABI changes incompatible; bump minor when ABI changes in a backwards-compatible way; bump sub when implementation, but not ABI, changes convention. debian/ubuntu/etc. add the so major number to the package name: xchat-otr and friends can still depend on libotr2 for a while, until they update their code, while the new pidgin-otr can depend on libotr5. Surely pkgsrc supports some equivalent notion? Yes - when upstream packages don't provide API back-compatibility, then there are packages with the version number in the name (not a shlib number). Or one without, that's normal, and one or more with. For unstable upstreams, there is typically always a version. OK. So then: are the set of files installed by these two versions distinct, so that they can not conflict, or is a system limited to at most one? Depending on how it's packaged, the runtime packages may be disjoint (the shared lib has a different name in each version), but the -dev package (with the header files) has the same filenames, so you'd be limited to installing one -dev package at a time. But it may be that only pidgin-otr in pkgsrc uses libotr; if so it's easier to just upgrade both at once and leave the old libotr behind. That would indeed be the easiest thing, if true. Do the old libotr and the new interoperate? Specifically, if one person is running the current pidgin-otr/libotr, and another both new ones, can they still talk? Yes. The new one will just fall back to the old protocol when speaking to old clients. - Ian PS: I've decided that Tuesday Sep 4 will be the release day, so that it's not buried in the long weekend. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Ian Goldberg i...@cypherpunks.ca writes: Oh, they're good questions. I guess my lack of experience with pkgsrc (and *bsd in general) is showing. :-p Perhaps, but I don't think my questions are bsd-specific - it's more about any system that has to manage lots of software maintained by third parties and get depdendencies right. The issues with pkgsrc and e.g ubuntu are really the same, and the approaches seem to be broadly similar, with just details different. Fair enough. Yes, libotr follows the bump major when ABI changes incompatible; bump minor when ABI changes in a backwards-compatible way; bump sub when implementation, but not ABI, changes convention. Glad to hear it - and that's a pretty hard rule out there for shlib versioning. Depending on how it's packaged, the runtime packages may be disjoint (the shared lib has a different name in each version), but the -dev package (with the header files) has the same filenames, so you'd be limited to installing one -dev package at a time. The notion of runtime and dev packages is Linux-specific. In pkgsrc, the emphasis is on building a single package from source, because there are such a large number of operating systems, os versions, and binary architectures (many of which lack the critical mass to have people building binaries and putting them up for download, which really only happens for the most popular combinations). So building split binary packages with some parts of a package and not other parts isn't really done much, unless there's a really good reason. Avoiding installing header files to save disk space is usually not considered a good reason :-), but avoiding the utility program that drags in qt is. But that answers my question - some filenames overlap, so the packages have to conflict (if we have both at once). But it may be that only pidgin-otr in pkgsrc uses libotr; if so it's easier to just upgrade both at once and leave the old libotr behind. That would indeed be the easiest thing, if true. I didn't quite say this, but it would have been nice if the new package supported the old API (I say that not caring much about ABI). As libraries become more and more widely used, that kind of stability becomes more important. Conversely, I think there's a bias against depending on things that don't have that property, because it requires synchronous updates, or to have earlier releases of depending packages that can autoconf/switch. But I realize time is limited and otr has few depending packages (even if it's 10, that's few). Do the old libotr and the new interoperate? Specifically, if one person is running the current pidgin-otr/libotr, and another both new ones, can they still talk? Yes. The new one will just fall back to the old protocol when speaking to old clients. Glad to hear it - that's obviously the critical upgrade interoperability issue, since it can't be worked around locally in any sane manner. PS: I've decided that Tuesday Sep 4 will be the release day, so that it's not buried in the long weekend. Thanks for the warning; I may be able to have an update for pkgsrc ready to go. Thanks for listening - I'm done ranting for now and have enough info to prepare the update. pgp0JDTxH1nBs.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Wed, 29 Aug 2012, Ian Goldberg wrote: Indeed, that's what Thibaut noticed, and I sent a patch to correct already. Oh, did not realise it was the same issue... I'm looking at providing libotr3 and libotr packages, as I don't think all the apps will port their code to the new library in reasonable time. Why libotr3? It's version 4 of the library, and the soname is 5. On Debian-like systems, the old package was libotr2, and the new one will be libotr5. The version of the old libotr is 3.x.x, so the compat package would then become libotr3-3.x. (as to not conflict with libotr-4.x.x) Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Thu, 30 Aug 2012, Ian Goldberg wrote: Depending on how it's packaged, the runtime packages may be disjoint (the shared lib has a different name in each version), but the -dev package (with the header files) has the same filenames, so you'd be limited to installing one -dev package at a time. But it may be that only pidgin-otr in pkgsrc uses libotr; if so it's easier to just upgrade both at once and leave the old libotr behind. That would indeed be the easiest thing, if true. In Fedora/EPEL libort is used by: [paul@thinkpad ~]$ repoquery -qa --whatrequires libotr bitlbee-otr-0:3.0.4-3.fc17.x86_64 bitlbee-otr-0:3.0.5-1.fc17.x86_64 climm-0:0.7.1-4.fc17.x86_64 irssi-otr-0:0.3-5.fc17.x86_64 kdenetwork-kopete-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-7:4.8.5-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.3-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.5-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.5-1.fc17.x86_64 libotr-devel-0:3.2.1-1.fc17.i686 libotr-devel-0:3.2.1-1.fc17.x86_64 mcabber-0:0.10.1-3.fc17.x86_64 pidgin-otr-0:3.2.1-1.fc17.x86_64 xchat-otr-0:0.3-5.fc17.x86_64 So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Do the old libotr and the new interoperate? Specifically, if one person is running the current pidgin-otr/libotr, and another both new ones, can they still talk? Yes. The new one will just fall back to the old protocol when speaking to old clients. Just to clarify (and confirm I'm right), the above listed software cannot just use libotr-4. They need to be fixed for libotr-4. However, code fixed to use libotr-4, can talk to clients based on libotr-3 and libotr-4. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Thu, Aug 30, 2012 at 05:02:57PM -0400, Paul Wouters wrote: In Fedora/EPEL libort is used by: [paul@thinkpad ~]$ repoquery -qa --whatrequires libotr bitlbee-otr-0:3.0.4-3.fc17.x86_64 bitlbee-otr-0:3.0.5-1.fc17.x86_64 climm-0:0.7.1-4.fc17.x86_64 irssi-otr-0:0.3-5.fc17.x86_64 kdenetwork-kopete-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-7:4.8.5-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.3-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.5-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.5-1.fc17.x86_64 libotr-devel-0:3.2.1-1.fc17.i686 libotr-devel-0:3.2.1-1.fc17.x86_64 mcabber-0:0.10.1-3.fc17.x86_64 pidgin-otr-0:3.2.1-1.fc17.x86_64 xchat-otr-0:0.3-5.fc17.x86_64 So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Do the old libotr and the new interoperate? Specifically, if one person is running the current pidgin-otr/libotr, and another both new ones, can they still talk? Yes. The new one will just fall back to the old protocol when speaking to old clients. Just to clarify (and confirm I'm right), the above listed software cannot just use libotr-4. They need to be fixed for libotr-4. However, code fixed to use libotr-4, can talk to clients based on libotr-3 and libotr-4. That is correct. (And to clients based on any of the independent implementations of the OTRv3 protocol in languages like Scheme, Python, Javascript, etc.) - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Thu, 30 Aug 2012, Ian Goldberg wrote: So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. As I am the pidgin-otr maintainer, I am going to ensure it is released as an update at the same time as libotr gets bumped to 4. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Thu, Aug 30, 2012 at 06:33:48PM -0400, Paul Wouters wrote: On Thu, 30 Aug 2012, Ian Goldberg wrote: So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. Since they're using the libotr 3 API, shouldn't they require libotr == 3? And the new libotr package will supply libotr == 4, and the new pidgin-otr package will require libotr == 4? (As opposed to = 4?) As I am the pidgin-otr maintainer, I am going to ensure it is released as an update at the same time as libotr gets bumped to 4. Perfect, thanks! - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Wed, Aug 29, 2012 at 03:40:19PM -0400, Paul Wouters wrote: On Mon, 27 Aug 2012, Ian Goldberg wrote: OK, 4.0.0-rc3 is ready. **Please give it a try, and give feedback!** So far, seems good. I noticed a warning, which is not new to libotr-4, but might be good to look at: libotr.x86_64: W: shared-lib-calls-exit /usr/lib64/libotr.so.5.0.0 exit@GLIBC_2.2.5 That's controversial at least. Is there a well founded reason for this? The call is in otrl_init() when detecting incomptabile versions. Exiting the problem, instead of just having the non-functional plugin seems a little harsh? Indeed, that's what Thibaut noticed, and I sent a patch to correct already. Please try the patch and let us know whether it makes the problem go away for you as well. I intend to merge it into master before 4.0.0 release (but have not yet done so). (Packagers: don't yet distribute it, but do check that it builds with your packaging system -- especially the new gcc/ld-hardening CFLAGS/LDFLAGS. Do note that the libotr so major number is now 5.) I'm looking at providing libotr3 and libotr packages, as I don't think all the apps will port their code to the new library in reasonable time. Why libotr3? It's version 4 of the library, and the soname is 5. On Debian-like systems, the old package was libotr2, and the new one will be libotr5. Thanks, - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Tue, Aug 28, 2012 at 2:24 AM, Ian Goldberg i...@cypherpunks.ca wrote:
Indeed, otrl_init(ver_major, ver_minor, ver_sub) calls exit(1) if the
passed version numbers are incompatible with the library's actual
version.
Seeing as how it's intended to be called from this macro:
#define OTRL_INIT do { \
otrl_init(OTRL_VERSION_MAJOR, OTRL_VERSION_MINOR, OTRL_VERSION_SUB); \
} while(0)
I suppose we could change otrl_init to return an error code, and change
the *macro* to call exit() upon otrl_init returning an error. Although
technically the ABI would change, the API wouldn't.
As long as the macro itself isn't used in the library, this should indeed work.
I will consider this for inclusion before release.
Thanks for the note!
You're welcome!
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Thibaut VARENE vare...@debian.org writes: On Tue, Aug 28, 2012 at 2:16 AM, Greg Troxel g...@ir.bbn.com wrote: In pkgsrc, libotr is simply libotr. Two questions: will just libotr.pc be installed, but with the new versions? If so, I don't see any reason to call this libotr5, but rather just libotr. Is there any reason to have both the old version and the new version simultaneously packaged? It seems the only real user of libotr is pidgin-otr, and hopefully Not really, no: apt-cache rdepends libotr2 libotr2 Reverse Depends: python-otr-dbg python-otr psi-plus-plugins pidgin-otr mcabber libotr2-dev libotr2-bin kopete xchat-otr irssi-plugin-otr bitlbee-plugin-otr ok, but do the current releases of all those build against libotr-4? If so, there is no issue in pkgsrc (even if they were all packaged, which they're not). If not, then there are bigger problems. pgpQ41rXHO9J6.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Thibaut VARENE vare...@debian.org writes: On Tue, Aug 28, 2012 at 2:16 AM, Greg Troxel g...@ir.bbn.com wrote: In pkgsrc, libotr is simply libotr. Two questions: will just libotr.pc be installed, but with the new versions? If so, I don't see any reason to call this libotr5, but rather just libotr. Is there any reason to have both the old version and the new version simultaneously packaged? It seems the only real user of libotr is pidgin-otr, and hopefully Not really, no: apt-cache rdepends libotr2 libotr2 Reverse Depends: python-otr-dbg python-otr psi-plus-plugins pidgin-otr mcabber libotr2-dev libotr2-bin kopete xchat-otr irssi-plugin-otr bitlbee-plugin-otr ok, but do the current releases of all those build against libotr-4? If so, there is no issue in pkgsrc (even if they were all packaged, which they're not). If not, then there are bigger problems. pgpDfE6tTM1IS.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
