Community
Participate
Working Groups
Smack 4 includes various bug fixes including security related ones. Note that Smack 4 is a new major release with some API changes. I would be happy to assist Eclipse ECF in adopting the new API. Smack 4 is also an OSGi bundle deployed on maven central, so it may be possible to drop the Smack source code, found in protocols/bundles/org.jivesoftware.smack/, from the ECF repository.
Hi Florian, Smack 4 will make it into ECF fastest, if assisting includes providing a patch or Gerrit Pull Request. :-)
I know and I would be happy to help. But I don't have enough free time to prepare the commit all by myself. All I can offer is my assistance as Smack maintainer. This ticket primary purpose is to serve as reminder that ECF is using on old insecure Smack version as in-tree code, should should eventually get updated and replaced by the OSGi bundle Smack 4. Side note: #smack (freenode) is the ideal place to ask questions that may arise when somebody tries to update Smack in ECF.
(In reply to Florian Schmaus from comment #2) > I know and I would be happy to help. But I don't have enough free time to > prepare the commit all by myself. > > All I can offer is my assistance as Smack maintainer. This ticket primary > purpose is to serve as reminder that ECF is using on old insecure Smack > version as in-tree code, should should eventually get updated and replaced > by the OSGi bundle Smack 4. > > Side note: #smack (freenode) is the ideal place to ask questions that may > arise when somebody tries to update Smack in ECF. Can the security relevant changes be back-ported or maybe even cherry-picked to our 3.x branch of Smack?
Everything can be backported if you are willing to put a required amount of work into it. But I doubt that it is as easy as cherry-picking. And I think that it would be easier to update to Smack 4. BTW, the related CVEs are: - CVE-2014-0363 - CVE-2014-0364
(In reply to Florian Schmaus from comment #5) > Everything can be backported if you are willing to put a required amount of > work into it. But I doubt that it is as easy as cherry-picking. And I think > that it would be easier to update to Smack 4. > > BTW, the related CVEs are: > - CVE-2014-0363 > - CVE-2014-0364 FTR: This will also require us to file a new CQ if we (ECF) want to include Smack 4.
I took a look at the ecf source in order to determine the best approach how to update Smack in ECF. I'd like to unbundle Smack from the ecf source, which is currently bundled in protocols/bundles/org.jivesoftware.smack, and depend on the maven artifacts of Smack instead (which are also OSGi components). But how do I configure Smack as maven dependency at org.eclipse.ecf.provider.xmpp? I couldn't find anywhere in the ECF source an example where one of the ECF project declares dependencies on maven artifacts? Is this even possible?
(In reply to Florian Schmaus from comment #7) > I took a look at the ecf source in order to determine the best approach how > to update Smack in ECF. I'd like to unbundle Smack from the ecf source, > which is currently bundled in protocols/bundles/org.jivesoftware.smack, The source in org.jivesoftware.smack is not ECF source, rather it's Smack source. There are no dependencies to ECF code in the smack source. >and > depend on the maven artifacts of Smack instead (which are also OSGi > components). Are the Smack artifacts OSGi components now (with proper manifest, etc)? Prior to Smack 4 they were not. Could you please point to them so they could be examined? > > But how do I configure Smack as maven dependency at > org.eclipse.ecf.provider.xmpp? I couldn't find anywhere in the ECF source an > example where one of the ECF project declares dependencies on maven > artifacts? Is this even possible? It's probably possible, but we don't currently do it. With third-party dependencies and the EF IP process the typical usage pattern is to either a) reference bundles that have been placed in the Orbit project https://www.eclipse.org/orbit/ OR to build the third-party library into a bundle and distribute with the project (which is what ECF has been doing with < Smack 4, since these older versions of Smack were not bundleized. I'm not sure what the usage rules are WRT directly referencing Maven artifacts (e.g. via Maven Central). Although I don't really have a technical objection, I don't even know if we would be allowed to do that, given the IP/third-party lib usage rules. Also, we currently are using Buckminster to build ECF (including the Smack 3.3 bundle), and although I understand that Buckminster can reference/use Maven artifacts just fine, I don't currently know how this is done.
(In reply to Scott Lewis from comment #8) > (In reply to Florian Schmaus from comment #7) > > I took a look at the ecf source in order to determine the best approach how > > to update Smack in ECF. I'd like to unbundle Smack from the ecf source, > > which is currently bundled in protocols/bundles/org.jivesoftware.smack, > The source in org.jivesoftware.smack is not ECF source, rather it's Smack > source. There are no dependencies to ECF code in the smack source. Hmm? I never said that smack depends on ECF code. I want to `git rm -rf protocols/bundles/org.jivesoftware.smack`. > Are the Smack artifacts OSGi components now (with proper manifest, etc)? > Prior to Smack 4 they were not. Could you please point to them so they > could be examined? Sure, I always eager for feedback regarding Smack's OSGi compatibility. You can download the jar's from maven central: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.igniterealtime.smack%22 > I'm not sure what the usage rules are WRT directly referencing Maven > artifacts (e.g. via Maven Central). Although I don't really have a > technical objection, I don't even know if we would be allowed to do that, > given the IP/third-party lib usage rules. I was once contacted by an Eclipse Foundation employee (?) asking how we handle contributions to Smack. It's such a pity that Eclipse is so strict about using open source 3rd party libraries, that you even resort to bundling libraries, which is a bad practice. The version of Smack in ECF has major security bugs and you can't easily update.
(In reply to Florian Schmaus from comment #9) > (In reply to Scott Lewis from comment #8) > > (In reply to Florian Schmaus from comment #7) > > > I took a look at the ecf source in order to determine the best approach how > > > to update Smack in ECF. I'd like to unbundle Smack from the ecf source, > > > which is currently bundled in protocols/bundles/org.jivesoftware.smack, > > The source in org.jivesoftware.smack is not ECF source, rather it's Smack > > source. There are no dependencies to ECF code in the smack source. > > Hmm? I never said that smack depends on ECF code. I want to `git rm -rf > protocols/bundles/org.jivesoftware.smack`. You said: 'unbundle Smack from the ecf source'. There is no ecf source in the Smack bundles...just necessary OSGi metadata not included in Smack 3.3 and previous. I understand what you were saying now though. > > > Are the Smack artifacts OSGi components now (with proper manifest, etc)? > > Prior to Smack 4 they were not. Could you please point to them so they > > could be examined? > > Sure, I always eager for feedback regarding Smack's OSGi compatibility. You > can download the jar's from maven central: > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.igniterealtime.smack%22 > > > I'm not sure what the usage rules are WRT directly referencing Maven > > artifacts (e.g. via Maven Central). Although I don't really have a > > technical objection, I don't even know if we would be allowed to do that, > > given the IP/third-party lib usage rules. > > I was once contacted by an Eclipse Foundation employee (?) asking how we > handle contributions to Smack. This was probably an EF employee, following up on our request to use a previous version of Smack (in EF parlance requests are known as a CQ...or contribution questionnaires). As part of the CQ approval process, the EF investigates third party library provenance and contribution handling policies...that's probably what they were doing. It's such a pity that Eclipse is so strict > about using open source 3rd party libraries, that you even resort to > bundling libraries, which is a bad practice. I agree that it's not a wonderful practice, but previously (i.e. Smack 3.3 and below) it was necessary to bundleize things in order to run in OSGi environment (because the libraries didn't have OSGi meta-data with them, so someone had to add it. WRT EF practices...I might agree with some of what you say, but we are subject to the EF rules. OTOH, the ECF project does maintain github repos as well https://github.com/ECF Which don't necessarily have to comply with all EF usage rules >The version of Smack in ECF has > major security bugs and you can't easily update. This would be much easier and pretty automatic from a consumer point of view if: a) previous versions of Smack were bundleized (making it unnecessary for us to do so) b) Major revisions (along with breaking API changes) weren't introduced...e.g. Smack 3.3 -> 4...requiring code changes in our dependent code (i.e. org.eclipse.ecf.provider.xmpp). So although again I agree it would be nicer for us and consumers if third party dependencies were IP-managed a little less loosely by the EF, there are multiple things involved in this case. I will tell you what. I will ask on the rt-pmc mailing list, and with the Eclipse Management Organization, about the use/dependence upon bundles exposed from Maven central for Smack 4.0. I'm an old-timer and the usage rules around such things may have been updated...allowing for such dependencies. If it is allowed somehow I'm pretty sure that with your help and guidance we/ECF could make the necessary code changes in the provider (in order to use Smack 4.0) and setup our build to use and deploy such dependencies. I'm not sure if you are on the rt-pmc mailing list, but if you want to be here's the page: https://dev.eclipse.org/mailman/listinfo/rt-pmc
For the record, Scott's mail to rt-pmc: http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg04045.html Any news about the CQ regarding Smack 4's orbit inclusion?
(In reply to Florian Schmaus from comment #11) > For the record, Scott's mail to rt-pmc: > http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg04045.html > > Any news about the CQ regarding Smack 4's orbit inclusion? Well, if I open a CQ for Smack 4, it won't be for Orbit inclusion but rather only for ECF usage. The reason for this is I'm not an Orbit committer, and I'm not personally willing or currently able to do the work for distribution via Orbit. If you or others are willing to contribute to Orbit that would be great and I would be happy to use it. Also, I'm sure the existing Orbit committers would welcome your or others participation/involvement as Orbit committers. But WRT Smack 4 CQ (for ECF), could you please provide up-to-date pointers to both the current 4.x binaries and associated source code? With those in hand (of correct/desired version) I will open a CQ for ECF usage, and begin the changes to the ECF provider to use Smack 4.x rather than 3.3.
Download; http://www.igniterealtime.org/downloads/index.jsp#smack Source: https://github.com/igniterealtime/Smack/tree/4.0.5 > Also, I'm sure the existing Orbit committers would welcome your... I also have zero interest in maintaining a second artifact repository besides maven central.
(In reply to Florian Schmaus from comment #13) > Download; http://www.igniterealtime.org/downloads/index.jsp#smack > Source: https://github.com/igniterealtime/Smack/tree/4.0.5 > > > Also, I'm sure the existing Orbit committers would welcome your... > > I also have zero interest in maintaining a second artifact repository > besides maven central. It is not about having a second repo but having a repo with guaruanteed IP clearance.
(In reply to Florian Schmaus from comment #13) > Download; http://www.igniterealtime.org/downloads/index.jsp#smack > Source: https://github.com/igniterealtime/Smack/tree/4.0.5 > I've downloaded both the 4.0.5 binary and source and created a new CQ for Smack 4.0.5: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8887 Florian I expect that eventually the Eclipse Foundation legal team will need to contact someone on the Smack 4 team (you?) to ask questions about the handling of provenance for contributions to Smack 4.0.5...especially now that the project has moved to github. It may simplify and speed things if you (and/or someone else associated with Smack 4) were to join the CQ bug above, as I can't answer all the provenance/policy questions about the project. In the mean time, I will examine the binaries to verify that the OSGi metadata is in a form we can directly consume, and no longer build the org.jivesoftware.smack bundle ourselves. Also, I expect that the API changes in moving the ECF code from using 3.3 -> to 4.0.5 may require some code changes (to use the 4 API rather than 3.3). Does the Smack project have some sort of 3.x -> 4 migration guide...or notes about API changes?
(In reply to Scott Lewis from comment #15) > It may simplify and speed things if you (and/or someone else associated with > Smack 4) were to join the CQ bug above, as I can't answer all the > provenance/policy questions about the project. I'd be happy to help here, but unfortunately I'm unable to login at https://dev.eclipse.org/ipzilla/ (using the same credentials I use here). > Also, I expect that the API changes in moving the ECF code from using 3.3 -> > to 4.0.5 may require some code changes (to use the 4 API rather than 3.3). > Does the Smack project have some sort of 3.x -> 4 migration guide...or notes > about API changes? https://github.com/igniterealtime/Smack/wiki/Smack-4.0-Readme-and-Upgrade-Guide
(In reply to Florian Schmaus from comment #16) <stuff deleted> > > I'd be happy to help here, but unfortunately I'm unable to login at > https://dev.eclipse.org/ipzilla/ (using the same credentials I use here). I believe you need to be a committer on some project, and use committer login credentials for ipzilla. If you are not a committer on any project, then I suppose I'll put them in touch with you at your email address when they get to that point.
Florian, This was just posted to the Smack 4 contribution questionnaire CQ 8884 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8887 by Sharon Corbett at the Eclipse Foundation: Hi Scott: Just a reminder from the last review of this package for ECF that provenance resolution for subsequent versions would depend on the Smack project putting a contribution mechanism in place (see CQ 7367). I had the impression you were going to follow up with the project lead to help convince them of this requirement. I've just spot checked the git page for the project and did not uncover any information concerning a CLA. Do you have any information? Otherwise, I'm not sure how we can proceed. Thanks, Sharon Just for your reference Florian, here's what Sharon said on 10/13/2013 about a Smack CLA on CQ 7367 Hi Scott: You are most welcome - my pleasure! Robin Collier is the Smack Project Lead. Correct, Matt and Jive are no longer active on the project from a development perspective. I've just introduced you to Robin via email moments ago. In my opinion, Robin seemed genuinely interested in the fact that we would not be able to continue to redistribute Smack without the project having a CLA mechanism in place. I hope this helps. Best Regards, Sharon [Scott] Florian how would you like to proceed? Is there a CLA mechanism associated with the Smack 4 project at github? Would you like to correspond with Sharon directly about this? Are you the appropriate person for the Smack 4 project?
Hi Florian, Just to let you know (since you are not able to join the CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8887 The EF (and I/ECF) are waiting for the Smack 4 CLA to be established and put in place as we've discussed in email with Matt Tucker and other Jive folks. Once that's done we will be able to use Smack 4 for our provider. In the mean time, I will begin (in Dec) the technical work in our code to use Smack 4 rather than Smack 3.3.
(In reply to Scott Lewis from comment #19) > The EF (and I/ECF) are waiting for the Smack 4 CLA to be established and put > in place... I'd just like to comment that it's unlikely that Smack will soon (or ever) establish a CLA. I'm unable to allocate the resources required to do this, and nobody else seems to be willing to do so too.
(In reply to Florian Schmaus from comment #20) > (In reply to Scott Lewis from comment #19) > > The EF (and I/ECF) are waiting for the Smack 4 CLA to be established and put > > in place... > > I'd just like to comment that it's unlikely that Smack will soon (or ever) > establish a CLA. I'm unable to allocate the resources required to do this, > and nobody else seems to be willing to do so too. Florian...I propose that we create a Smack 4 provider and make it available via ECF's github organization: http://github.com/ECF
(In reply to Scott Lewis from comment #21) > (In reply to Florian Schmaus from comment #20) > > (In reply to Scott Lewis from comment #19) > > > The EF (and I/ECF) are waiting for the Smack 4 CLA to be established and put > > > in place... > > > > I'd just like to comment that it's unlikely that Smack will soon (or ever) > > establish a CLA. I'm unable to allocate the resources required to do this, > > and nobody else seems to be willing to do so too. > > Florian...I propose that we create a Smack 4 provider and make it available > via ECF's github organization: http://github.com/ECF I've created the new repository here: https://github.com/ECF/Smack4Provider
That's great! Let me know or ask in #smack (freenode) if there is anything I can do to help. But one question because I'm unfamiliar with the Eclipse approach: What does the Smack4 provider actually provide? How is it implemented? Why is is required?
(In reply to Florian Schmaus from comment #23) > That's great! Let me know or ask in #smack (freenode) if there is anything I > can do to help. > > But one question because I'm unfamiliar with the Eclipse approach: What does > the Smack4 provider actually provide? How is it implemented? Why is is > required? 1) ECF has several abstract APIs...e.g. filetransfer, presence, im, chat, etc that are implemented via various protocols...e.g. xmpp, irc, http/https, etc. So the ECF provider bundle, which is here for the 3.3.0 version of Smack: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.xmpp provides a bridge between the APIs and the Smack4 implementation of xmpp. It's not a lot of code, but with the changes Smack3->Smack4 it has to be modified/reworked. I will likely need to ask you some questions about Smack4 changes. Hopefully I'll have something compilable in the github repo within a few days. I've already started it and am doing some testing of basic connections, etc. One question right now though: There used to be slightly different connect API for connecting to Google talk accounts (e.g. security). Is there any code example of using Smack4 to connect to gtalk? Or is it now the same as connecting to other xmpp servers? Another question: Smack (4.2.0) has 19 jars/bundles now...is there some description of which are required/appropriate for what features and/or environments? Thanksinadvance.
(In reply to Scott Lewis from comment #24) > One question right now though: There used to be slightly different connect > API for connecting to Google talk accounts (e.g. security). Is there any > code example of using Smack4 to connect to gtalk? Or is it now the same as > connecting to other xmpp servers? I don't remember a "slightly different connect API" for gtalk, even in older Smack versions (3.x). From Smack's POV, Google provides just a normal XMPP server. > Another question: Smack (4.2.0) has 19 jars/bundles now...is there some > description of which are required/appropriate for what features and/or > environments? Thanksinadvance. There is the description attribute within the POM of the subprojects artifacts. Most Java SE users usually want to depend on - smack-tcp: For XMPP over TCP - smack-java7: In order to initialize Smack using Java7 API (e.g. in order to resolve DNS SRV RRs) - smack-extensions: Smack API for XEPs (Service Discovery, AdHoc Commands, ...) - smack-im: For XMPP-IM (RFC 6121) support (Roster etc.) - smack-experimental: Smack API for experimental XEPs All other subproject artifacts are direct or transitive dependencies of those, and are automatically pulled in if required. If you don't use a build system with maven dependency resolution, you have to manually gather all required dependencies (jars) and put them into the classpath.
(In reply to Florian Schmaus from comment #25) > (In reply to Scott Lewis from comment #24) > > One question right now though: There used to be slightly different connect > > API for connecting to Google talk accounts (e.g. security). Is there any > > code example of using Smack4 to connect to gtalk? Or is it now the same as > > connecting to other xmpp servers? > > I don't remember a "slightly different connect API" for gtalk, even in older > Smack versions (3.x). From Smack's POV, Google provides just a normal XMPP > server. > > > Another question: Smack (4.2.0) has 19 jars/bundles now...is there some > > description of which are required/appropriate for what features and/or > > environments? Thanksinadvance. > > There is the description attribute within the POM of the subprojects > artifacts. Most Java SE users usually want to depend on > > - smack-tcp: For XMPP over TCP > - smack-java7: In order to initialize Smack using Java7 API (e.g. in order > to resolve DNS SRV RRs) > - smack-extensions: Smack API for XEPs (Service Discovery, AdHoc Commands, > ...) > - smack-im: For XMPP-IM (RFC 6121) support (Roster etc.) > - smack-experimental: Smack API for experimental XEPs > > All other subproject artifacts are direct or transitive dependencies of > those, and are automatically pulled in if required. If you don't use a build > system with maven dependency resolution, you have to manually gather all > required dependencies (jars) and put them into the classpath. Thanks for the info...we don't use a maven build system currently, but that's likely to change. I also discovered that smack depends upon jxmpp lib version 0.4.2 apparently (0.5.x) has changed to not include some classes that smack uses. Anyway, if I add jxmpp 0.4.2.alpha2 things seem ok. Just to make sure I have the right jxmpp version, which smack pom references jxmpp dependency? Thanks.
(In reply to Scott Lewis from comment #26) > Thanks for the info...we don't use a maven build system currently, but > that's likely to change. I also discovered that smack depends upon jxmpp > lib version 0.4.2 apparently (0.5.x) has changed to not include some classes > that smack uses. Anyway, if I add jxmpp 0.4.2.alpha2 things seem ok. Just > to make sure I have the right jxmpp version, which smack pom references > jxmpp dependency? smack-core:4.1.3 depends on jxmpp-core:0.4.2-beta1 [1], that the version you want to include. I think the easiest way to determine the dependencies of a smack version is to git checkout <smackVersion, e.g. '4.1.3'> gradle smack-tcp:dependencies Don't be worried because of the beta1 in jxmpp. The version is reasonable stable and I just missed to create release for jxmpp 0.4. 1: https://repo1.maven.org/maven2/org/igniterealtime/smack/smack-core/4.1.3/smack-core-4.1.3.pom
(In reply to Florian Schmaus from comment #27) > (In reply to Scott Lewis from comment #26) > > Thanks for the info...we don't use a maven build system currently, but > > that's likely to change. I also discovered that smack depends upon jxmpp > > lib version 0.4.2 apparently (0.5.x) has changed to not include some classes > > that smack uses. Anyway, if I add jxmpp 0.4.2.alpha2 things seem ok. Just > > to make sure I have the right jxmpp version, which smack pom references > > jxmpp dependency? > > smack-core:4.1.3 depends on jxmpp-core:0.4.2-beta1 [1], that the version you > want to include. I think the easiest way to determine the dependencies of a > smack version is to > > git checkout <smackVersion, e.g. '4.1.3'> > gradle smack-tcp:dependencies > > Don't be worried because of the beta1 in jxmpp. The version is reasonable > stable and I just missed to create release for jxmpp 0.4. > > 1: > https://repo1.maven.org/maven2/org/igniterealtime/smack/smack-core/4.1.3/ > smack-core-4.1.3.pom Thanks. I have a new question. In Smack 3.3, when connecting to gmail I currently have code to load/fill an instance of org.jivesoftware.smackx.vcardtemp.packet.VCard. Then I call VCard.getAvatar and it returns an array of bytes that is the person's picture. In 3.3 this all works fine. In 4.1.3, however, all the VCard instance logic is the same, but when I call VCard.getAvatar() it returns null (not the picture bytes as in 3.3). I'm trying to track down why. Do you have any insight about this? Thanksinadvance.
(In reply to Scott Lewis from comment #28) > I have a new question. In Smack 3.3, when connecting to gmail I currently > have code to load/fill an instance of > org.jivesoftware.smackx.vcardtemp.packet.VCard. Then I call VCard.getAvatar > and it returns an array of bytes that is the person's picture. In 3.3 this > all works fine. > > In 4.1.3, however, all the VCard instance logic is the same, but when I call > VCard.getAvatar() it returns null (not the picture bytes as in 3.3). I'm > trying to track down why. Do you have any insight about this? > > Thanksinadvance. Not from the top of my head. I'm not aware of any issues with Smack's vCard API in 4.1. But then again, I don't use gmail (but others probably do). You best chance is to enable Smack debug in order to get a stanza trace, and then compare the stanza trace with what is specified in the relevant XEP. See also https://github.com/igniterealtime/Smack/wiki/How-to-ask-for-help-or-report-an-issue It would also help if you could show me a minimal (non-)working example.
(In reply to Florian Schmaus from comment #29) > (In reply to Scott Lewis from comment #28) > > I have a new question. In Smack 3.3, when connecting to gmail I currently > > have code to load/fill an instance of > > org.jivesoftware.smackx.vcardtemp.packet.VCard. Then I call VCard.getAvatar > > and it returns an array of bytes that is the person's picture. In 3.3 this > > all works fine. > > > > In 4.1.3, however, all the VCard instance logic is the same, but when I call > > VCard.getAvatar() it returns null (not the picture bytes as in 3.3). I'm > > trying to track down why. Do you have any insight about this? > > > > Thanksinadvance. > > Not from the top of my head. I'm not aware of any issues with Smack's vCard > API in 4.1. But then again, I don't use gmail (but others probably do). > > You best chance is to enable Smack debug in order to get a stanza trace, and > then compare the stanza trace with what is specified in the relevant XEP. > See also > https://github.com/igniterealtime/Smack/wiki/How-to-ask-for-help-or-report- > an-issue > > It would also help if you could show me a minimal (non-)working example. Nevermind. I've fixed it. It seems that the required calls on the 4.x VCardManager are slightly different from those on 3.3, but I've figured it out and it's working now. I've checked in (at github/ECF) the current state of things: https://github.com/ECF/Smack4Provider There are still some problems with the smack4 provider, and I'll be working on them over the next few weeks...and probably asking you (Florian) questions here as I go along. I'll also eventually add pom.xml for building. I'm going to be away the week of 27, so don't take my inactivity as a sign of anything other than that time off is sometimes necessary.
Hi Florian. Nearly everything is working, but I'm having one problem with Google Talk: The problem is that for relatively new accounts I'm getting a SASL Plain auth error when I try to connect...it looks something like the connect error reported in this bug http://stackoverflow.com/questions/25543828/smack-connecting-to-googles-xmpp-service-gtalk-throws-exception-saslerror-us i.e. Exception in thread "main" org.jivesoftware.smack.sasl.SASLErrorException: SASLError using PLAIN: not-authorized One bug responder says this: Google has recently switched to not allowing PLAIN and similar methods on its accounts - https://support.google.com/accounts/answer/6010255. If you want to use such auth mechanisms, the account will need to enable them - https://www.google.com/settings/security/lesssecureapps Is this right? Does every client have to enable clients? Or is there some way to config Smack security to connect to gtalk accounts that haven't been specifically enabled as above? Thanks for any info.
(In reply to Scott Lewis from comment #31) > Nearly everything is working, but I'm having one problem with Google Talk: > > Exception in thread "main" org.jivesoftware.smack.sasl.SASLErrorException: > SASLError using PLAIN: not-authorized > > One bug responder says this: > > Google has recently switched to not allowing PLAIN and similar methods on > its accounts - https://support.google.com/accounts/answer/6010255. > > If you want to use such auth mechanisms, the account will need to enable > them - https://www.google.com/settings/security/lesssecureapps > > > Is this right? Does every client have to enable clients? Or is there some > way to config Smack security to connect to gtalk accounts that haven't been > specifically enabled as above? I think so, Google has phased out PLAIN in favor of X-OAUTH2, which is supported by Smack [1] (although not used by me, but IIRC i've got feedback that it works). What makes me wonder is "PLAIN: not-authorized", which suggests that the server is offering PLAIN. But maybe Google's XMPP servers are offering PLAIN unconditionally, i.e. not respecting the lesssecureapps setting. If that is the case, you will eventually need to blacklist/disable PLAIN for the SASL mechanism selection, e.g. by only enabling X-OAUTH2 in the ConnectionConfiguration via enabledSaslMechanisms. When X-OAUTH2 is used by Smack, then you need to use the OAUTH2 token as "password". 1: https://github.com/igniterealtime/Smack/blob/4.1.3/smack-core/src/main/java/org/jivesoftware/smack/sasl/core/SASLXOauth2Mechanism.java
(In reply to Florian Schmaus from comment #32) <stuff deleted> > > I think so, Google has phased out PLAIN in favor of X-OAUTH2, which is > supported by Smack [1] (although not used by me, but IIRC i've got feedback > that it works). What makes me wonder is "PLAIN: not-authorized", which > suggests that the server is offering PLAIN. But maybe Google's XMPP servers > are offering PLAIN unconditionally, i.e. not respecting the lesssecureapps > setting. If that is the case, you will eventually need to blacklist/disable > PLAIN for the SASL mechanism selection, e.g. by only enabling X-OAUTH2 in > the ConnectionConfiguration via enabledSaslMechanisms. > > When X-OAUTH2 is used by Smack, then you need to use the OAUTH2 token as > "password". > > > 1: > https://github.com/igniterealtime/Smack/blob/4.1.3/smack-core/src/main/java/ > org/jivesoftware/smack/sasl/core/SASLXOauth2Mechanism.java Thanks Florian. Is there any example or other code that shows how to do this? Ideally known to work for gmail. Or maybe I can ask for a pointer to your feedback person? And if this is done (disabling plain), will it cease working for non-gtalk jabber servers? Thanks.
This provider now exists here: https://github.com/ECF/Smack4Provider
