Dear Maintainer,

After upgrade to 1.05-1, sendxmpp program can't send message to googole hangouts.

XML::Stream: SetCallBacks: tag(node) func(CODE(0x5567d6c2aa20))
XMPP::Conn: xmppCallbackInit: start
XMPP::Conn: SetCallBacks: tag(message) func(CODE(0x5567d6c2aaf8))
XMPP::Conn: SetCallBacks: tag(presence) func(CODE(0x5567d6b19538))
XMPP::Conn: SetCallBacks: tag(iq) func(CODE(0x5567d5bc4b68))
XMPP::Conn: SetPresenceCallBacks: type(subscribe) func(CODE(0x5567d6c2a798))
XMPP::Conn: SetPresenceCallBacks: type(unsubscribe) func(CODE(0x5567d6c2a720))
XMPP::Conn: SetPresenceCallBacks: type(unsubscribed) func(CODE(0x5567d6c2b068))
XMPP::Conn: SetPresenceCallBacks: type(subscribed) func(CODE(0x5567d6c2b1d0))
XMPP::Conn: SetDirectXPathCallBacks: xpath(/[@xmlns="urn:ietf:params:xml:ns:xmpp-tls"]) func(CODE(0x5567d6bd6a48))
XMPP::Conn: SetDirectXPathCallBacks: xpath(/[@xmlns="urn:ietf:params:xml:ns:xmpp-sasl"]) func(CODE(0x5567d6c2aea0))
XMPP::Conn: xmppCallbackInit: stop
sendxmpp: ssl_verify: 1
sendxmpp: tls_ca_path:
XMPP::Conn: Connect: host(talk.google.com:5222) namespace(jabber:client)
XMPP::Conn: Connect: timeout(10)
XML::Stream: Connect: srv requested
XML::Stream: Connect: srv query failed
XML::Stream: Connect: type(tcpip)
Invalid or unreadable path specified for ssl_ca_path. at /usr/share/perl5/XML/Stream.pm line 641.

rollback to 1.02-5 will slove this issue.

I can confirm this.
Same problem with my ejabberd server (on debian testing).

The package is breaking other packages, as sendxmpp. It is reflecting
in Stretch too. I need sendxmpp to receive important event notices
from my network.

Cheers,

Eriberto

^^

Looks like the path to the SSL cert(s) is empty.
I gues either sendxmpp should set it, or XML::Stream should use a
sane default.

For the latter see /usr/share/perl5/XML/Stream.pm:
223    $self->{SIDS}->{default}->{ssl_ca_path} = '';

Changing this value to '/etc/ssl/certs' might help.


I doubt that libnet-xmpp-perl is the problem here; the change between
1.02 and 1.05 is that it passes a defined ssl_ca_path on to
XML::Stream.


Ah, sendxmpp has an option tls-ca-path which is set to an empty
string if not passed on the command line. [0] In that case probably the
empty string somehow propagates down ...


Could one of the sendxmpp please try to call it with something like
--tls-ca-path="/etc/ssl/certs"
and see if this helps?
And/or change the above mentioned line in
/usr/share/perl5/XML/Stream.pm?
And/or change the line in sendxmpp mentioned in [0]?


If this is successful we still have to think where we should make
changes.


Cheers,
gregor


[0]
287        'tls-ca-path' => ($tls_ca_path or ''),

2017-06-23 21:14 GMT-03:00 gregor herrmann <gregoa@debian.org>:



Hi gregor,

The both options work fine. Thanks a lot for your help.

Please, when uploading, fix Stretch too!

Have a nice weekend.

Cheers,

Eriberto

Now I'm a bit confused: Which "both" of the 3 options mentioned above
work?
[ ] call sendxmpp with --tls-ca-path="/etc/ssl/certs"
[ ] change line 223 in /usr/share/perl5/XML/Stream.pm
[ ] change line 287 in /usr/bin/sendxmpp

