1676141 - Thunderbird fails to communicate over IMAPS with Dovecot after Automatically updating to 78.4.1 (20201105231226) - can't override cert for wrong hostname

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Steve]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

I have a (long-established and unmodified) IMAPS service provided by Dovecot on Ubuntu 18.04.5 LTS. This service uses certificates signed using a personal certificate agency - the same certificates are used for an HTTPS service which still works without certificate issues. This IMAP service has worked perfectly with K9Mail and various Thunderbird releases up-to-and-including Thunderbird 78.4.0 (20201019003438).

I had Thunderbird 78.4.0 (32 bit build) running on Windows 10 up-until 5 November 2020. From 6th November 2020, Thunderbird had updated to 78.4.1 and would no longer connect to the existing IMAPS service.

Thunderbird 68.10.0 (64-bit distributed with Ubuntu desktop) still works with the IMAPS service, as does K9Mail from Android... Hence, I can be pretty confident that the fault does not with the Dovecot service itself.

Actual results:

The Thunderbird user interface fails to display new emails (received after 5 November 2020) that are available over IMAPS (implemented by Dovecot) in Thunderbird 78.4.1 (after the automated update). When sending email (which, in my setup, necessitates a save to a Dovecot "Sent" folder) I get this error:

--
Your message was sent but a copy was not placed in your sent folder (Sent) due to network or file access errors.
You can retry or save the message locally to Local Folders/Sent...

