[pitrou]

Rationale for this change

We often get private security reports for some issues which don't threaten confidentiality or integrity.

For these kinds of issues, we would rather have them reported through the usual public means, as it follows our open development principles more closely, and lessens the required paperwork (no CVE, etc.).

What changes are included in this PR?

Add a paragraph in the C++ security model about what should be reported as a security vulnerability vs. a regular bug.

Are these changes tested?

N/A.

Are there any user-facing changes?

No.

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

• GitHub Issue: [C++][Doc] Document bugs vs security vulnerabilities #49760

[pitrou]

@alamb @tustvold @paleolimbot Could you look at these non-C++ specific changes?

[pitrou]

@zanmato1984 @HuaHuaY @taepper @westonpace @emkornfield Would you like to take a look?

[pitrou]

@github-actions crossbow submit preview-docs

[github-actions]

Revision: 32291c5

Submitted crossbow builds: ursacomputing/crossbow @ actions-a1be7c45db

Task	Status
preview-docs

[paleolimbot]

Thanks!

This seems like a reasonable change...the C++ bits apply to nanoarrow too but we haven't had many security reports until the last few weeks.

Most reports claim that crashes have a privacy component (e.g., use after free), but hopefully this helps. Having these as open issues makes it much simpler to get them fixed (e.g., doesn't have to be somebody specifically watching the private list).