First we need to decide where we want the fix ...


Cheers,
gregor

2017-06-24 15:23 GMT-03:00 gregor herrmann <gregoa@debian.org>:


Wow, sorry...

Worked fine:

[ x ] call sendxmpp with --tls-ca-path="/etc/ssl/certs"
[ x ] change line 223 in /usr/share/perl5/XML/Stream.pm

I didn't test the following option in my last email. I did it now and works too.

[ x ] change line 287 in /usr/bin/sendxmpp

However, for me in Stretch the right line is 290. See below:

   290 'tls-ca-path' => ($tls_ca_path or '/etc/ssl/certs'),

Thanks!

Cheers,

Eriberto

Another question: you marked this bug as "affects: sendxmpp
ejabberd". The former is obvious but why the latter? I don't think
that ejabberd uses XML::Stream or Net::XMPP …


Cheers,
gregor

2017-06-25 11:40 GMT-03:00 gregor herrmann <gregoa@debian.org>:


Hi gregor,

This information was provided by Markus Gschwendt here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854210#10

When you think that you will can fix the issue?

Thanks in advance.

Cheers,

Eriberto

Right but I'm reading the message as "It also happens when I use
sendxmpp to send a message to a server running ejabberd [and not only
some google server as in the original bug report]". Cc'ing Markus for
clarification.
(and following that who should fix it).

So far we have:
- a bug against libnet-xmpp-perl which is (at least partially) the wrong
  package; the change in Net::XMPP is that it starts to pass on the
  empty path to the ssl certs from sendxmpp to XML::Stream (before
  that it just ignored the path), so even if a change in Net::XMPP
  triggered the issues, it's not doing anything wrong and doesn't
  look like the place to fix anything;
- a probably inflated severity, as sendxmpp appears to work fine if a
  correct --tls-ca-path is passed on the command line (or probably in
  its config file?);
- the idea to make this all easier for users by setting a sane
  default in either sendxmpp or libxml-stream-perl;
- no indication that this affects anything else then sendxmpp
  (if I interpret Markus' message correctly).

Currently I tend to think that setting an empty path for tls-ca-path
is suboptimal behaviour in sendxmpp which should be fixed there.

But I'd welcome other opinions on this point.


Cheers,
gregor

+1
I'd like to have the path to the certs as default.
Maybe both packages should have a default value.

Markus

Thanks for your reply.

Could you please also tell us if my interpretation of your message re
ejabberd from my last mail was correct?

-#-#-#-#

Right but I'm reading the message as "It also happens when I use
sendxmpp to send a message to a server running ejabberd [and not only
some google server as in the original bug report]". Cc'ing Markus for
clarification.

#-#-#-#-


Cheers,
gregor

yes. in my opinion ejabberd is not effected.
the cause of the problem is on the local side of perl/sendxmpp
configuration. ejabberd was just the remote side in my case like google
chat in the original report.

Markus

Control: affects -1 - ejabberd

Thanks for the confirmation!
I'm removing the "affects ejabberd" now.


Cheers,
gregor

Hi Gregor,

Maybe I miss something obvious, but IMHO the bug should 1/ be
reassigned to sendxmpp itself. Then the question is if sendxmpp should
be patches actually (if so it might need to depend on
ca-certificates), or "just" document when
-tls-ca-path="/etc/ssl/certs" needs to be passed.

Maybe not a really useful reply, and I was not involved in the whole
discussion. But my gut feeling is that Net::XMPP is not at "fault"
here in this case.

Regards,
Salvatore

Thanks for your assessment which makes a lot of sense to me.

Ack, AFAICS Net::XMPP fixed a bug (ignoring the path to the certs)
and this triggered the necessity for sendxmpp to set it (by the user
or in the code). -- At the other end of the chain XML::Stream is just
a general-purpose low-level library, and changes there look like the
wrong place to me.


Unless new arguments come up in to near feature, I'm going to
reassign this bug to sendxmpp.


Cheers,
gregor

...

If people don't like to use SSL (which i would consider as a bad idea
these days) they also don't want a dependency on ca-certificates. So it
should be a 'reccomended package'.

