Address blockers to people adding security policies

[robrwo]

There are several blockers to adding security policies:

• Desire for a simpler, tiny policy
• Dual-life modules
• Projects with multiple maintainers who cannot agree

Questions: how do decentralised projects like Postgres handle this?

[sjn]

Could we make it a little clearer what this issue it about?

Also, we talked about it at the meeting, and veered into topics around guidance, SBOMs and metadata, and more.... Probably good to take a look at what context/project this task belongs under (so we discuss it with related topics when the time comes for that)

[sjn]

• Projects with multiple maintainers who cannot agree

What's the context and use case here? A lack of suitable conflict resolution mechanisms in the project?

[robrwo]

• Projects with multiple maintainers who cannot agree

What's the context and use case here? A lack of suitable conflict resolution mechanisms in the project?

In the specific case I am thinking of, the project has no governance: there are a group of people who maintain packages based on who gets around to merging changes and releasing them.

[robrwo]

Could we make it a little clearer what this issue it about?

Some of the feedback from the policy template is that the suggested policy is too long. The guide can probably be improved by giving multiple examples with the optional bits left out, and the tools that generate policies given options to leave these out.

Another issue is with dual life modules: ideally, these would have separate ones and that the core Perl security team would refer issues with these modules back to the authors. But it also seems like authors are pushing dirt around under the carpet: the feedback I have gotten is that they don't see a need, since these are dual life.

For projects with governance issues, I'm not really sure. (I do think governance issues are also security issues, and perhaps we need a way of tracking these.)