There are no network connectivity issues between Thunderbird and the server - both are on my LAN. When reviewing the server side log, numerous similar errors are reported. (I've replaced valid IPV4 addresses with 1.2.3.4 and 9.8.7.6 to avoid publicising the imap server address here):

--
dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=1.2.3.4, lip=9.8.7.6, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48, session=<ed/3oquzEsTAqAKF>

My best interpretation of this error (so far) is that Thunderbird is trying to do a mutual authentication using SSL - but this is failing because Dovecot is not configured to support this.

It may be relevant that while Thunderbird now refuses to connect to my Dovecot IMAPS service, I do not have a similar problem connecting to GMail IMAPS using the exact same Thunderbird instance.

Brief exploration with tcpdump on the dovecot server confirms that Thunderbird 78.4.1 is making a TCP connection but failing to establish an SSL connection over it.

Expected results:

Ideally, Thunderbird would continue to connect to Dovecot IMAPS services after the automatic upgrade from 78.4.0 to 78.4.1.

If, for some reason, an IMAP service implemented like mine is no-longer supported... a more detailed explanatory error message would be desirable.

Comment 1

[Wayne Mery (:wsmwk)]

I didn't think we had any imap changes in 78.4.1 https://hg.mozilla.org/releases/comm-esr78/pushloghtml?fromchange=THUNDERBIRD_78_4_0_RELEASE&tochange=THUNDERBIRD_78_4_1_RELEASE&full=1

Comment 2

[gene smith]

Sounds like the TLS version of the server isn't >=1.2. Or maybe tb doesn't like the certificate (maybe self-signed?). According to Magnus, you should get a prompt to override the self signed problem when you connect to the server and/or click get new mail.
For the bad TLS version you have to reduce the pref security.tls.version.min from the default to a lower number. Go down one step at a time and restart tb between changes.

Comment 3

[Stefano]

I just had the same issue with an ancient IMAPS server (courier imap), and also found this bug 1669676 closed as invalid. (and solved it by setting security.tls.version.min=1)

I think the main issue is the lack of a specific error message.
No problem with requiring by default TLS1.2, but there should be an error message stating the problem when connecting to an older server.

With old accounts there is no indication that something is wrong, it even shows "connected to ..." message in the lower bar, even if nothing is happening. But I just had messages till the last upgrade of TB.
I also tried enabling debug logs of imap but just got a generic "URL failed with code 0x805a2ff7"

I also tried deleting and recreating the account, which failed with the message "unable to log in at the server. Probably wrong configuration, username or password" which is not very helpful.

Comment 4

[gene smith]

I also tried enabling debug logs of imap but just got a generic "URL failed with code 0x805a2ff7"

Does seem like tb should pop up an alert about this: SSL_ERROR_UNSUPPORTED_VERSION
https://james-ross.co.uk/mozilla/misc/nserror?0x805A2FF7

Comment 5

[Laurent Pointal]

I confirm, same server requested with Thunderbird 68.10.0 (64bits) under Linux works well, but using my son Thunderbird 78.5.0 (32bits) under Windows, it fails as described.

Thunderbird continue to indicate retrieving messages, and Dovecot show in logs:
nov. 26 20:58:26 hostname dovecot[10493]: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=XX.XX.XX.XX, lip=YY.YY.YY.YY, TLS, session=<lCqM9we1NeVOwLQ2>

Comment 6

[gene smith]

Attachment: Proposed fix for non-overridable TLS errors

It's definitely a problem that tb goes silent when there is a non-overridable TLS error with imap. While working on bug 1622640 I found a quick and dirty way to provide the user with feedback. The changes proposed there should probably be in its own bug such as this one. Here's the fix I proposed there.

Comment 7

[Ben Campbell]

Comment on attachment 9189894 [details] [diff] [review]
Proposed fix for non-overridable TLS errors

Oop - I commented on the patch on bug 1622640 instead of here.
Upshot: Looks good, although I think most of the error-code checking can be done with publicly-exposed NS_ERROR_ macros and [`mozilla::psm::ErrorIsOverridable()`](https://searchfox.org/mozilla-central/source/security/manager/ssl/NSSErrorsService.h#46).

Comment 8

[gene smith]

No problem. Thanks for pointing out that it's public. I'll move those fixes to this bug since they are not really STARTTLS specific.

One problem that I've noticed and that you pointed out here, bug 1590474 comment 29, is that you have to click the "get mail" button for a possible TLS override to occur. Otherwise, no new mail is brought in, e.g., if your certificate is bad. I was expecting to see the override dialog as soon as I clicked on a folder or at least after the get new mail timer expires (biff occurs). If I understand the problem, there is no "on stop url" callback associated with the url that triggers the imap select and, after looking at the code, I have no idea how to add it or if it's possible to add it. I think if it could be implemented just for imap select it would fix the problem since that's where I first see the failure when I try to open a folder.

From the log after I click on a folder:
ProcessCurrentURL:imap://gd%2Esmth%40protonmail%2Ecom@127.0.0.1:1143/select%3E/INBOX: = currentUrl
:
CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a3ff2 <---this is overridable
:
SetConnectionStatus(0x805a3ff2)
URL failed with code 0x805a3ff2 (imap://gd%2Esmth%40protonmail%2Ecom@127.0.0.1:1143/select%3E/INBOX)

In this case the error is ignored. But I see the same log entries when I click "get mail" but, thanks to fixes in bug 1590474, the error is handled and the override dialog occurs.

Comment 9

[gene smith]

Attachment: Same functionality but uses the public functions and macros as it should

This is the same functionality as before but uses the public stuff as you suggested. I also moved the "stash of errors in url" up since we now know when the error is truly overridable. It still works when I tested it with a self-signed cert.

I modified your comment under "default:" since I think I have essentially implemented what you were talking about there

This doesn't address any of my other concerns that I wrote about in comment 8. They may be a subject of yet another bug.

Comment 10

[Ben Campbell]

(In reply to gene smith from comment #8)
[snip]

If I understand the problem, there is no "on stop url" callback associated with the url that triggers the imap select and, after looking at the code, I have no idea how to add it or if it's possible to add it. I think if it could be implemented just for imap select it would fix the problem since that's where I first see the failure when I try to open a folder.

From the log after I click on a folder:
ProcessCurrentURL:imap://gd%2Esmth%40protonmail%2Ecom@127.0.0.1:1143/select%3E/INBOX: = currentUrl
:
CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a3ff2 <---this is overridable
:
SetConnectionStatus(0x805a3ff2)
URL failed with code 0x805a3ff2 (imap://gd%2Esmth%40protonmail%2Ecom@127.0.0.1:1143/select%3E/INBOX)

I've not had much of a dig around (I'm not sure how the SELECT goes from the GUI through down to the IMAP command), but that log rather implies that the IMAP protocol is told to perform the SELECT by running an imap: URL (I think pretty much all the IMAP protocol is driven like this - I know there are a couple of exceptions, but on the whole I think URLs are the main interface). This implies that there is a URL listener somewhere with an OnStopRunningUrl() callback which could pick up errors during SELECT and deal with them appropriately. Same goes for all the other IMAP operations, but as you point out, doing it for SELECT should handle the vast bulk of such cases.

But yeah, I think that's worth moving to another bug.

Comment 11

[Ben Campbell]

Comment on attachment 9190138 [details] [diff] [review]
Same functionality but uses the public functions and macros as it should

Review of attachment 9190138 [details] [diff] [review]:
-----------------------------------------------------------------

(BTW,  all this IMAP code is pretty inscrutable and I imagine it can all get a bit frustrating, so I just wanted to say a big thanks for doggedly pursuing this stuff!)

::: mailnews/imap/src/nsImapProtocol.cpp
@@ +4894,5 @@
> +                    do_QueryInterface(secInfo);
> +                if (transportSecInfo) {
> +                  mailNewsUrl->SetFailedSecInfoInternal(transportSecInfo);
> +                }
> +              }

Sorry, I probably missed this last time round:
wouldn't the secInfo of the failed attempt would be useful (in onStopRunningUrl callbacks) for _all_ NSS errors, not just recoverable ones? The secInfo provides a way to get at a failed certificate and hypothetically I'd guess some error handlers might want to show details on bad certs?
So I'd move the secInfo nabbing out, to be done for any NSS error.

@@ +4899,5 @@
> +            }
> +          }
> +        } else {
> +          // Not sure if other errors types can occur here.
> +          NS_ASSERTION(false, "CreateNewLineFromSocket: error ignored");

I'm a bit hazy on the various error codes that might bubble up, but I'm sure there are a bunch of valid ones which don't trigger an alert box from within the IMAP code. I'd leave out the assert and let such non-alert-generating errors pass through, to be picked up (optionally) by onStopRunningUrl callback.

Comment 12

[gene smith]

Attachment: t2.diff

Sorry, I probably missed this last time round:
wouldn't the secInfo of the failed attempt would be useful (in onStopRunningUrl callbacks) for all NSS errors, not just recoverable ones? The secInfo provides a way to get at a failed certificate and hypothetically I'd guess some error handlers might want to show details on bad certs?
So I'd move the secInfo nabbing out, to be done for any NSS error.

No, you didn't miss it since I just moved it with that version. Anyhow, I'm now moved it so it occurs for any security related errors, not just overridable. I hope that's what you mean since, with this diff, I didn't put it back where it originally was and store the sec info for all errors.

I'm a bit hazy on the various error codes that might bubble up, but I'm sure there are a bunch of valid ones which don't trigger an alert box from within the IMAP code. I'd leave out the assert and let such non-alert-generating errors pass through, to be picked up (optionally) by onStopRunningUrl callback.

I think NS_ASSERTION just prints a console message for DEBUG builds and is ignored in releases. So I don't think it will stop or crash the program or prevent the the errors from propagating. But, it's probably not really needed so I took it out anyhow.

(BTW, all this IMAP code is pretty inscrutable and I imagine it can all get a bit frustrating, so I just wanted to say a big thanks for doggedly pursuing this stuff!)

Yes, it does seem like a lot is not documented and some of the code is hard to follow (for me at least). For example, I can see that for SMTP the specific error string corresponding to the many NSS errors is actually obtained, encoding and displayed here:
https://searchfox.org/comm-central/rev/1fa5ebe1384434e904b33bb7de8f0a3d6e8bfdc5/mailnews/compose/src/nsMsgSend.cpp#3043
But when I do a similar thing in IMAP, it builds OK but I get a "not thread-safe" crash. I guess that's the same problem you point out about the imap thread vs. main thread. I assume SMTP runs on main thread.
Also, never found where the "OnStopRunning" for select might be, and if it exists, I hope it runs on main thread.

Comment 13

[Ben Campbell]

(In reply to gene smith from comment #12)

Created attachment 9190392 [details] [diff] [review]
t2.diff

Sorry, I probably missed this last time round:
wouldn't the secInfo of the failed attempt would be useful (in onStopRunningUrl callbacks) for all NSS errors, not just recoverable ones? The secInfo provides a way to get at a failed certificate and hypothetically I'd guess some error handlers might want to show details on bad certs?
So I'd move the secInfo nabbing out, to be done for any NSS error.

No, you didn't miss it since I just moved it with that version. Anyhow, I'm now moved it so it occurs for any security related errors, not just overridable. I hope that's what you mean since, with this diff, I didn't put it back where it originally was and store the sec info for all errors.

Yep, that's what I meant. I don't think secInfo is of any use for non-NSS errors. I think my original code stored the secInfo unconditionally just because it was a bit of an arse to determine if it was an NSS error or not from within the IMAP thread (but you've solved that!).

(BTW, all this IMAP code is pretty inscrutable and I imagine it can all get a bit frustrating, so I just wanted to say a big thanks for doggedly pursuing this stuff!)

Yes, it does seem like a lot is not documented and some of the code is hard to follow (for me at least). For example, I can see that for SMTP the specific error string corresponding to the many NSS errors is actually obtained, encoding and displayed here:
https://searchfox.org/comm-central/rev/1fa5ebe1384434e904b33bb7de8f0a3d6e8bfdc5/mailnews/compose/src/nsMsgSend.cpp#3043
But when I do a similar thing in IMAP, it builds OK but I get a "not thread-safe" crash. I guess that's the same problem you point out about the imap thread vs. main thread. I assume SMTP runs on main thread.

There doesn't seem to be a hard technical reason why nsINSSErrorsService can't be used off the main thread. Your patch proves that. There's just a general don't-use-XPCOM-off-the-main-thread guideline, which is a good one... except that the IMAP code violates it left right and centre :-)
The nsComPtr refcounting can make things really troublesome when it comes to cleaning up - it's hard to guarantee which thread objects will be freed on, which leads to all kinds of problems (e.g. Bug 1586494).

Also, never found where the "OnStopRunning" for select might be, and if it exists, I hope it runs on main thread.

Yep - they can be hard to track down (it'll be a call on a listener, but it won't be obvious at the point of issue). In any case, it'll be out in javascript land, so it will be on the main thread. If it turns out to be a pressing issue flag me with an NI or something and I'll have a poke about!

Comment 15

[Wayne Mery (:wsmwk)]

Do we know what caused this regression?

(In reply to Ben Campbell from comment #10)

...
I've not had much of a dig around (I'm not sure how the SELECT goes from the GUI through down to the IMAP command), but that log rather implies that the IMAP protocol is told to perform the SELECT by running an imap: URL (I think pretty much all the IMAP protocol is driven like this - I know there are a couple of exceptions, but on the whole I think URLs are the main interface). This implies that there is a URL listener somewhere with an OnStopRunningUrl() callback which could pick up errors during SELECT and deal with them appropriately. Same goes for all the other IMAP operations, but as you point out, doing it for SELECT should handle the vast bulk of such cases.

But yeah, I think that's worth moving to another bug.

Do we have that bug created?

Comment 16

[Steve]

Wayne posted: "Duplicate of this bug: 1671736"

I don't think this is a duplicate of bug 1671736, per se. Bug 1671736 relates to a problem arising from having changed a certificate in Dovecot. I found this bug without having changed anything about my working Dovecot instance. (Just FYI, my IMAP server instance uses certificates I created using a local certificate agency implemented by "Certificate Manager" in pfSense. I've configured this pfSense as a trusted root authority throughout my LAN and elder versions of Thunderbird (and various other tools) work fine with the same certificate.)

I accept that both bugs relate to sub-par handling of SSL in Thunderbird - so there is, at least, this link between the bugs.

Comment 17

[gene smith]

I think the "regression" is just that moz platform now is stricter with TLS -- not caused by a specific bug fix. The problems is we don't provide good error messages when something goes wrong with TLS. The fix I propose for this bug will at least provide a general message that something is wrong and suggest some things to fix but only for "non-overridable" errors (e.g., <= TLS1.2 on server).

The other bug that I haven't created yet is the fact that you must (*) click "get mail" to see an override prompt, e.g., when you have a self-signed cert on the server. Just selecting INBOX or any folder should do this. Fixing this may also allow finer grained messages for non-overridable errors a la SMTP since, per Ben, it will move error processing to the main thread.

(*) You will get the override message if you re-create the account from scratch with account mgr so new accounts won't see this problem.

Comment 18

[gene smith]

I tried to push this to try server with several variations on the commit message and get the same error each time:
Exception: Missing fetch job for toolchain-toolchain-linux64-cbindgen: linux64-rust-1.47

Am I doing something wrong? Has the procedure changed for pushing try commits?
Example of failed push: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=6f6a3c00fc1788cb796028dba89e8f1b49d67aed

Also, when I submit a patch for this should I ask for review from both Magnus and Ben or just one?

Comment 19

[Magnus Melin [:mkmelin]]

I don't know, maybe your code was based on a too old commit? That rust artifact was added sometime this week IIRC. So rebase and retry (though the tree is currently broken-ish.). One reviewer is enough. You can send this to Ben.

Comment 20

[Magnus Melin [:mkmelin]]

Comment on attachment 9190392 [details] [diff] [review]
t2.diff

Review of attachment 9190392 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/imap/src/nsImapProtocol.cpp
@@ +4879,5 @@
> +          // SSL_ERROR_BAD_CERT_DOMAIN from security/nss/lib/ssl/sslerr.h
> +          // rv = 0x80000000 + 0x00450000 + 0x00150000 + 0x00002ff4 = 0x805A2ff4
> +          int32_t sec_error = -1 * NS_ERROR_GET_CODE(rv); // = 0xFFFFD00C
> +          if (!mozilla::psm::ErrorIsOverridable(sec_error)) 
> +            AlertUserEventUsingName("imapTlsError");

It seems it could be better to pass the secinfo up to the UI and let it decide what it wants to show/handle the sec error, and not have the IMAP protocol do user actions.
For debugging this, probably the actual hex error code would also come in handy.

Comment 21

[gene smith]

Attachment: Bug1676141-add-alert-for-non-overridable-tls-error.patch

It seems it could be better to pass the secinfo up to the UI and let it decide what it wants to show/handle the sec error, and not have the IMAP protocol do user actions.

I think this is what Ben has been saying by using the "on stop url" callback for the imap SELECT url. But I have no idea how to find and/or produce this function in "JS land" as he calls it.

There are many calls to AlertUserEventUsingName() for things other than TLS errors scattered over the imap code. They seem to just cause a pop up message to occur and don't block or slow down the protocol activities.

What I'm proposing here is a simple interim fix that will avoid tb being completely mute and seemingly freezing up when a non-overridable TLS error occurs. This doesn't affect the overridable TLS errors.

For debugging this, probably the actual hex error code would also come in handy.

I don't see a way to pass a hex error code to the "alert" function and not sure it would help the end-user that much since they would have to know about and look it up at the UK web site that decodes mozilla errors and it doesn't include more recent ones. I tried to have the finer grained message for TLS appear in the pop up sort of like SMTP but it didn't work due to "not thread-safe" errors (comment 12 above). Mozilla has detailed strings corresponding to each possible TLS error so if these could appear in the pop-up you wouldn't need an error code at all. These detailed strings do appear with TLS errors when sending via SMTP. Not sure about other protocols, POP etc.

Anyhow, here's the proposed patch.
P/S: The try build is OK now. I left an old "try" commit in that messed it up.

Comment 22

[Ben Campbell]

Comment on attachment 9192875 [details] [diff] [review]
Bug1676141-add-alert-for-non-overridable-tls-error.patch

Review of attachment 9192875 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/imap/src/nsImapProtocol.cpp
@@ +4833,5 @@
> +            NS_ERROR_GET_SEVERITY(rv) == NS_ERROR_SEVERITY_ERROR) {
> +          // It's an error of class 21 (SSL/TLS/Security), e.g., overridable
> +          // SSL_ERROR_BAD_CERT_DOMAIN from security/nss/lib/ssl/sslerr.h
> +          // rv = 0x80000000 + 0x00450000 + 0x00150000 + 0x00002ff4 = 0x805A2ff4
> +          int32_t sec_error = -1 * NS_ERROR_GET_CODE(rv);  // = 0xFFFFD00C

This all looks fine to me, although looking at the implementation of NSSErrorsService::GetErrorClass(), it does the same checks as here and then _also_ calls `mozilla::psm::IsNSSErrorCode()`. I'd have thought the NS_ERROR_ checks above were enough to identify an NSS error. Does `GetErrorClass()` know something we don't? (I doubt it, but probably worth checking out).
https://searchfox.org/mozilla-central/source/security/manager/ssl/NSSErrorsService.cpp#123

@@ +4852,5 @@
> +              if (transportSecInfo) {
> +                mailNewsUrl->SetFailedSecInfoInternal(transportSecInfo);
> +              }
> +            }
> +          }

