This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Do not lose tweets on TLS issues #9
Description
Sometimes (possibly just on one network) I get TLS connection errors. Normally this happens when RTing, but occasionally it happens when tweeting. Normally, Corebird/Cawbird keeps the last tweet, but in one specific situation that I think is related to the TLS errors then it forgets it. My assumption is that it doesn't handle the error correctly and treats it as posted.
Activity
IBBoard commentedon Sep 3, 2019
Error is:
At least it's from Vala code and we get a line number!
IBBoard commentedon Sep 3, 2019
This may be handled correctly on sending tweets.
start_send_tweetinComposeTweetWindow.valaonly wipes the last message when the async finishes and the tweet succeeds (src).But
save_last_tweetonly saves the text when we're not replying to something. So maybe we lose replies.Re #9: Keep RT status in-line with success/failure
Re #9: Make favouriting follow same pattern as RT
Re #9: Make Delete follow the same pattern
Re #9: Add saving of reply to/quoted tweet
IBBoard commentedon Sep 10, 2019
From initial testing then the patches are working. I've had an RT that failed that then reset back to the "not RTed" status so that I could RT properly. Previously the UI would say RTed, but the dialog says it failed, then you'd un-RT and it'd complain that the tweet didn't exist, and then you'd RT.
The only problem is that I've had to add a "Save tweet?" dialog to give users a way out when they quote a tweet, it fails for transient reasons (like the TLS issue), and then by the time they go to post it again then it fails to load the tweet and so they want to clear the draft tweet.
One thing I need to think about is attached media. I'm not sure how well we can handle keeping draft attached images.
IBBoard commentedon Sep 13, 2019
Today was a REALLY bad day for these errors. Happened repeatedly. Not a clue what's happening with Twitter/the network. I briefly tried Wireshark but it wasn't hugely helpful.
However, I did find that I've got more work to do:
Also, I still need to look at attached media.
Re #9: Fix favouriting failure behaviour
Re #9: Fix deprecated "async without begin()" that I introduced
Re #9: Fix handling of failed tweets in UI
Re #9: Fix handling of failed tweets in UI
19 remaining items
IBBoard commentedon Oct 5, 2019
Okay, I think this is about done now. I've still got to look in to the GnuTLS side, but most things should now be handled correctly, fail and retry, or fail silently for some remaining less important things.
I've merged to Master and will release soon, so give me a shout if there's anything else that people find.
IBBoard commentedon Oct 7, 2019
It looks like there's a simple fix upstream in GnuTLS that appears to work for me.
It's currently scheduled for v3.6.11 in December.
In the mean-time, I'll consider this as fixed as it's going to be, unless someone tells me otherwise.
schmittlauch commentedon Oct 31, 2019
@IBBoard Have you really checked compiling cawbird with GnuTLS from master?
I tried backporting the patches from this commit and compiled cawbird with a
glib-networkingthat uses this patched GnuTLS in NixOS, but I still get TLS errors.I want to test building cawbird agains the latest GnuTLS master but currently fail at building the latter.
IBBoard commentedon Nov 1, 2019
I've been running with a custom build of GnuTLS for a few days that basically just adds MR 1087 to the 3.6.10 code and I've not seen a single TLS error.
I don't believe it's glib-networking that needs recompiling with the updated GnuTLS. I think it's libsoup. I've rebuilt GnuTLS but not glib-networking.
schmittlauch commentedon Nov 1, 2019
That is pretty interesting, as libsoup does not even take gnutls as a dependency in NixOS but just depends on glib-networking.
And that does take gnutls as a dependency.
IBBoard commentedon Nov 2, 2019
Huh, maybe you're right. Maybe I was reading old docs where libsoup used GnuTLS directly. I just rebuilt them both and it worked, but looking at build specs and
lddoutput then libsoup doesn't reference gnutls but does reference GIO'sg_tls_âĶfunctions and glib-networking provides/usr/lib64/gio/modules/libgiognutls.so, which loadslibgnutls.so.30. I might not need to rebuild libsoup.schmittlauch commentedon Jan 7, 2020
Good news, having built Cawbird against NixOS-unstable with the latest GnuTLS release, I haven't encountered any TLS issues for several hours so far \0/
Good job.
IBBoard commentedon Jan 8, 2020
I just debugged it. The GnuTLS people knew the protocols enough to understand what to do to fix it!
philipzae commentedon Apr 18, 2020
I'm running Ubuntu 20.04 with GnuTLS 3.6.13 and still getting the error.
philipzae commentedon Apr 18, 2020
Well i'm running the snap which has a 18.04 base, so maybe that's the issue then.
j1warren commentedon Apr 18, 2020
I've never stopped having this error the first time I try to open any tweet in the timeline.
Pressing back and trying again then works on any tweet.
18.04, 1.0.5 now.
IBBoard commentedon Apr 18, 2020
As far as I can tell, it looks like Ubuntu 18.04 is still using an old version of GnuTLS (possibly 3.5.18).
From what I understand of Snap, I think it bundles its own version of many libraries and I assume it is also outdated if you're seeing the errors.
There's nothing we can do. The changes in this ticket put in the best work-arounds we can without causing different issues. The only real solution is for distros and "application distribution systems" that insist on bundling their own copies of libraries to update their libraries to fix the real bug.
philipzae commentedon Apr 18, 2020
I've filed a bug with the snap dev of cawbird as this is fixable in snaps.
philipzae commentedon Apr 19, 2020
Patch to fix it in 18.04 and 19.10 was submitted by the snap maintainer.
https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1873565