Addons no longer maintained.
When I was working on my addon in the beginning I used some code from a small addon that
did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work how to update my own
to a MailExtensions addon. The original popmaillistrecipients addon is now well out of
date. (But I really like using it)
Is there any way that I can put the web extension version on thunderbird.net other than
offering it to the original author? I sent him the bootstrapped version which to my
knowledge he didn't use...
Blessings
Graeme
I think this is a valid and important fundamental question:
- If an addon is clearly unmaintained, meaning it does not work with current supported versions of Thunderbird (TB 60 at the moment)
- and the addon is open-source
- and there is another author who made an update that works, and fulfills the original extension's purpose
- and we gave the original author a chance to respond and he either does not respond for a reasonable time frame or cannot give a good explanation,
then do we allow the new author to take over maintenance and maintainership of the addon?
I think we should, yes.
And I think that question is very important for our addons and for our users, because I think there are a lot of addons that fall into this specific category. We could help users this way.
And I'd like to thank people who go through the length of updating third party addons, and not put bureaucratic roadblocks in their way. The process should be easy for the new author, esp. when the old author is clearly and obviously absent.
I think there should be an official and maybe even automated process for that, which checks the above conditions. 1. and 2. above are known from existing ATN meta data. Point 3 just needs a third party upload feature that's enabled under conditions 1 and 2, and point 4 just needs an automated email to the original author.
Ben
Graeme wrote on 06.02.19 17:34:
When I was working on my addon in the beginning I used some code from a small addon that did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work how to update my own to a MailExtensions addon. The original popmaillistrecipients addon is now well out of date. (But I really like using it)
Is there any way that I can put the web extension version on thunderbird.net other than offering it to the original author? I sent him the bootstrapped version which to my knowledge he didn't use...
Blessings
Graeme_______________________________________________
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
If this approach is taken, please be careful.
There are some examples of maintainers transferring ownership of a
repo to another party, who ends up being malicious and incorporating
backdoors (e.g.
https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/).
Such situations could be easily exaggerated if we allow the original
author to be bypassed entirely.
Of course, reviews are performed on extensions, which would help
mitigate this, but it's still tricky. If users trusted the previous
author, but don't necessarily trust changes of any kind from other
authors, automatically allowing this is concerning.
However, I can partially envision a feature where:
- An original add-on is unmaintained
- A new developer forks it and fixes it
- A new developer uploads to the extension store and flags it as a
"maintained fork" of some other add-on - TB notifies users of new "maintained forks" automatically, but does
not replace the old version or automatically switch them. - The user chooses whether to switch.
// Josiah Bruner
On Wed, Feb 6, 2019 at 2:00 PM Ben Bucksch ben.bucksch@beonex.com wrote:
I think this is a valid and important fundamental question:
If an addon is clearly unmaintained, meaning it does not work with current supported versions of Thunderbird (TB 60 at the moment)
and the addon is open-source
and there is another author who made an update that works, and fulfills the original extension's purpose
and we gave the original author a chance to respond and he either does not respond for a reasonable time frame or cannot give a good explanation,
then do we allow the new author to take over maintenance and maintainership of the addon?
I think we should, yes.
And I think that question is very important for our addons and for our users, because I think there are a lot of addons that fall into this specific category. We could help users this way.
And I'd like to thank people who go through the length of updating third party addons, and not put bureaucratic roadblocks in their way. The process should be easy for the new author, esp. when the old author is clearly and obviously absent.
I think there should be an official and maybe even automated process for that, which checks the above conditions. 1. and 2. above are known from existing ATN meta data. Point 3 just needs a third party upload feature that's enabled under conditions 1 and 2, and point 4 just needs an automated email to the original author.
Ben
Graeme wrote on 06.02.19 17:34:
When I was working on my addon in the beginning I used some code from a small addon that did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work how to update my own to a MailExtensions addon. The original popmaillistrecipients addon is now well out of date. (But I really like using it)
Is there any way that I can put the web extension version on thunderbird.net other than offering it to the original author? I sent him the bootstrapped version which to my knowledge he didn't use...
Blessings
Graeme
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
Josiah Bruner wrote on 06.02.19 20:11:
...
Such situations could be easily exaggerated if we allow the original
author to be bypassed entirely.
a) We'd only bypass authors that are non-responsible or unreasonable
Of course, reviews are performed on extensions, which would help
mitigate this, but it's still tricky.
b) The extension still needs to go through the normal addon review
process. Hopefully, that would catch malicious code.
npm does not have such a review process, IIRC.
If users trusted the previous author, but don't necessarily trust changes of any kind from other
authors, automatically allowing this is concerning.
Well, we're talking about extensions that are not maintained. So, there
is no author anymore that users could trust.
And the extension will simply disable.
Or, worse, users will hold off updating Thunderbird, because they depend
on that addon. That would be the worst security-wise, because they users
are exposed to all known security holes.
So, it is very much in the interest of security to keep the extensions
updated.
However, I can partially envision a feature where:
- An original add-on is unmaintained
- A new developer forks it and fixes it
- A new developer uploads to the extension store and flags it as a
"maintained fork" of some other add-on - TB notifies users of new "maintained forks" automatically, but does
not replace the old version or automatically switch them. - The user chooses whether to switch.
I don't like "redirectmail redone" extension names.
More importantly, I don't see how the end user's decision can be any
more informed than the addon reviewer. You're essentially just pushing
responsibility from the addon reviewers to the end users. The end user
has no way to tell whether the new extension is trust-worthy or not. You
can know that only by looking at the code.
Ben
Hey Ben,
Thanks for your comments. Responses inline...
On 2/6/19 3:17 PM, Ben Bucksch wrote:
Josiah Bruner wrote on 06.02.19 20:11:
...
Such situations could be easily exaggerated if we allow the original
author to be bypassed entirely.
a) We'd only bypass authors that are non-responsible or unreasonable
A lack of responsiveness or unreasonableness from Author A who I (used
to) trust does not mean that I should automatically trust arbitrary
Author B.
On another note, by "bypass" I meant that the attack steps become
easier. Where before an attacker had to social engineer his way into
being a maintainer (which necessarily requires original author
engagement), an attacker's opportunities now expand to authors who don't
engage. This is more or less trivial (e.g. the author dies, the author
stops checking email entirely, an attacker makes an annoying number of
"overtake" attempts until the original author just ignores
extension-related emails entirely, etc.).
Of course, reviews are performed on extensions, which would help
mitigate this, but it's still tricky.
b) The extension still needs to go through the normal addon review
process. Hopefully, that would catch malicious code.
npm does not have such a review process, IIRC.
Yes, hopefully, but it's hard to guarantee that. What if the "backdoor"
is a minor crypto bug? Those are notoriously difficult to detect, but
have serious implications.
If users trusted the previous author, but don't necessarily trust
changes of any kind from other
authors, automatically allowing this is concerning.
Well, we're talking about extensions that are not maintained. So, there
is no author anymore that users could trust.
Agreed, although the user may not know that.
And the extension will simply disable.
Or, worse, users will hold off updating Thunderbird, because they depend
on that addon. That would be the worst security-wise, because they users
are exposed to all known security holes.
Totally agree.
...
However, I can partially envision a feature where:
- An original add-on is unmaintained
- A new developer forks it and fixes it
- A new developer uploads to the extension store and flags it as a
"maintained fork" of some other add-on - TB notifies users of new "maintained forks" automatically, but does
not replace the old version or automatically switch them. - The user chooses whether to switch.
I don't like "redirectmail redone" extension names.
More importantly, I don't see how the end user's decision can be any
more informed than the addon reviewer. You're essentially just pushing
responsibility from the addon reviewers to the end users. The end user
has no way to tell whether the new extension is trust-worthy or not. You
can know that only by looking at the code.
The difference is that we aren't automatically "pushing" the changes to
the user without their consent. By simply suggesting an add-on, we force
them to re-consider whether they trust the author, add-on, and TB.
Sure, you could make the case that users will blindly accept the
suggestion, so it's no better than doing it automatically. In that case,
I again question the safety of the feature entirely.
As an example, here's what I do not want to see happen:
1. I, Josiah Bruner, trust the current author and maintainers of
Enigmail to provide me a safe PGP extension.
2. I, Josiah Bruner, trust TB to ensure that the integrity of the
upload extensions stay in-tact.
3. Eventually, Enigmail becomes unmaintained and the author retires to
an island without internet connectivity.
4. A malicious attacker waits until the extension stops working and
then immediately submits a "takeover" request.
5. The Enigmail author never responds.
6. During the review process, I, Josiah Bruner, notice that Enigmail is
not compatible with the latest version of TB. That's sad, but whatever.
I just suck it up and don't use PGP encryption with TB.
7. During the review process the addon reviewer looks at the code
changes (which are potentially huge). There are a lot of legitimate
features added, but also slight changes to the crypto handling.
8. The addon reviewer, not being a crypto expert, decides the new
version of Enigmail is okay and pushes it to ATN.
9. I, Josiah Bruner, start TB one day and discover that Enigmail now
works again. I rejoice and assume the author's (long) vacation has ended.
10. 1 year later a press release comes out which states that millions
of PGP encrypted emails were not encrypted properly because the
Thunderbird Team allowed malicious changes to be made to Enigmail
without the original author's permission. Users were not made aware.
Worse, the TB team did review the changes and decided it was okay to ship.
11. Many users no longer trust TB.
My intention in bringing this up is not to unnecessarily block such a
feature, which definitely could be useful. It is to demonstrate that
care would need to be taken when designing and implementing this.
Specifically, I would highly suggest working with Mozilla's security
team (or a third-party security firm) to ensure it does not backfire.
I am not aware of any extension or package management platforms who
allow arbitrary individuals to "take over" well-used packages, which
makes security analysis much harder. The concept would be more or less
novel, and would need to be considered as such by a security team.
There are also potential legal implications, which I am ignoring here.
Regards,
Josiah Bruner
In the past I have adopted an add-on by contacting the original author and having him add me on amo as owner.
I think that’s the way it should go, but if the original author doesn’t reply when contacted, there should be other ways to take over an extension.
That would be a lot better then another “add-on” Improved, “add-on” Next or whatever people call it and add to amo/atn and where users have to search for, because their original add-on stopped working or was disabled.
Onno
On 6 Feb 2019, at 19:59, Ben Bucksch ben.bucksch@beonex.com wrote:
I think this is a valid and important fundamental question:
If an addon is clearly unmaintained, meaning it does not work with current supported versions of Thunderbird (TB 60 at the moment)
and the addon is open-source
and there is another author who made an update that works, and fulfills the original extension's purpose
and we gave the original author a chance to respond and he either does not respond for a reasonable time frame or cannot give a good explanation,
then do we allow the new author to take over maintenance and maintainership of the addon?
I think we should, yes.
And I think that question is very important for our addons and for our users, because I think there are a lot of addons that fall into this specific category. We could help users this way.
And I'd like to thank people who go through the length of updating third party addons, and not put bureaucratic roadblocks in their way. The process should be easy for the new author, esp. when the old author is clearly and obviously absent.
I think there should be an official and maybe even automated process for that, which checks the above conditions. 1. and 2. above are known from existing ATN meta data. Point 3 just needs a third party upload feature that's enabled under conditions 1 and 2, and point 4 just needs an automated email to the original author.
Ben
Graeme wrote on 06.02.19 17:34:
When I was working on my addon in the beginning I used some code from a small addon that did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work how to update my own to a MailExtensions addon. The original popmaillistrecipients addon is now well out of date. (But I really like using it)
Is there any way that I can put the web extension version on thunderbird.net other than offering it to the original author? I sent him the bootstrapped version which to my knowledge he didn't use...
Blessings
Graeme
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
A few thoughts...
Most users don't put any thought at all into whether they trust the
authors of add-ons and don't even have any idea who the authors are. If
they need an add-on and it's available in ATN, that's all they care
about. The vast majority of users have not invested even a moment of
thought into whether they should trust any particular add-on author, and
therefore will not care or invest a moment of thought if the add-on is
taken over by a new author.
The add-on review process, not "trust" in any particular author, is what
is supposed to keep users safe. The people approving add-ons using the
review tools aren't, or at least shouldn't be, basing their reviews on
who the authors are, they should be basing them on the code. That is
true whether the person submitting a new add-on or an update to an
add-on is the original author or someone who has taken it over from them.
Enigmail could have a security bug or could be backdoored NOW with some
complex, difficult-to-spot thing that could have already gotten past the
ATN reviewers. I'm not saying it does, I'm saying I see no reason why it
would be any more or less likely whether it were Patrick submitting new
revisions or someone else.
Tough cases make for bad law. Using Enigmail as your example is distorts
the decision-making process. Most add-ons are far less complex than
Enigmail and have far less potential for security vulnerabilities. While
I agree with you that special care should be taken with regards to
complex add-ons that are specifically related to security, drawing
general conclusions from that to how careful we need to be about every
single add-on that becomes unmaintained on ATN is unwarranted.
In my opinion, the benefit of being able to hand off abandoned add-ons
to new maintainers who are willing to make them work again far outweighs
the amorphous risks you have described here.
(I'm speaking as a Thunderbird user, a user of many add-ons, an author
and maintainer of many add-ons, and someone with 30 years of information
security experience who is now the CISO of a FinTech start-up.)
jik
On 2/6/19 4:06 PM, Josiah Bruner wrote:
Hey Ben,
Thanks for your comments. Responses inline...
On 2/6/19 3:17 PM, Ben Bucksch wrote:
Josiah Bruner wrote on 06.02.19 20:11:
...
Such situations could be easily exaggerated if we allow the original
author to be bypassed entirely.
a) We'd only bypass authors that are non-responsible or unreasonable
A lack of responsiveness or unreasonableness from Author A who I (used
to) trust does not mean that I should automatically trust arbitrary
Author B.
On another note, by "bypass" I meant that the attack steps become
easier. Where before an attacker had to social engineer his way into
being a maintainer (which necessarily requires original author
engagement), an attacker's opportunities now expand to authors who
don't engage. This is more or less trivial (e.g. the author dies, the
author stops checking email entirely, an attacker makes an annoying
number of "overtake" attempts until the original author just ignores
extension-related emails entirely, etc.).
Of course, reviews are performed on extensions, which would help
mitigate this, but it's still tricky.
b) The extension still needs to go through the normal addon review
process. Hopefully, that would catch malicious code.
npm does not have such a review process, IIRC.
Yes, hopefully, but it's hard to guarantee that. What if the
"backdoor" is a minor crypto bug? Those are notoriously difficult to
detect, but have serious implications.
If users trusted the previous author, but don't necessarily trust
changes of any kind from other
authors, automatically allowing this is concerning.
Well, we're talking about extensions that are not maintained. So,
there is no author anymore that users could trust.
Agreed, although the user may not know that.
And the extension will simply disable.
Or, worse, users will hold off updating Thunderbird, because they
depend on that addon. That would be the worst security-wise, because
they users are exposed to all known security holes.
Totally agree.
...
However, I can partially envision a feature where:
- An original add-on is unmaintained
- A new developer forks it and fixes it
- A new developer uploads to the extension store and flags it as a
"maintained fork" of some other add-on - TB notifies users of new "maintained forks" automatically, but does
not replace the old version or automatically switch them. - The user chooses whether to switch.
I don't like "redirectmail redone" extension names.
More importantly, I don't see how the end user's decision can be any
more informed than the addon reviewer. You're essentially just
pushing responsibility from the addon reviewers to the end users. The
end user has no way to tell whether the new extension is trust-worthy
or not. You can know that only by looking at the code.
The difference is that we aren't automatically "pushing" the changes
to the user without their consent. By simply suggesting an add-on, we
force them to re-consider whether they trust the author, add-on, and TB.
Sure, you could make the case that users will blindly accept the
suggestion, so it's no better than doing it automatically. In that
case, I again question the safety of the feature entirely.
As an example, here's what I do not want to see happen:
1. I, Josiah Bruner, trust the current author and maintainers of
Enigmail to provide me a safe PGP extension.
2. I, Josiah Bruner, trust TB to ensure that the integrity of the
upload extensions stay in-tact.
3. Eventually, Enigmail becomes unmaintained and the author
retires to an island without internet connectivity.
4. A malicious attacker waits until the extension stops working
and then immediately submits a "takeover" request.
5. The Enigmail author never responds.
6. During the review process, I, Josiah Bruner, notice that
Enigmail is not compatible with the latest version of TB. That's sad,
but whatever. I just suck it up and don't use PGP encryption with TB.
7. During the review process the addon reviewer looks at the code
changes (which are potentially huge). There are a lot of legitimate
features added, but also slight changes to the crypto handling.
8. The addon reviewer, not being a crypto expert, decides the new
version of Enigmail is okay and pushes it to ATN.
9. I, Josiah Bruner, start TB one day and discover that Enigmail
now works again. I rejoice and assume the author's (long) vacation has
ended.
10. 1 year later a press release comes out which states that
millions of PGP encrypted emails were not encrypted properly because
the Thunderbird Team allowed malicious changes to be made to
Enigmail without the original author's permission. Users were not made
aware. Worse, the TB team did review the changes and decided it was
okay to ship.
11. Many users no longer trust TB.
My intention in bringing this up is not to unnecessarily block such a
feature, which definitely could be useful. It is to demonstrate that
care would need to be taken when designing and implementing this.
Specifically, I would highly suggest working with Mozilla's security
team (or a third-party security firm) to ensure it does not backfire.
I am not aware of any extension or package management platforms who
allow arbitrary individuals to "take over" well-used packages, which
makes security analysis much harder. The concept would be more or less
novel, and would need to be considered as such by a security team.
There are also potential legal implications, which I am ignoring here.
Regards,
Josiah Bruner
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
Agreed first option is always to first get involved with the original
author and work something out.
I'm not too keen on allowing unauthorized takeovers. I doubt you can
even do that legally in most cases: licenses aside, authors do have
moral rights that usually are perpetual. I'd expect the name in
combination with the work to fall under that even if not trademarked.
What would be nice though, is if we could annotate add-ons to describe
what they are forked from. If add-on X is abandoned, someone would fork
it to create add-on Y, and Thunderbird could offer the user to start
using the forked add-on Y instead. But this would only be offered in
case the original was abandoned.
-Magnus
On 06-02-2019 23:34, Onno Ekker wrote:
In the past I have adopted an add-on by contacting the original author
and having him add me on amo as owner.
I think that’s the way it should go, but if the original author
doesn’t reply when contacted, there should be other ways to take over
an extension.
That would be a lot better then another “add-on” Improved, “add-on”
Next or whatever people call it and add to amo/atn and where users
have to search for, because their original add-on stopped working or
was disabled.
Onno
On 6 Feb 2019, at 19:59, Ben Bucksch <ben.bucksch@beonex.com
mailto:ben.bucksch@beonex.com> wrote:
I think this is a valid and important fundamental question:
- If an addon is clearly unmaintained, meaning it does not work
with current supported versions of Thunderbird (TB 60 at the moment) - and the addon is open-source
- and there is another author who made an update that works, and
fulfills the original extension's purpose - and we gave the original author a chance to respond and he either
does not respond for a reasonable time frame or cannot give a
good explanation,
then do we allow the new author to take over maintenance and
maintainership of the addon?
I think we should, yes.
And I think that question is very important for our addons and for
our users, because I think there are a lot of addons that fall into
this specific category. We could help users this way.
And I'd like to thank people who go through the length of updating
third party addons, and not put bureaucratic roadblocks in their
way. The process should be easy for the new author, esp. when the old
author is clearly and obviously absent.
I think there should be an official and maybe even automated process
for that, which checks the above conditions. 1. and 2. above are
known from existing ATN meta data. Point 3 just needs a third party
upload feature that's enabled under conditions 1 and 2, and point 4
just needs an automated email to the original author.
Ben
Graeme wrote on 06.02.19 17:34:
When I was working on my addon in the beginning I used some code
from a small addon that did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work
how to update my own to a MailExtensions addon. The original
popmaillistrecipients addon is now well out of date. (But I really
like using it)
Is there any way that I can put the web extension version on
thunderbird.net http://thunderbird.net other than offering it to
the original author? I sent him the bootstrapped version which to my
knowledge he didn't use...
Blessings
Graeme
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
How about this:
If an author cannot be reached even after we tried over a long time, an AddOn can be set as abandon and it is maybe even hidden from ATN results. A new Author can create an AddOn with the same name which automatically marks it as a replacement. (Or the reviewer does that)
If users have installed an abandoned AdOn for which a new version is avail, Thunderbird will inform the user and allows to switch.
John
Am 07.02.2019 um 08:52 schrieb Magnus Melin mkmelin+mozilla@iki.fi:
Agreed first option is always to first get involved with the original author and work something out.
I'm not too keen on allowing unauthorized takeovers. I doubt you can even do that legally in most cases: licenses aside, authors do have moral rights that usually are perpetual. I'd expect the name in combination with the work to fall under that even if not trademarked.
What would be nice though, is if we could annotate add-ons to describe what they are forked from. If add-on X is abandoned, someone would fork it to create add-on Y, and Thunderbird could offer the user to start using the forked add-on Y instead. But this would only be offered in case the original was abandoned.
-Magnus
On 06-02-2019 23:34, Onno Ekker wrote:
In the past I have adopted an add-on by contacting the original author and having him add me on amo as owner.
I think that’s the way it should go, but if the original author doesn’t reply when contacted, there should be other ways to take over an extension.
That would be a lot better then another “add-on” Improved, “add-on” Next or whatever people call it and add to amo/atn and where users have to search for, because their original add-on stopped working or was disabled.
Onno
On 6 Feb 2019, at 19:59, Ben Bucksch ben.bucksch@beonex.com wrote:
I think this is a valid and important fundamental question:
If an addon is clearly unmaintained, meaning it does not work with current supported versions of Thunderbird (TB 60 at the moment)
and the addon is open-source
and there is another author who made an update that works, and fulfills the original extension's purpose
and we gave the original author a chance to respond and he either does not respond for a reasonable time frame or cannot give a good explanation,
then do we allow the new author to take over maintenance and maintainership of the addon?
I think we should, yes.
And I think that question is very important for our addons and for our users, because I think there are a lot of addons that fall into this specific category. We could help users this way.
And I'd like to thank people who go through the length of updating third party addons, and not put bureaucratic roadblocks in their way. The process should be easy for the new author, esp. when the old author is clearly and obviously absent.
I think there should be an official and maybe even automated process for that, which checks the above conditions. 1. and 2. above are known from existing ATN meta data. Point 3 just needs a third party upload feature that's enabled under conditions 1 and 2, and point 4 just needs an automated email to the original author.
Ben
Graeme wrote on 06.02.19 17:34:
When I was working on my addon in the beginning I used some code from a small addon that did a little piece of what I wanted.
Now I've updated that addon, popmaillistrecipients, in order to work how to update my own to a MailExtensions addon. The original popmaillistrecipients addon is now well out of date. (But I really like using it)
Is there any way that I can put the web extension version on thunderbird.net other than offering it to the original author? I sent him the bootstrapped version which to my knowledge he didn't use...
Blessings
Graeme
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 07-Feb-19 6:22 PM, Magnus Melin wrote:
Agreed first option is always to first get involved with the original
author and work something out.
I'm not too keen on allowing unauthorized takeovers. I doubt you can
even do that legally in most cases: licenses aside, authors do have
moral rights that usually are perpetual. I'd expect the name in
combination with the work to fall under that even if not trademarked.
What would be nice though, is if we could annotate add-ons to describe
what they are forked from. If add-on X is abandoned, someone would
fork it to create add-on Y, and Thunderbird could offer the user to
start using the forked add-on Y instead. But this would only be
offered in case the original was abandoned.
In this process It would be excellent if we can get away from the
current situation such as that of Theme and font size changer. We have
two, and quite honestly I do not know which to recommend to users. The
one that regularly stops working because it has a bomb in it, or the
fixed version.
https://addons.thunderbird.net/en-us/thunderbird/addon/theme-font-size-changer-fixed/
https://addons.thunderbird.net/en-us/thunderbird/addon/theme-font-size-changer-for-tb
The folks in the KB have obviously opted for the fixed version.
https://support.mozilla.org/en-US/kb/thunderbird-accessibility-features
but I really don't think we should be suggesting either version in
particular.
Matt