6 ms·

I've noticed that many of the linux repos are not up to date. If you're using those, you probably need to install it directly from the website to get the latest

by ajosh 6y ago

I've noticed that many of the linux repos are not up to date. If you're using those, you probably need to install it directly from the website to get the latest version and see the updates. The major features that have come out lately that I've noticed are first-party calendar integration and first-party GPG support. There was a calendar integration but I always found it to be a bit funny and hard to get working all of the way. I never had problems with Enigmail, however. Both features work much more solidly as an included part of Thunderbird. There are other, smaller features that have come in like having e-mail addresses in the To/CC/BCC lines be places into ovals to show them as a distinct, drag-able element. The Thunderbird codebase is old and is full of a ton of features, transforming it in a way that is true to its past and moves towards a better future is going to take time but it is coming along. Sure, some of the major features were available as plug-ins but they're much more solid now that they're built-in.

AdmiralAsshat 6y ago
I thought I had installed the flatpak for Thunderbird some time ago, but apparently I was wrong; I'm still pulling the RPMs down from Fedora repos. Those seem pretty close to upstream, however. I got an update for it just last week.
lrem 6y ago
First-party GPG support would be so nice to have some decades ago. By now seems everyone admitted defeat. Companies standardized on email as notification system for "you got a message in the actually secure medium". Humans standardized on using some inherently safe (but usually not open) communicator. Who is there still wanting secure email?
- ajosh 6y ago
  This question (and the one above right now) are good points. GPG isn't really a killer feature right now. I likewise haven't needed secure e-mail in a while. I just happened to notice it when it migrated stuff over. I stopped using my Yubikey with gpg a while back. All of that said - I'm replying to this message and not the other because there is one use for secure e-mail that may make a difference: DeltaChat. Deltachat uses autocrypt which includes your public key in headers. With autocrypt in place, Thunderbird can still read DeltaChat messages. I'm not sure if DeltaChat will ever take off in large numbers but it seems like a decent option for secure chat/IM.
  - lrem 6y ago
    First time I hear of DeltaChat. Does it use email as the actual transport? Sounds prone to stupid latency. What's the benefit over Matrix?
    - brnt 6y ago
      It does, and the benefit is that anyone with an email address can already be approached via Deltachat, because all it does is send and receive email through the Autocrypt protocol, which gracefully degrades with clients that don't support it.
      - akerl_ 6y ago
        Gracefully degrading for clients that don’t support it is an un-goal of encrypted messaging.
        ekianjo 6y ago
        You cannot read encrypted messages if you do not have gpg support. Not sure what your comment is about.
    - gsich 6y ago
      Latency is not that bad usually.
- bsder 6y ago
  > By now seems everyone admitted defeat. Well, since everybody is using Gmail or Office365 anyway, encrypted email is kind of pointless, no?
  - gsich 6y ago
    GPG works with all mail providers.
  - ekianjo 6y ago
    If you encrypt something within gmail only you and your recipient can read it. Not sure what you mean ?
    - iudqnolq 6y ago
      Their point is so can gmail, and thus the govt through various channels.
      - gsich 6y ago
        No? All they see is yhe encrypted mail.
- submeta 6y ago
  > Companies standardized on email as notification system for "you got a message in the actually secure medium". This is so ridiculous. I have to log in to a dozen different sites to download documents. And those sites are 2FA secured, so I have no means to automate. Of course these companies never heared of (REST) APIs. - This is such a step backwards.
  - lrem 6y ago
    Frankly, I prefer my bank and insurance to have minimal access surface.
    - 411111111111111 6y ago
      But why don't they support just sending them to your email, gpg encrypted if sensitive? They'd still be secure and significantly easier to archive I know it's for liability reasons, but annoying nontheless
      - lrem 6y ago
        That's an extra thing they could get wrong. Seeing how some banks cannot deal with copy-pasting my legal name correctly, I prefer to not give them anything else out of the ordinary.
