Openness of mailing lists

[baentsch]

This is to request a long-term decision as to the openness of PQCA mailing list archives.

My personal preference would be to document them as permanently and openly accessible and searchable to anyone without registration and make subscribers aware of this policy upon registration.

Reason for this request is a change of policy from "closed" to "open" in the past few days, indicating the policy could be changed (back again).

[ryjones]

Hi, this was not a change in policy, but a UI bug.

[baentsch]

Hi, this was not a change in policy, but a UI bug.

So are you saying there is no config option to (possibly) restrict access to the archives?

[ryjones]

@baentsch there is, but it wasn't set to do so.

[ryjones]

I did more digging. On 07 FEB, on all the mailing lists, the Linux Foundation automation bot or Todd Benzies made some changes. I can't tell what the changes were, just that they were made.

On the main list, I made changes on 06 March, but that changed nothing.

[baentsch]

@baentsch there is, but it wasn't set to do so.

So I thought, @ryjones . This is precisely the reason why I am requesting with this issue a binding policy decision by PQCA as to the setting of this config -- and to inform everyone subscribing of this permanent policy within the registration email.

Without this, PQCA can decide at any time to close out the general public from its discussion(archive)s (or again "UI bugs" may happen or --not exactly trust-enhancing-- things like "the Linux Foundation automation bot or Todd Benzies made some changes").

This actually also is one of the reasons why I am not on Discord: As an independent, non-Linux Foundation member I do not want to hand control over information flow to FOSS projects I maintain to a corporate-controlled entity that can remove access or data at any time:

You should be aware that these permissions are set by server owners or admins, and they may change over time.

You can edit or delete a channel from a Discord server if you have the permissions needed to do so.

we may add or remove features, start offering new services, or stop offering some services entirely (or just in some places or for some users) if they no longer make sense from a business perspective

[hartm]

This is precisely the reason why I am requesting with this issue a binding policy decision by PQCA as to the setting of this config -- and to inform everyone subscribing of this permanent policy within the registration email.

I don't think we need to officially make this a policy. Our default policy is that everything should be as open as possible. This means that almost everything except budget discussions and security vulnerability disclosures are public. If we make a policy, then people might assume that some things aren't open, which is not what we want.

Without this, PQCA can decide at any time to close out the general public from its discussion(archive)s (or again "UI bugs" may happen or --not exactly trust-enhancing-- things like "the Linux Foundation automation bot or Todd Benzies made some changes").

We can't control all bugs, but we can promise that as LF staff we won't close out the general public from discussion archives. In general, you can assume that we will strive to make everything as open as reasonably possible.

This actually also is one of the reasons why I am not on Discord: As an independent, non-Linux Foundation member I do not want to hand control over information flow to FOSS projects I maintain to a corporate-controlled entity that can remove access or data at any time:

In an ideal world, we would have open source software hosting tools that are fully decentralized. You could imagine a decentralized hosting service that functioned like a blockchain and simultaneously hosted software and tools for software on a number of different clouds and platforms, meaning that no company could censor or remove access to software or communications.