This is good - the secInfo is still stashed away and made available to the `onStopRunningUrl()`, which I think was part of Magnus' concern in comment 20.
I still agree that IMAP shouldn't be displaying alert boxes directly, but it already does it all over the place and this patch obviously improves the user experience, so I say go for it.
I'll file a separate bug to ultimately move the user-facing error handling out of IMAP.

Comment 23

[gene smith]

This all looks fine to me, although looking at the implementation of NSSErrorsService::GetErrorClass(), it does the same checks as here and then also calls mozilla::psm::IsNSSErrorCode(). I'd have thought the NS_ERROR_ checks above were enough to identify an NSS error. Does GetErrorClass() know something we don't? (I doubt it, but probably worth checking out).
https://searchfox.org/mozilla-central/source/security/manager/ssl/NSSErrorsService.cpp#123

Looks like the call to IsNSSErrorCode() checks the error to make sure it is in the range for SEC_, SSL or PKIX_ errors before passing the code on to ErrorIsOverridable(). If it's not in one of the ranges, ErrorIsOverridable() is never called and the function GetErrorClass() returns an error.

For us I don't think it is necessary to check this since our call to ErrorIsOverridable() will just return false if the code is not one of the SEC, SSL or PKIX codes explicitly listed in the switch statement of ErrorIsOverridabe(): https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/security/manager/ssl/NSSErrorsService.cpp#139.