ryukafalz 6y ago
I still haven't been able to get the new GPG integration working with my Yubikey, that whole path seems not super well-supported yet. And Enigmail doesn't run on more recent versions of Thunderbird. I haven't had to work with encrypted email for a little bit, but I think the next time I do it'll push me to another email client if I still haven't gotten this working.
- ylk 6y ago
  You'll have to do some additional configuration: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards
  - ryukafalz 6y ago
    Right, even with that I haven't gotten it working. I'm sure I'm doing something wrong, but the failure modes don't make it particularly clear what the problem is.
pizza234 6y ago
> I've noticed that many of the linux repos are not up to date This is very tricky. Thunderbird keeps breaking addons compatibility (as an end user, I don't care if this is justified or not), by supporting main versions for short times (v68 was released less than two years ago). An O/S like LTS Ubuntu, which has a 4+ years support cycles, is systematically forced to break TB compatibility during each cycle, which is contrary to the O/S versioning guidelines (which typically freeze the program versions, with the exception of security upgrades, e.g. web browsers). As a side effect, addons, which give TB a significant value (I'd argue that they give its only value - even Google Calendar is not natively supported) slowly disappear. Thunderbird is essentially systematically and forcefully breaking versioning and compatibility. I believe something's broken in the team/company.
- silon42 6y ago
  IMO, distros should start packaging good addons anyway.
- coryrc 6y ago
  Given the resources available, I don't think they can make the product better and maintain compatibility for long. Given the previous decade+ of minimal enhancement to the point where it's now just the tiniest fraction of email users, standing still is a guaranteed death sentence.
  - lstamour 6y ago
    I figure the easy (though actually hard) answer is to try to collect commonly used add-ons in one central place and update those there, the same way that TypeScript can always keep moving as a language while centrally publishing new versions of types with backwards compatibility to older language APIs. Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration as downloadable add-ons that extensions could use. You could add existing extensions to a giant test-suite that ensures common extensions don't break. You could combine all these approaches, of course. Personally, I'd push to have common community add-ons maintained centrally though, such that if they change an API and it's a relatively easy fix, project maintainers could automate a "code-mod" or fix to rename and use the new API, or shim support for the old API? It's not easy, exactly, it requires taking ownership of a community to such an extent that you can ship API changes as useful codemods to help automate community porting efforts. That said, I've often found that even if plugin APIs don't change, requirements to list compatible API versions in plugin manifests can make it hard to use new plugins until app authors can get around to updating the manifest to a new version and ensure compatibility for their extension. It might be interesting if app or extension stores could run tests to confirm if a plugin is compatible or not and if not, maybe suggestions could be made to point projects to new APIs and porting guides, if not outright automated PRs for fixes?

by ajosh 6y ago

AdmiralAsshat 6y ago

I thought I had installed the flatpak for Thunderbird some time ago, but apparently I was wrong; I'm still pulling the RPMs down from Fedora repos. Those seem pretty close to upstream, however. I got an update for it just last week.

lrem 6y ago

First-party GPG support would be so nice to have some decades ago. By now seems everyone admitted defeat. Companies standardized on email as notification system for "you got a message in the actually secure medium". Humans standardized on using some inherently safe (but usually not open) communicator. Who is there still wanting secure email?

ajosh 6y ago
This question (and the one above right now) are good points. GPG isn't really a killer feature right now. I likewise haven't needed secure e-mail in a while. I just happened to notice it when it migrated stuff over. I stopped using my Yubikey with gpg a while back. All of that said - I'm replying to this message and not the other because there is one use for secure e-mail that may make a difference: DeltaChat. Deltachat uses autocrypt which includes your public key in headers. With autocrypt in place, Thunderbird can still read DeltaChat messages. I'm not sure if DeltaChat will ever take off in large numbers but it seems like a decent option for secure chat/IM.
- lrem 6y ago
  First time I hear of DeltaChat. Does it use email as the actual transport? Sounds prone to stupid latency. What's the benefit over Matrix?
  - brnt 6y ago
    It does, and the benefit is that anyone with an email address can already be approached via Deltachat, because all it does is send and receive email through the Autocrypt protocol, which gracefully degrades with clients that don't support it.
    - akerl_ 6y ago
      Gracefully degrading for clients that don’t support it is an un-goal of encrypted messaging.
      - ekianjo 6y ago
        You cannot read encrypted messages if you do not have gpg support. Not sure what your comment is about.
  - gsich 6y ago
    Latency is not that bad usually.
bsder 6y ago
> By now seems everyone admitted defeat. Well, since everybody is using Gmail or Office365 anyway, encrypted email is kind of pointless, no?
- gsich 6y ago
  GPG works with all mail providers.
- ekianjo 6y ago
  If you encrypt something within gmail only you and your recipient can read it. Not sure what you mean ?
  - iudqnolq 6y ago
    Their point is so can gmail, and thus the govt through various channels.
    - gsich 6y ago
      No? All they see is yhe encrypted mail.
submeta 6y ago
> Companies standardized on email as notification system for "you got a message in the actually secure medium". This is so ridiculous. I have to log in to a dozen different sites to download documents. And those sites are 2FA secured, so I have no means to automate. Of course these companies never heared of (REST) APIs. - This is such a step backwards.
- lrem 6y ago
  Frankly, I prefer my bank and insurance to have minimal access surface.
  - 411111111111111 6y ago
    But why don't they support just sending them to your email, gpg encrypted if sensitive? They'd still be secure and significantly easier to archive I know it's for liability reasons, but annoying nontheless
    - lrem 6y ago
      That's an extra thing they could get wrong. Seeing how some banks cannot deal with copy-pasting my legal name correctly, I prefer to not give them anything else out of the ordinary.

ryukafalz 6y ago

I still haven't been able to get the new GPG integration working with my Yubikey, that whole path seems not super well-supported yet. And Enigmail doesn't run on more recent versions of Thunderbird. I haven't had to work with encrypted email for a little bit, but I think the next time I do it'll push me to another email client if I still haven't gotten this working.

ylk 6y ago
You'll have to do some additional configuration: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards
- ryukafalz 6y ago
  Right, even with that I haven't gotten it working. I'm sure I'm doing something wrong, but the failure modes don't make it particularly clear what the problem is.

pizza234 6y ago

> I've noticed that many of the linux repos are not up to date This is very tricky. Thunderbird keeps breaking addons compatibility (as an end user, I don't care if this is justified or not), by supporting main versions for short times (v68 was released less than two years ago). An O/S like LTS Ubuntu, which has a 4+ years support cycles, is systematically forced to break TB compatibility during each cycle, which is contrary to the O/S versioning guidelines (which typically freeze the program versions, with the exception of security upgrades, e.g. web browsers). As a side effect, addons, which give TB a significant value (I'd argue that they give its only value - even Google Calendar is not natively supported) slowly disappear. Thunderbird is essentially systematically and forcefully breaking versioning and compatibility. I believe something's broken in the team/company.

silon42 6y ago
IMO, distros should start packaging good addons anyway.
coryrc 6y ago
Given the resources available, I don't think they can make the product better and maintain compatibility for long. Given the previous decade+ of minimal enhancement to the point where it's now just the tiniest fraction of email users, standing still is a guaranteed death sentence.
- lstamour 6y ago
  I figure the easy (though actually hard) answer is to try to collect commonly used add-ons in one central place and update those there, the same way that TypeScript can always keep moving as a language while centrally publishing new versions of types with backwards compatibility to older language APIs. Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration as downloadable add-ons that extensions could use. You could add existing extensions to a giant test-suite that ensures common extensions don't break. You could combine all these approaches, of course. Personally, I'd push to have common community add-ons maintained centrally though, such that if they change an API and it's a relatively easy fix, project maintainers could automate a "code-mod" or fix to rename and use the new API, or shim support for the old API? It's not easy, exactly, it requires taking ownership of a community to such an extent that you can ship API changes as useful codemods to help automate community porting efforts. That said, I've often found that even if plugin APIs don't change, requirements to list compatible API versions in plugin manifests can make it hard to use new plugins until app authors can get around to updating the manifest to a new version and ensure compatibility for their extension. It might be interesting if app or extension stores could run tests to confirm if a plugin is compatible or not and if not, maybe suggestions could be made to point projects to new APIs and porting guides, if not outright automated PRs for fixes?