Implement Pre-Disclosure List Policy

[maennchen]

Follow up of https://github.com/orgs/erlef-cna/discussions/3

TODO

• Check if CNA Partners agree with the policy
  • EEF
  • Erlang
  • Gleam
  • Elixir
  • Hex
  • Nerves
  • OpenRiak
• Implement Pre Disclosure Repo & Automation
• Collect List of initial Participants

[maennchen]

⚠️ This would mean that those projects agree that we give one weeks heads up before publication.

[IngelaAndin]

I think that it is important that the "heads up" information will be timely. That is we should not disclose any information until we have a working solution and are ready to release patches. Keeping secrets is not something that people are generally good at and the more people that know the higher the risk.

We need to investigate how long is the heads up, and not make it too long. Also it is a good thing to not plan to release patches before weekends or holidays as we want to avoid creating panics and forcing people to work when they are suppose to be relaxing. This creates bad-will.

It is important to note that we are not planning to make any pre-patches available to embargo-people. We only make the official patches but maybe embargo-people can be notified so that they can prepare.

We discussed what should we let them know and I am not sure it necessary to give them all details. It could perhaps be enough to try to describe what kind of use cases should be worried so that they can prepare their organizations to be ready to take our patches and deploy their own patch-packages as soon as the patches become available.

We also discussed that we thought the participants of and embargo-list should be CNA representatives so that it is people use to handling these kind of secrets and hopefully decrease the risk.

We discussed that plain emails is not a good medium to convey the information. But what would be better needs investigating.

[WarpEngineer]

With respect to the concerns about using email, like I stated on the call, there's nothing inherently wrong with email notifications, but if we do want to keep the information more private, and I suggest we do, then the notifications should only contain minimal information and direct the reader to a secure site. We can use private GH repos and adjust notification settings to minimize information disclosure, or we can host the content ourselves on erlef.org behind a login. Another option could be password protecting the information in an attachment to the email but that might be almost as hard as having to manage PGP keys.

[maennchen]

Thank you both for your feedback.

---

@IngelaAndin One thing I would like to be able to support is cornerstone projects in our own ecosystem. I'm thinking of projects like Cowboy, Phoenix, GriSP, Nerves, OpenRiak etc. If we formally invited those projects to partake in the CNA, would that work with what you had in mind? (basically invite them as a "participating project" as per https://github.com/erlef-cna/.github/blob/main/GOVERNANCE.md#overview and not just the catch-all via Hex.pm)

I would then rephrase the eligibility as distributions, project participating in our CNA and vendors that have a CNA on their own.

---

@WarpEngineer I'm trying out to figure out a simple solution where we can inform users, but only the specific part the points of contact are ready to share.

My first proposal was to create a separate repo that is scope to those specific users. We would then (with CI/CD) sync all advisories that are published and all advisories in a draft state with a manual trigger.

We could additionally open an issue or discussion for each of them and just include the link to the file. This way the notifications will not include any details.

I changed it to a normal mailing list before this WG call because I got the vibe that this is a bit of an exotic solution. I'm happy to revert this back.

For sure, I'd like to avoid building a complicated system with logins etc.

I think we need to be clear on a few requirements:

• May emails contain embargoed data?
  • Yes
  • Only Encrypted
  • No
• Do we want to publish our full advisories or only a subset?
• It should be a small effort to build / maintain.

I personally think that:

• We should publish full advisories (I can't find any subset that I think would be good.)
• I like the email solution with a mailing list since it is very simple.
• I like the GH solution because we don't have to extend our trust to another party that doesn't already have the data. However it is a bit "exotic" and might be a bit more difficult to collaborate with other CNAs.

[WarpEngineer]

@maennchen Your first proposal sounds great to me and would keep things organized. I know we want to keep things simple but the repo approach gives us just enough usability and security to strike a good balance.

• It should be a small effort to build / maintain.

I'm happy and willing to help as needed.

I personally think that:

• We should publish full advisories (I can't find any subset that I think would be good.)
• I like the email solution with a mailing list since it is very simple.
• I like the GH solution because we don't have to extend our trust to another party that doesn't already have the data. However it is a bit "exotic" and might be a bit more difficult to collaborate with other CNAs.

I agree with full advisories.
Yes, email is simple but I don't think that GH is all that exotic these days. It's so popular that almost everyone is already familiar with it.

[Copilot]

Pull Request Overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[IngelaAndin]

Thank you both for your feedback.

@IngelaAndin One thing I would like to be able to support is cornerstone projects in our own ecosystem. I'm thinking of projects like Cowboy, Phoenix, GriSP, Nerves, OpenRiak etc. If we formally invited those projects to partake in the CNA, would that work with what you had in mind? (basically invite them as a "participating project" as per https://github.com/erlef-cna/.github/blob/main/GOVERNANCE.md#overview and not just the catch-all via Hex.pm)

Yes I think that works, that 's what we discussed in the meeting yesterday,

I would then rephrase the eligibility as distributions, project participating in our CNA and vendors that have a CNA on their own.

Sounds like a plan.

@WarpEngineer I'm trying out to figure out a simple solution where we can inform users, but only the specific part the points of contact are ready to share.

My first proposal was to create a separate repo that is scope to those specific users. We would then (with CI/CD) sync all advisories that are published and all advisories in a draft state with a manual trigger.

We could additionally open an issue or discussion for each of them and just include the link to the file. This way the notifications will not include any details.

I changed it to a normal mailing list before this WG call because I got the vibe that this is a bit of an exotic solution. I'm happy to revert this back.

For sure, I'd like to avoid building a complicated system with logins etc.

I think we need to be clear on a few requirements:

• May emails contain embargoed data?

  • Yes
  • Only Encrypted
  • No

I think no, but can settle for encrypted.

• Do we want to publish our full advisories or only a subset?
• It should be a small effort to build / maintain.

I personally think that:

• We should publish full advisories (I can't find any subset that I think would be good.)

Ericsson CNA, agreed this would be ok for us.

• I like the email solution with a mailing list since it is very simple.

I dislike this because it is insecure and too many people are sloppy when handling e-mails.

• I like the GH solution because we don't have to extend our trust to another party that doesn't already have the data. However it is a bit "exotic" and might be a bit more difficult to collaborate with other CNAs.

I like this because it feels more modern and adept what we want to accomplish.

[maennchen]

@IngelaAndin I already adapted to the dicussed state. At this point the files in the PR should reflect all that.

[IngelaAndin]

@IngelaAndin I already adapted to the dicussed state. At this point the files in the PR should reflect all that.

I mainly documented here what we discussed in the meeting. I did not re-review.