The only possible reason I can think of for doing the finer grained check by adding a call to IsNSSErrorCode() would be to skip the stash of error info into the URL if the error is not really an NSS error. But I don't see a reason to skip the stash for this.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c1739ebe238d
Add an alert for non-overridable TLS errors. r=benc

Comment 25

[Magnus Melin [:mkmelin]]

Not for 78, since it has strings.

Comment 26

[pb]

should this be fixed in 78.14.0 (ubuntu 20.04)? I seem to have the same issue after a certificate change on a long running server (debian 9). I changed the certificate, the certificate is bad, but I ran it only on a private server for myself. It works fine with a couple of other email clients (such as claws or manually login (text) or android k9... etc. and ignoring the certificate error) but not on thunderbird. With thunderbird I get on the server

SSL_read() failed: error: ... :SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42

coming from thunderbird I guess. After deleting the certificates and deleting certs9.db and certs_override.txt thunderbird asks me for accepting an execption regarding a bad certificate, which I happily do, but after that I have again the same error. The Inbox is left intact (on the server) but I cannot retrieve any email. I remember to have upgraded the working installion from an age old thunderbird profile around 3-4 years ago; which already had a bad certificate. Now that 5 year old certificate expired and installing a new (bad) certificate works on every email client but thunderbird. I'd do a new bug report, but it appears that one is the same and it has the error and the comment (Fixed as well as wontfix for 78 - and I do have 78.*) which left me wondering. I'd also be fine with a workaround (some about:config and 'acceptanycertificatewithoutcheck: true' or something like that).

Comment 27

[gene smith]

I doubt if this ever made it to any TB 78 at all since it requires translations so won't be in ubuntu release until they move to tb 91 for LTS 20.04. I suspect it is in 91 (next TB release, skipped a bunch of numbers) but not sure.
I don't remember the details but there may be workarounds as described in comment 2 above.
You can download and install 91 with ubuntu 20.04. I have.

Comment 28

[pb]

aaahhh - thanks. I have a manjaro lying around on which there is TB 91.4.0 and there it works fine out of the box. I'll happily upgrade... Thanks again

Comment 29

[gene smith]

Just a "heads-up" but if you run 91 and then go back and try to run 78 for some reason, you'll maybe see something about needing to start a new profile. You can override this by starting 78 with command line option --allow-downgrade if you really need to run it.