But if ca-certificates is installed, it would be nice to have tls-ca-
path="/etc/ssl/certs" set as default. Otherwise it will not be used
anyways.
If the -t flag is used and no certs are found, there should be a error
message which suggests the installation of the ca-certificates package
or to set a proper path to manually deployed certs.


...

I'd like to have the default set in Net::XMPP debian package to have it
available in several applications which use this library.
Maybe in sendxmpp too.

ACK. this would be too low-level.

Markus

Control: reassign -1 sendxmpp 1.23-1.1
Control: severity -1 important
Control: retitle -1 sendxmpp: sendxmpp can't send message with TLS/SSL without passing -tls-ca-path

I think that's not really an option, as what we are seeing here, and
that's the start of the bug report, is tjat there are servers which
enforce TLS/SSL.
(But maybe I'm wrong here.)
it's the wrong place.

Net::XMPP::Connection offers a Connect() method (which is used by
sendxmpp [0]) which optionally offers to set some TLS/SSL parameters.
They can also be left out but saying "yes we want TLS/SSL but we
don't tell you were to find the certs", as sendxmpp does, breaks
later in the underlying XML::Stream.

Or in other words: I think sendxmpp is just using
Net::XMPP::Connection wrong.
sets tls-ca-path explicitly to an empty value which then causes
havoc.

BTW, in the meantime I think it belongs in line
80               $$cmdline{'tls-ca-path'} || $$config{'tls-ca-path'} || '/etc/ssl/certs',

Alternatively, just dropping the empty string seems to work too:
80               $$cmdline{'tls-ca-path'} || $$config{'tls-ca-path'},


Conclusion:
So far we only see problems with sendxmpp; sendxmpp is not broken
(manually setting the parameters works) but is sub-optimal: it would
profit from either setting a default path or not setting an empty
path (!). And the fix is easy as well.

Therefore I'm now reassigning the bug to sendxmpp and lowering the
severity.


Cheers,
gregor


[0]
Arguably a bad idea, as that's an internal module according to its
documentation but anyway.

Did I miss something or has this largely been languishing for months?

Hey everyone,

I've just stumbled across this bug, because we're using some
not-packaged software that worked fine on jessie, and on stretch
fails to connect to our internal jabber server.

It basically does this:

  my $connection = Net::Jabber::Client -> new( debugLevel => $jabberdebug );
  $connection -> Connect( "hostname" => $jabberserver, "port" => $jabberport, "tls" => $jabbertls, "ssl" => $jabberssl )  or die "Cannot connect ($!)\n";

Note: Net::Jabber::Client is a "wrapper" for Net::XMPP::Client which
one can consider to be equal for this discussion.

* gregor herrmann <gregoa@debian.org> [171113 11:01]:
very bad idea today. Most public servers should be requiring at
least StartTLS, so these defaults pretty much break connecting to
most servers.
Still, a common pattern in Debian appears to be only Recommending:
ca-certificates, so that'd still be alright, I think.

Net::XMPP::Client's new appears to set defaults. That might be a
good place?

As said above, defaulting TLS to off is a bad idea already.

OTOH, XML::Stream then defaults to verifying certificates, if TLS is
on, but does not provide a default where to find any certificates.

Having every user of Net::XMPP (or XML::Stream) supply the path
to the OS-provided default certificate store is rather silly in my
opinion.

That looks bad in sendxmpp, but comparing the code I pasted above,
it also won't work with nothing passed, in which case sane defaults
should apply.

I'd consider cloning this bug to libnet-xmpp-perl or
libxml-stream-perl, raising severity, because of the upgrade
breakage.

Thoughts, objections?

Thanks,
Chris