📝 notes/guidance for security policy [due Oct 11]

[ebullient]

Goes hand-in-hand with commonhaus/.github#3

voting group: @commonhaus/cf-egc

Do one of the following:

• React with 👍 (:+1:) or Approve a review if it looks good to you
• React with 👀 (:eyes:) if you're "ok" with it (it may not be your favorite)
• If you think it needs discussion or revision:
  • Create a review, add your comments and require changes
  • Use the +- button to make a suggestion (instead of just adding a comment).

[haus-rules-bot]

This vote has been closed by ebullient:

Quorum reached. Updates to templates pushed.

---

✅ 12 of 17 members of @commonhaus/cf-egc have voted (reaction or review, quorum=2/3).

Reaction	Total	Team	Voting members
approve	14	10	Naros, aalmiray, cowtowncoder, criccomini, dandreadis, ebullient, henri-tremblay, k-wall, kenfinnigan, tristantarrant
ok	3	2	bstansberry, gavinking

Additional input (🙏 🥰 🙌):
AlvarVG(👍), jjpbolano(👍), karesti(👍), yrodiere(👍), Sanne(👀)

[ebullient]

Just a reminder to all: this issue is due in 10 days.

[Sanne]

Reports will generally become public once a fix is available and confirmed. In exceptional cases — such as when downstream users require time to update or when disclosure could cause immediate harm — a short embargo may be considered.

I appreciate that maintaining embargoes is complex and expensive, but I would still expect them to be used in the several cases. But the above section of the proposal seems to specifically recommend to avoid embargoes - was this discussed with our security experts?
I'm not an expert myself but I'd be uncomfortable with this, and I wonder why there even is such a recommendation guidance - I assume most projects will want to define their own rules in such regards.

Since this is a "guidance", perhaps I'd consider a guidance more useful if it gave practical advise on when we'd consider an embargo unneccessary. My personal suggestion would be to avoid the topic altogether, unless we have something useful to contribute on the matter.

[ebullient]

Not all projects have paid maintainers.

Inspiration somewhat from here: https://lwn.net/Articles/1025971/

What works for the projects that have full-time developers focused on it does not work for projects with folks working in their spare time.

And... note that this is a template only. It is something you could use for your project, but you don't have to.

[Sanne]

Ok, so it's meant as a reasonable "default" to be manageable for smaller projects. That makes sense, but it looks like a recommendation.

[ebullient]

For a small project, this approach helps set sustainable expectations from the start. It should be an obvious option early on. I'm not sure how many people think about expectations this way. Moving from this to something with stronger guarantees is straightforward, but going in reverse is less intuitive (at least to me).

For a large project (like yours), y'all already know what you want to be doing. You don't need this guidance--go forth and do your thing. ;)

[ebullient]

Ok, so it's meant as a reasonable "default" to be manageable for smaller projects. That makes sense, but it looks like a recommendation.

I updated the text to make it's nature (as an example) and inspiration (LWN article re: sustainable/realistic expectations for unpaid maintainers) obvious.

[ebullient]

vote::result Quorum reached. Updates to templates pushed.