[Council Meeting] Minutes from 2021-02-15
18 views
Skip to first unread message
Magnus Melin
Mar 1, 2021, 3:49:10 PM3/1/21
to Thunderbird planning (moderated)
Thunderbird Project Council Meeting
When: Feb 15, 2021 at 8:00 PM – 09:01 CET
Minuter: Magnus
In the call: Magnus, Dirk, Berna, Christopher, Philipp
Regrets: Ryan, Patrick
Hiring/personnel
- Discussed employment matters.
- Magnus noted a new team member (Henry) is joining Feb 22.
Product/Strategy
- Berna brought up RedHat not currently shipping Thunderbird OpenPGP, and how/if we could cooperate with the Sequoia team who is developing a solution for RHEL Thunderbird users. Berna will organize a meeting between Sequoia/Thunderbird developers.
- Scheduled strategy meeting for next Monday [this got repurposed, will need new time]
Miscellaneous
- Discussed potentially changing meeting time. Hard to find another time that most can attend.
- Discussed mailing list moderation policies
- No significant moderation atm.
- Delays are possible: especially during weekends moderators may take time before they approve.
-Magnus
Matt Harris
Mar 4, 2021, 7:30:24 PM3/4/21
to tb-pl...@mozilla.org
On 02-Mar-21 7:19 AM, Magnus Melin wrote:
Thunderbird Project Council Meeting
When: Feb 15, 2021 at 8:00 PM – 09:01 CET
Minuter: Magnus
In the call: Magnus, Dirk, Berna, Christopher, Philipp
Regrets: Ryan, PatrickHiring/personnel
- Discussed employment matters.
- Magnus noted a new team member (Henry) is joining Feb 22.
And this brings the contacted/paid staff to what level? Does the
council feel this will be a long term staffing level?
Product/Strategy
- Berna brought up RedHat not currently shipping Thunderbird OpenPGP, and how/if we could cooperate with the Sequoia team who is developing a solution for RHEL Thunderbird users. Berna will organize a meeting between Sequoia/Thunderbird developers.
So let me get this. The Redhat security group chose to break
Thunderbird by not shipping required component because it did not
suit their chosen security model as it included the encryption
library. Thunderbird does it's own security and that does not suit.
https://bugzilla.redhat.com/show_bug.cgi?id=1837512
Now we are going to help fix Thunderbird so it runs on their product from their repository, despite there being perfectly good functional copies that can be installed from thunderbird.net. or as a flatpack. I would have though that IBM would have been more than capable of contributing to whatever was needed to rectify their decision, but I guess a desktop mail clients is not important to a server operating system manufacturer. It is also apparent that e2ee is important to the council. General run of the mill users might disagree. Do we have any information on take up of e2ee? Some information from the metrics we are getting back on usage from telemetry?
How is the telemetry data going? Have we learned anything about our user base from it? Like how many users there are even, or how many use RSS or NNTP? What is the average age of the user profile/how long have they been using Thunderbird? How many profiles they have on disk in the profiles folder Vs the number in the prefs JS? Might give a clue on the true level of lost profiles. We (the community at least) are still largely in the dark about how the project and the users it is supposed to be serving. I have my own perceptions on what is important garnered largely through my involvement. But the project is still not releasing number that might prove or disprove perceptions.
RedHsat (IBM) might be a big player in the Linux world but they represent a very small part of the Thunderbird users indeed. Seriously I think we have more pressing issues than fixing the product for a truly small percentage of users that chose to use a niche operating system that could fix the issue quickly by installing another distribution. Or they could installing the version from Thunderbird.net and get official instead of rebuilt copies of the product. or even use the flatpack we have started. Sorry, but I see time and money being wasted on a political decision by RedHat to further their enterprise market. Their choice to not offer a fully functional Thunderbird. Their focus is on, enterprise and web servers, Thunderbird's core market is consumers and small business. I have seen nothing to indicate that has changed in decades. There is not even much of a market overlap between the two. Except in the enthusiast market and they are rarely restrained by things like corporate images, so they have plenty of choices.
Once Thunderbird users get a button to press that says "Transfer my Thunderbird to a new device", and another that says "Import a backup for use on this device". I am opposed to squandering money and time on niche enterprises like the political decision made by redhat. (this is political because they don't like the placement of a library and there are some very simple alternatives. They just do not use their repository). We are loosing users because they just can't get their data from their old device to their new. They can't handle the double wammy of a manual backup of files and folders and the profile per install making the restore of that manual backup non trivial. This is where we need to be spending resources. It needed love 10 years ago and it has so far received none.
Lets get some of these basic user facing items fixed that affect 100% of users over time before we continue on with the ones that affect less than 1%. Far to much time has already been invested in e2ee for a user base that mostly does not use it and does not understand it. This is where we need to be focusing on the usability problems of the majority. Not on what is happening in some enterprise focused Linux distribution that has a market share of less that 2% of users.
We have users who loose their user profile because of some corruption affecting the prefs.js file. But the profile has no intrinsic way to restore setting sto what were loaded successfully yesterday. If the last save failed for some reason a backup should not only be available but automatically loaded so the user get to do mail, not learn how to use their operating system file manager for the first time ever.
Now we are going to help fix Thunderbird so it runs on their product from their repository, despite there being perfectly good functional copies that can be installed from thunderbird.net. or as a flatpack. I would have though that IBM would have been more than capable of contributing to whatever was needed to rectify their decision, but I guess a desktop mail clients is not important to a server operating system manufacturer. It is also apparent that e2ee is important to the council. General run of the mill users might disagree. Do we have any information on take up of e2ee? Some information from the metrics we are getting back on usage from telemetry?
How is the telemetry data going? Have we learned anything about our user base from it? Like how many users there are even, or how many use RSS or NNTP? What is the average age of the user profile/how long have they been using Thunderbird? How many profiles they have on disk in the profiles folder Vs the number in the prefs JS? Might give a clue on the true level of lost profiles. We (the community at least) are still largely in the dark about how the project and the users it is supposed to be serving. I have my own perceptions on what is important garnered largely through my involvement. But the project is still not releasing number that might prove or disprove perceptions.
RedHsat (IBM) might be a big player in the Linux world but they represent a very small part of the Thunderbird users indeed. Seriously I think we have more pressing issues than fixing the product for a truly small percentage of users that chose to use a niche operating system that could fix the issue quickly by installing another distribution. Or they could installing the version from Thunderbird.net and get official instead of rebuilt copies of the product. or even use the flatpack we have started. Sorry, but I see time and money being wasted on a political decision by RedHat to further their enterprise market. Their choice to not offer a fully functional Thunderbird. Their focus is on, enterprise and web servers, Thunderbird's core market is consumers and small business. I have seen nothing to indicate that has changed in decades. There is not even much of a market overlap between the two. Except in the enthusiast market and they are rarely restrained by things like corporate images, so they have plenty of choices.
Once Thunderbird users get a button to press that says "Transfer my Thunderbird to a new device", and another that says "Import a backup for use on this device". I am opposed to squandering money and time on niche enterprises like the political decision made by redhat. (this is political because they don't like the placement of a library and there are some very simple alternatives. They just do not use their repository). We are loosing users because they just can't get their data from their old device to their new. They can't handle the double wammy of a manual backup of files and folders and the profile per install making the restore of that manual backup non trivial. This is where we need to be spending resources. It needed love 10 years ago and it has so far received none.
Lets get some of these basic user facing items fixed that affect 100% of users over time before we continue on with the ones that affect less than 1%. Far to much time has already been invested in e2ee for a user base that mostly does not use it and does not understand it. This is where we need to be focusing on the usability problems of the majority. Not on what is happening in some enterprise focused Linux distribution that has a market share of less that 2% of users.
We have users who loose their user profile because of some corruption affecting the prefs.js file. But the profile has no intrinsic way to restore setting sto what were loaded successfully yesterday. If the last save failed for some reason a backup should not only be available but automatically loaded so the user get to do mail, not learn how to use their operating system file manager for the first time ever.
Neal H. Walfield
Mar 5, 2021, 8:53:05 AM3/5/21
to unicorn.c...@gmail.com, Thunderbird planning (moderated)
Hi Matt,
On Fri, 05 Mar 2021 01:30:12 +0100,
Matt Harris wrote:
> On 02-Mar-21 7:19 AM, Magnus Melin wrote:
> * Berna brought up RedHat not currently shipping Thunderbird OpenPGP, and how/if we could cooperate with the Sequoia team who is developing a solution for RHEL
library is a big commitment. You point out in your message that most
RHEL users' care about web servers, not mail clients. So, it seems
perfectly reasonable to me for them to choose to ship a version of TB
without OpenPGP support. In fact, what they are doing is actually
supported by TB: the build scripts have an option to disable OpenPGP
supprt ("--disable-openpgp"); OpenPGP is not a required component.
> Now we are going to help fix Thunderbird so it runs on their product
> from their repository,
I'd like to provide a bit of the back story here. I work on Sequoia
PGP, a GPL2+ OpenPGP implementation written in Rust. You can learn
more about it here:
https://sequoia-pgp.org/
TL;DR: We're doing nearly all of the work on this; we contacted Magnus
and Kai to coordinate our efforts.
The longer version: A Fedora user recently made us aware of the fact
that Redhat includes a version of TB without OpenPGP support, and
pointed us to the same bug report that you mention above:
https://bugzilla.redhat.com/show_bug.cgi?id=1837512
In that bug report, a Redhat employee indicated that they'd be willing
to accept a patch to use a different OpenPGP backend.
We contacted someone from Redhat, and asked if they'd be interested in
a Sequoia backend. They said that since Sequoia uses Nettle, which is
one of the four crypto libraries that RHEL supports, they would in
principle be open to it. I made clear that Sequoia is under the GPL
2+, and was told that that is not a problem for them, since the MPL 2
and GPL are compatible.
(Using GPL 2 code *is* a problem for TB even thought the MPL 2 and
GPL2 are compatible:
https://www.fsf.org/blogs/licensing/mpl-2.0-release
As I understand it from Magnus, although TB ships code under other
licenses, they only ship code that is at least as liberally licensed
as the MPL 2; adding GPL 2 would impose additional restrictions on
user's and forks of TB.)
Our technical approach was to simply reimplement the RNP ABI that TB
uses. We also reuse the same file format as RNP so no migration is
required and you can switch between the two backends at any time.
You can see the code here:
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp
The current version passes all of TB's OpenPGP-related tests, and
several people on the Sequoia team have been using it as their daily
MUA.
Recently, we contacted Magnus and Kai to inform them about our
project, and to ask for a minimal amount of help. Yesterday we had a
conversation (the aforementioned meeting) with them and discussed the
following five issues:
- Confusion regarding the backend.
To make it easier to debug issues, we decided to modify TB to
print more information about the OpenPGP library at start up.
This is also useful when a distribution uses an unbundled version
of RNP, as Debian plans to do.
We'll provide a patch.
- Backwards compatibility.
To make sure a TB update doesn't cause the OpenPGP backend to stop
working, we proposed that if an RNP function is missing, TB should
fallback to a stub, which simply fails. This could also help when
a distribution uses an unbundled version of RNP.
Magnus and Kai were open to this. We'll provide a patch.
- CI.
We already started work on a pipeline to test TB using Sequoia on
our CI (it's not fully debugged):
https://gitlab.com/sequoia-pgp/build-thunderbird
Our concern is that we will test a different configuration and
fail to identify some issues.
We asked about adding a "may fail" job to TB's CI that also runs
the OpenPGP tests against the latest version of the Sequoia
Octopus. This would make sure that we find out about breaking
changes when then land.
We observed that testing against a second OpenPGP backend would
also help with interoperability.
Magnus and Kai were against this, as they don't want failing tests
for code that they don't want to support to prevent their CI from
being green. But, Kai said that he'll review our pipeline.
- Use a standard OpenPGP API and ABI.
Daniel Kahn Gillmor (dkg) developed an IETF internet draft that
specifies an OpenPGP-implementation agnostic command line
interface:
https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli-02
We're using this is our OpenPGP interoperability test suite:
https://tests.sequoia-pgp.org/
The API has been well received by the community. Of the 9 OpenPGP
implementations that we test, half of the SOP implementations were
not written by us. Currently, dkg is working on a C API:
https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/32
We think that this would also help RNP. Justus, who did nearly
all of the implementation work on the octopus, kept notes, and
identified a number of issues in RNP's API (unclear documentation,
poor defaults, misunderstands of the standard):
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/blob/main/notes.org
If RNP used a standard C API, many of these issues would
disappear.
It would also be useful for TB as TB could more easily replace
their OpenPGP implementation, should the need ever arise.
Magnus and Kai indicated that they are happy with RNP's API, and
don't think the RNP developers would want to implement the SOP C
API as they'd lose their competitive advantage. As such, they
don't want to invest any time in this.
- Bring back OpenPGP's native authentication mechanisms.
OpenPGP supports a non-hierarchical authentication framework,
which is a superset of X.509, which is used by TLS and S/MIME.
This framework is sometimes referred to as the "web of trust,"
which makes people think about key signing parties, but it is
quite a bit more than that. For instance, OpenPGP CA uses it to
simplify authenticating OpenPGP certificates in organizations.
https://openpgp-ca.org/
There are many organizations who lament TB 78's lack of OpenPGP's
authentication mechanisms. For example:
https://thunderbird.topicbox.com/groups/e2ee/Tcb4b3decdb7e66ce-M65309638f210286b7469ce61
We're in close contact with a few of them.
Yesterday, we discussed whether there is interest in restoring
OpenPGP authentication, and how that might look. We decided that
I would open an issue on TB's bugzilla with a concrete proposal.
Once everyone is satisfied, we (Sequoia, not TB) would implement
it.
I hope you agree that the burden on TB is minimal, and that we are
doing nearly all of the work. Concretely, we are trying to coordinate
our efforts to avoid making work for TB.
If you have any questions, I'll be happy to answer them on or off
list.
:) Neal
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
On Fri, 05 Mar 2021 01:30:12 +0100,
Matt Harris wrote:
> On 02-Mar-21 7:19 AM, Magnus Melin wrote:
> Thunderbird users. Berna will organize a meeting between Sequoia/Thunderbird developers.
>
> So let me get this. The Redhat security group chose to break
> Thunderbird by not shipping required component because it did not
> suit their chosen security model as it included the encryption
> library. Thunderbird does it's own security and that does not
> suit. https://bugzilla.redhat.com/show_bug.cgi?id=1837512
I have sympathy for Redhat. Providing security support for a crypto
>
> So let me get this. The Redhat security group chose to break
> Thunderbird by not shipping required component because it did not
> suit their chosen security model as it included the encryption
> library. Thunderbird does it's own security and that does not
> suit. https://bugzilla.redhat.com/show_bug.cgi?id=1837512
library is a big commitment. You point out in your message that most
RHEL users' care about web servers, not mail clients. So, it seems
perfectly reasonable to me for them to choose to ship a version of TB
without OpenPGP support. In fact, what they are doing is actually
supported by TB: the build scripts have an option to disable OpenPGP
supprt ("--disable-openpgp"); OpenPGP is not a required component.
> Now we are going to help fix Thunderbird so it runs on their product
> from their repository,
PGP, a GPL2+ OpenPGP implementation written in Rust. You can learn
more about it here:
https://sequoia-pgp.org/
TL;DR: We're doing nearly all of the work on this; we contacted Magnus
and Kai to coordinate our efforts.
The longer version: A Fedora user recently made us aware of the fact
that Redhat includes a version of TB without OpenPGP support, and
pointed us to the same bug report that you mention above:
https://bugzilla.redhat.com/show_bug.cgi?id=1837512
In that bug report, a Redhat employee indicated that they'd be willing
to accept a patch to use a different OpenPGP backend.
We contacted someone from Redhat, and asked if they'd be interested in
a Sequoia backend. They said that since Sequoia uses Nettle, which is
one of the four crypto libraries that RHEL supports, they would in
principle be open to it. I made clear that Sequoia is under the GPL
2+, and was told that that is not a problem for them, since the MPL 2
and GPL are compatible.
(Using GPL 2 code *is* a problem for TB even thought the MPL 2 and
GPL2 are compatible:
https://www.fsf.org/blogs/licensing/mpl-2.0-release
As I understand it from Magnus, although TB ships code under other
licenses, they only ship code that is at least as liberally licensed
as the MPL 2; adding GPL 2 would impose additional restrictions on
user's and forks of TB.)
Our technical approach was to simply reimplement the RNP ABI that TB
uses. We also reuse the same file format as RNP so no migration is
required and you can switch between the two backends at any time.
You can see the code here:
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp
The current version passes all of TB's OpenPGP-related tests, and
several people on the Sequoia team have been using it as their daily
MUA.
Recently, we contacted Magnus and Kai to inform them about our
project, and to ask for a minimal amount of help. Yesterday we had a
conversation (the aforementioned meeting) with them and discussed the
following five issues:
- Confusion regarding the backend.
To make it easier to debug issues, we decided to modify TB to
print more information about the OpenPGP library at start up.
This is also useful when a distribution uses an unbundled version
of RNP, as Debian plans to do.
We'll provide a patch.
- Backwards compatibility.
To make sure a TB update doesn't cause the OpenPGP backend to stop
working, we proposed that if an RNP function is missing, TB should
fallback to a stub, which simply fails. This could also help when
a distribution uses an unbundled version of RNP.
Magnus and Kai were open to this. We'll provide a patch.
- CI.
We already started work on a pipeline to test TB using Sequoia on
our CI (it's not fully debugged):
https://gitlab.com/sequoia-pgp/build-thunderbird
Our concern is that we will test a different configuration and
fail to identify some issues.
We asked about adding a "may fail" job to TB's CI that also runs
the OpenPGP tests against the latest version of the Sequoia
Octopus. This would make sure that we find out about breaking
changes when then land.
We observed that testing against a second OpenPGP backend would
also help with interoperability.
Magnus and Kai were against this, as they don't want failing tests
for code that they don't want to support to prevent their CI from
being green. But, Kai said that he'll review our pipeline.
- Use a standard OpenPGP API and ABI.
Daniel Kahn Gillmor (dkg) developed an IETF internet draft that
specifies an OpenPGP-implementation agnostic command line
interface:
https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli-02
We're using this is our OpenPGP interoperability test suite:
https://tests.sequoia-pgp.org/
The API has been well received by the community. Of the 9 OpenPGP
implementations that we test, half of the SOP implementations were
not written by us. Currently, dkg is working on a C API:
https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/32
We think that this would also help RNP. Justus, who did nearly
all of the implementation work on the octopus, kept notes, and
identified a number of issues in RNP's API (unclear documentation,
poor defaults, misunderstands of the standard):
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/blob/main/notes.org
If RNP used a standard C API, many of these issues would
disappear.
It would also be useful for TB as TB could more easily replace
their OpenPGP implementation, should the need ever arise.
Magnus and Kai indicated that they are happy with RNP's API, and
don't think the RNP developers would want to implement the SOP C
API as they'd lose their competitive advantage. As such, they
don't want to invest any time in this.
- Bring back OpenPGP's native authentication mechanisms.
OpenPGP supports a non-hierarchical authentication framework,
which is a superset of X.509, which is used by TLS and S/MIME.
This framework is sometimes referred to as the "web of trust,"
which makes people think about key signing parties, but it is
quite a bit more than that. For instance, OpenPGP CA uses it to
simplify authenticating OpenPGP certificates in organizations.
https://openpgp-ca.org/
There are many organizations who lament TB 78's lack of OpenPGP's
authentication mechanisms. For example:
https://thunderbird.topicbox.com/groups/e2ee/Tcb4b3decdb7e66ce-M65309638f210286b7469ce61
We're in close contact with a few of them.
Yesterday, we discussed whether there is interest in restoring
OpenPGP authentication, and how that might look. We decided that
I would open an issue on TB's bugzilla with a concrete proposal.
Once everyone is satisfied, we (Sequoia, not TB) would implement
it.
I hope you agree that the burden on TB is minimal, and that we are
doing nearly all of the work. Concretely, we are trying to coordinate
our efforts to avoid making work for TB.
If you have any questions, I'll be happy to answer them on or off
list.
:) Neal
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Reply all
Reply to author
Forward
0 new messages