[SOLVED] Anyone using -current and have trouble with weechat connecting to SSL servers?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Anyone using -current and have trouble with weechat connecting to SSL servers?
Since the past week, this happened out of the blue (i don't believe i upgraded any packages prior to this happening).
I can only connect to EFNet with SSL. All other networks, be that FreeNode, Mozilla, oftc, Rizon, SnooNet, SwiftIRC and others... SSL fails with this message;
Code:
irc: TLS handshake failed
irc: error: The operation was cancelled due to user error
I have been told it's related to something involving openssl packages, however these haven't been upgraded since at least May, so i doubt that can be the problem.
Does anyone know how i can get back to using SSL connections with weechat? The strange thing is that EFNEt works fine, despite no other network wanting to connect. I have no idea how to solve this.
Works for me still (including disconnect/reconnect). What's in your irc.conf?
Too many passwords/servers/channels i'd rather not post here, lol.
However, my irc.conf hasn't changed from my most recent backup i have on another disk, where it has previously been working fine for the past 2 years or so.
Like i say in that other thread, i'm baffled at the cause for this. Because the fact that EFNet connects fine over SSL, yet no other network does. I have tried with irssi, and hexchat... these all work fine as normal. I don't know where else to look.
With HexChat and FreeNode I had to switch too SASL authentication.
I've been using SASL with certificate auth for at least a year on Freenode, but cannot connect with this since this problem started happening.
Also;
Quote:
Originally Posted by mralk3
Try as root maybe? Just a guess.
Code:
update-ca-certificates -f
This doesn't fix the situation. Another thing is that for several irc servers i visit, they have invalid/unsigned certs, so i have to connect with ssl verification disabled, but even those servers throw up the same error messages and i can never connect.
I'm not sure what to do, as i have tried with a clean irc.conf, reconfiguring a new server to use SSL etc, but the same problem occurs, i can only literally connect to EFNet, i guess i will just have to use a different IRC client for now, as i have no idea what is causing this, but like i say, irssi, hexchat (and even kvirc) these work fine connecting to SSL servers... so i have no idea what has happened to weechat, despite rebuilding it and even upgrading it.
Apparently, weechat doesn't use openssl, it uses gnutls. Now after learning of this, i grepped the changelog and spotted this:
Code:
+--------------------------+
Tue Jul 17 21:16:10 UTC 2018
Happy 25th anniversary to the Slackware 1.00 release! When the original
announcement went out on Usenet, I believe it had a UTC timestamp which has
led to some confusion over whether the anniversary falls on the 16th (which
was the date when I made the post) or on the 17th (which is when most people
first saw it)... but really, what's the difference? We can celebrate on both
days as far as I'm concerned. Thanks for sticking with the project all these
years. Glad I was able to help. :)
Here's a link to the 1.00 announcement:
http://www.slackware.com/announce/1.0.php
And here's a nice article that was posted on opensource.com:
https://opensource.com/article/18/7/stackware-turns-25
a/kernel-firmware-20180717_8d69bab-noarch-1.txz: Upgraded.
l/pulseaudio-12.2-x86_64-1.txz: Upgraded.
n/gnutls-3.6.3-x86_64-1.txz: Upgraded.
n/mutt-1.10.1-x86_64-1.txz: Upgraded.
This update fixes bugs and security issues. Upstream strongly recommends
that all IMAP and POP users upgrade as soon as possible.
(* Security fix *)
+--------------------------+
The same date is around the time i started experiencing issues with weechat.
I asked in #weechat on freenode, and it seems i'm not the only one...
Someone grepped their logs for someone else asking about the same issue on slackware -current and posted this:
Quote:
2018-07-31 04:21:02 rimmah Hey, I'm on Slackware current, weechat 2.2, and I'm having issues connecting to any server. On connection this is the result: 'irc: TLS handshake failed', 'irc: error: The operation was cancelled due to user error'. Started a few days ago when I finally rebooted for a new kernel, but SSL/TLS packages have remained constant.
So now i feel this either being a problem with the gnutls package that was upgraded, or whether it's a bug in weechat itself. Despite having rebuilt weechat package multiple times since, the problem still persists.
Just to make sure, is your system time correct? Almost every time I run into this problem its because the system time is wrong.
Yes 100% it is synchronized with ntp, if i manually force ntpdate to sync, then i get drift of -0.00000000000005 or similar. So it's definitely not that, plus i've heard reports of at least 3 people on -current experiencing this issue now.
It's one or the other, something to do with gnutls, or weechat. However, the previous version of weechat suffered from this issue after gnutls was updated it seems.
Sorry to keep bumping this, but it's still broken. I've also just installed -current to a fresh virtual machine, built weechat from ponce's slackbuilds branch, and the same problems occur (EFNet SSL works fine... but literally no other network will connect?). I had also tried a fresh ~/.weechat/irc.conf config, and same problem exists on my desktop.
I still can't understand why EFNet connects fine, but everything else is broken, that's really odd. However, i'm pretty sure it's something involving the gnutls package.
I have been told it's related to something involving openssl packages, however these haven't been upgraded since at least May, so i doubt that can be the problem.
They were updated yesterday, and so I made sure I'm all up to date. That didn't fix the problem for me until I ran
They were updated yesterday, and so I made sure I'm all up to date. That didn't fix the problem for me until I ran
Code:
update-ca-certificates -f
. Now I can connect to FreeNode using HexChat.
ENDEDIT
I'm having this problem with HexChat as well
That's something completely different, hexchat uses OpenSSL (which i have had no problems with). weechat relies on gnutls for SSL connections, i opened a bug report here for weechat: https://github.com/weechat/weechat/issues/1231
I ran into this issue too, after some time completely failing to build the gnutls upstream master I looked at what other distros were doing and found this patch backporting upstream fixes from Fedora.
Code:
diff --git a/lib/cert-cred.c b/lib/cert-cred.c
index d3777e51f..2150e903f 100644
--- a/lib/cert-cred.c
+++ b/lib/cert-cred.c
@@ -387,6 +387,13 @@ static int call_legacy_cert_cb1(gnutls_session_t session,
if (ret < 0)
return gnutls_assert_val(ret);
+ if (st2.ncerts == 0) {
+ *pcert_length = 0;
+ *ocsp_length = 0;
+ *privkey = NULL;
+ return 0;
+ }
+
if (st2.cert_type != GNUTLS_CRT_X509) {
gnutls_assert();
ret = GNUTLS_E_INVALID_REQUEST;
@@ -503,7 +510,10 @@ void gnutls_certificate_set_retrieve_function
gnutls_certificate_retrieve_function * func)
{
cred->legacy_cert_cb1 = func;
- cred->get_cert_callback3 = call_legacy_cert_cb1;
+ if (!func)
+ cred->get_cert_callback3 = NULL;
+ else
+ cred->get_cert_callback3 = call_legacy_cert_cb1;
}
static int call_legacy_cert_cb2(gnutls_session_t session,
@@ -578,7 +588,10 @@ void gnutls_certificate_set_retrieve_function2
gnutls_certificate_retrieve_function2 * func)
{
cred->legacy_cert_cb2 = func;
- cred->get_cert_callback3 = call_legacy_cert_cb2;
+ if (!func)
+ cred->get_cert_callback3 = NULL;
+ else
+ cred->get_cert_callback3 = call_legacy_cert_cb2;
}
/**
diff --git a/lib/hello_ext.c b/lib/hello_ext.c
index a3027130a..f72afe77f 100644
--- a/lib/hello_ext.c
+++ b/lib/hello_ext.c
@@ -208,7 +208,7 @@ int hello_ext_parse(void *_ctx, unsigned tls_id, const uint8_t *data, unsigned d
if (tls_id == PRE_SHARED_KEY_TLS_ID) {
ctx->seen_pre_shared_key = 1;
- } else if (ctx->seen_pre_shared_key) {
+ } else if (ctx->seen_pre_shared_key && session->security_parameters.entity == GNUTLS_SERVER) {
/* the pre-shared key extension must always be the last one,
* draft-ietf-tls-tls13-28: 4.2.11 */
return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER);
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.