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 <[email protected]> [171113 11:01]: > 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 > > On Wed, 28 Jun 2017 00:09:12 +0200, Markus Gschwendt wrote: > > > > > 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. > > 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'. > > 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.) Net::XMPP::Client defaulting to ssl=0, tls=0 in itself is already a 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. > > > 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). > > I'd like to have the default set in Net::XMPP debian package to have it > > available in several applications which use this library. > > I don't see a place of/for default values there, and I still think > it's the wrong place. Net::XMPP::Client's new appears to set defaults. That might be a good 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. 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. > > Maybe in sendxmpp too. > > I'm still sure that it belongs there because it is sendxmpp which > sets tls-ca-path explicitly to an empty value which then causes > havoc. 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. > [..] > 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. 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