Unfortunately, this is not where we are today. While you correctly point out that Discord is centrally controlled, so is Github itself (it's a subsidiary of Microsoft). In theory, Microsoft could take everything on Github down tomorrow. While this is obviously an extremely low probability event, the probability of such a thing happening for Discord is also probably quite small (although maybe not as small as that of Github). So, while I sympathize with your principles, I am willing to compromise for the sake of efficiency.

[baentsch]

If we make a policy, then people might assume that some things aren't open, which is not what we want.

You may not want it, but you do it: By also stating

almost everything except budget discussions and security vulnerability disclosures are public

you confirm the assumption that PQCA restricts the open flow of information.

By not stating publicly, e.g., in the mailing list subscription documentation, what it is that PQCA retains to "members only" eyes it shirks a public discussion about this. This is a pretty controversial approach in a project involving security software ("security by obscurity"? See "Open Design" cf. NIST 800-123).

Assuming the 2 exceptions to the term "almost everything" [should be open] above are the only ones, allow me to comment them:

1. Keeping security vulnerability disclosures under taps for some time is sensible to restrict bad actors from getting information too early. Not publishing it after a to-be-agreed-upon time is a disservice to public safety and does not seem to be a good "general" policy of a security software OSS project: Not publicly stating a CVE-handling policy is very bad indeed. Not keeping archives open to allow for post mortem analysis of (e.g., discussions around) security vulnerabilities seems even worse.

2. Keeping budgeting discussions equally completely hidden also doesn't seem totally sensible: Of course, for example the exact dollar amounts PQCA is paying to fund a particular executive's time on the PQCA governing board is not that interesting but by keeping budget discussions completely secret, you are robbing the (public) FOSS community of understanding what PQCA cares about: Is it spending more on marketing than technology? More on overhead than security evaluations? etc. You are avoiding questions like "PQCA doesn't invest in x, why should I contribute to x?" but invite questions like "What does PQCA have to hide by not stating what its business/monetary priorities are? Why is it not making public discussions which security measures it invests in?"

But we digress: The question was: Is PQCA willing to commit to a policy regarding mailing list openness?

The answer of PQCA seems to be "No".

I personally find this a wrong decision and countering the interest of the wider OSS community interested in topics PQCA works on. By not committing to support open communication flows you are also robbing PQCA of external perspectives by people valuing that property and who may be beneficial to progress and/or finding alternative solutions, e.g. benefiting more entities than just PQCA members.

In turn a question to you personally, @hartm: Would you be willing to publicly state your affiliation and function in this as otherwise it is difficult to judge whether your statements above indeed are an informed decision by the PQCA governing board (are you its chair?), one of Linux Foundation (paying your salary, right?) or your personal opinion (always welcome) -- or whether this all coalesces into one (a bit scary)? This surely would help understand the governance model of PQCA -- actually, another sign of openness and arguably befitting a project called "PQCA/governance".

Microsoft could take everything on Github down tomorrow

Yes. An asteroid could crash into Redmond tomorrow, too. Fun aside: Microsoft taking down (all software on) github has far larger reverberations than a corporate-controlled entity like PQCA or Discord deciding to drop a communications channel (or single members) it doesn't like ("no longer make sense from a business perspective" in the words of the Discord subscription t's and c's) and accordingly, much less likely.

[hartm]

Keeping security vulnerability disclosures under taps for some time is sensible to restrict bad actors from getting information too early. Not publishing it after a to-be-agreed-upon time is a disservice to public safety and does not seem to be a good "general" policy of a security software OSS project: Not publicly stating a CVE-handling policy is very bad indeed. Not keeping archives open to allow for post mortem analysis of (e.g., discussions around) security vulnerabilities seems even worse.

We obviously don't believe in security by obscurity, and I am sorry if my reply could be interpreted in any way as supporting this. In fact, defining a PQCA security vulnerability disclosure policy will be one of the first things that the PQCA TAC needs to do. The OpenSSF has done a lot of work on this.

Keeping budgeting discussions equally completely hidden also doesn't seem totally sensible: Of course, for example the exact dollar amounts PQCA is paying to fund a particular executive's time on the PQCA governing board is not that interesting but by keeping budget discussions completely secret, you are robbing the (public) FOSS community of understanding what PQCA cares about: Is it spending more on marketing than technology? More on overhead than security evaluations? etc. You are avoiding questions like "PQCA doesn't invest in x, why should I contribute to x?" but invite questions like "What does PQCA have to hide by not stating what its business/monetary priorities are? Why is it not making public discussions which security measures it invests in?"

Keeping budget discussions partially hidden is standard practice for nonprofits and government agencies. It is not about on what, exactly, money is being spent, but more about negotiating. For instance, if the PQCA wants to contract with a third party for a security audit, it becomes difficult to get the best price if that company can hear all of the internal discussion on the topic.

But we digress: The question was: Is PQCA willing to commit to a policy regarding mailing list openness?
The answer of PQCA seems to be "No".

To my knowledge, no other Linux Foundation project has such a policy. I'm not sure why the PQCA would want or need to be the first project to do so. There are also probably other things that would have to be excluded from being open like code of conduct violation/harassment reporting, so writing a policy would be tricky and would likely require legal approval.

That being said, TAC meetings are completely open (and start next week--see the TAC list). Anyone is always welcome to bring things in front of the TAC, and you could bring this up for discussion, although there are probably things for the first couple of meetings that most folks will consider higher priority than this. Personally, I would share this sentiment: we have more important things to do at this point in the project than hash out a mailing list openness policy, including things like setting a project lifecycle policy, a security vulnerability disclosure policy, electing a TAC chair, and so forth.

In turn a question to you personally, @hartm: Would you be willing to publicly state your affiliation and function in this as otherwise it is difficult to judge whether your statements above indeed are an informed decision by the PQCA governing board (are you its chair?), one of Linux Foundation (paying your salary, right?) or your personal opinion (always welcome) -- or whether this all coalesces into one (a bit scary)? This surely would help understand the governance model of PQCA -- actually, another sign of openness and arguably befitting a project called "PQCA/governance".

Sure! I am not on the governing board, which will soon also have the TAC chair on it as per the PQCA Charter. However, I am a full-time Linux Foundation employee. The LF is pretty excellent about letting us state our personal opinions, so yes, this is my personal opinion. Does that clarify things for you?

[baentsch]

But we digress: The question was: Is PQCA willing to commit to a policy regarding mailing list openness?
The answer of PQCA seems to be "No".

To my knowledge, no other Linux Foundation project has such a policy.

And this is exactly my concern regarding LinuxFoundation projects, incl. PQCA: Not having a general policy committing to openness in all regards.

we have more important things to do at this point in the project than hash out a mailing list openness policy,

Some people may agree to this, but the question of openness in my view is rather central to OSS projects.

I am a full-time Linux Foundation employee. The LF is pretty excellent about letting us state our personal opinions, so yes, this is my personal opinion. Does that clarify things for you?

Yes, it does, Thank You. I will leave this issue open until/if PQCA GB decided on its course concerning openness.