Add Security Policy

[niccokunzmann]

This adds a security policy as reguired by tidelift

See https://icalendar--755.org.readthedocs.build/en/755/security.html

• Contributes to Tidelift - Software Supply Chain Security & Sustainability #754

After the merge, I will activate the policy on GitHub here: https://github.com/collective/icalendar/security

---

📚 Documentation preview 📚: https://icalendar--755.org.readthedocs.build/

[coveralls]

Pull Request Test Coverage Report for Build 12449439023

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 96.355%

---

Totals
Change from base Build 12336865356:	0.0%
Covered Lines:	4580
Relevant Lines:	4747

---

💛 - Coveralls

[stevepiercy]

See comment.

[stevepiercy]

For a security policy, see examples at:

• https://github.com/Pylons/.github/blob/main/SECURITY.md # I've seen this in action, and the maintainers have a very professional response.
• https://github.com/plone/.github/blob/main/SECURITY.md # @mauritsvanrees can speak Plone ones.
• https://github.com/plone/Products.CMFPlone/blob/master/.github/SECURITY.md

It's really up to you what you want to include. If you have another revision after reviewing the above items, please @ me and I'll take another look. I'd suggest incorporating some bits and pieces from the above, especially how to work with CVEs.

[niccokunzmann]

Thank you for the links! I changed it to link to the Plone security page.

I will also write to the security team to ask if they have any feedback on this change.

[stevepiercy]

Do not refer to links that refer to links, especially if you cannot honor the policies to which they refer. You should instead grab the relevant bits that you want to follow and incorporate them into your custom security policy.

As this states, eventually people may report the security issue to [email protected]. Are you a member of that email group? If not, you would need to discuss with them how to handle reports for icalendar sent to that address. It may be better to use another address.

[niccokunzmann]

We can activate GitHub's security reporting for this project.

I wonder: If a vulnerability gets reported on GitHub, then the other Plone packages do not know it exists.
If a vulnerability is reported to Plone, then I do not know it was reported.

Thus, I wonder what to do. We have two different groups here that are affected. I asked the security team to enlighten us here.

Also, nobody reported anything like this for years and it is unlikely to happen. So. I wonder if this is hypothetical. But a report should also not go into the void after a few years.

[stevepiercy]

We can activate GitHub's security reporting for this project.

To enable GitHub security, you create a SECURITY.md file at the root of your repo. GitHub should automatically detect it. It's nothing magical. It's mere documentation of how to report security issues, and how you will respond to them.

I wonder: If a vulnerability gets reported on GitHub, then the other Plone packages do not know it exists. If a vulnerability is reported to Plone, then I do not know it was reported.

Thus, I wonder what to do. We have two different groups here that are affected. I asked the security team to enlighten us here.

I would follow Pylons Project's workflow, modified to your preference.

https://github.com/Pylons/.github/blob/main/SECURITY.md

To summarize:

1. Users report security issues responsibly and in a manner that allows maintainers to respond in a timely and effective manner.
2. Maintainers verify and fix.
3. All the bullet points at that link.

I have no insight into the Plone Security Team's internal process. I'm not a member, and it's not transparent. I never received a report back of what they did for an issue that I recently reported to them.

Also, nobody reported anything like this for years and it is unlikely to happen. So. I wonder if this is hypothetical. But a report should also not go into the void after a few years.

It's only hypothetical until it's not, and then it's too late.

[stevepiercy]

You should not ask people to open a security issue in a public arena, such as an issue tracker. This also conflicts with the link above, which links to https://plone.org/security/report.

If you want to create an email distribution group, and add members to it to review security, I'd suggest following Pylon Project's example as in https://groups.google.com/g/pylons-project-security/ or other free email group distribution list service that is less Google-y.

[stevepiercy]

For accessibility, I'm not a fan of emoji. Better to use "yes" and "no" for screen reader happiness.