Skip to content

Add SECURITY.md #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bluwy wants to merge 1 commit into
base: main
Choose a base branch
from
+13 −0
Open

Add SECURITY.md #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# Security Policy

## Supported Versions
Copy link
Copy Markdown

@beeequeue beeequeue May 28, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should also add a section regarding node version support, which i propose to copy from Nuxt;

the latest Changesets versions support the latest node LTS version, no matter what the package manifests say

Copy link
Copy Markdown
Member Author

@bluwy bluwy May 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, could our manifest say differently now? It would be easier to track when engines is the single source of truth

Copy link
Copy Markdown

@beeequeue beeequeue May 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no LTS alias we could use, but it will become a lot easier with the new LTS schedule of 1 node version per year which is LTS for one year

but if we use a statement like "only the LTS version is supported" the engines just restrict installations, and if we forget to drop/add a version it doesn't matter to our official stance

Copy link
Copy Markdown
Member Author

@bluwy bluwy May 28, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your point that we ONLY support LTS versions? (dynamic/rolling version support) I personally prefer to not do that and stick with static ranges. I don't think it's a lot of churn for us to maintain for previous node versions, and we can always bump majors when it affects us.

Copy link
Copy Markdown

@beeequeue beeequeue May 28, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the current version could only support LTS versions. any backwards support would be set in stone when it's no longer the currently maintained version

but yes, if we support old versions for a year then it might not make as much sense


The latest major version of the project is supported with security updates. Previous major versions will also receive security updates for 12 months after the release of their respective next major versions.
Copy link
Copy Markdown
Member

@Andarist Andarist May 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this kinda implies we'd have to do security updates to all non-latest (within the specified timeframe) majors of all subpackages. This is close to impossible. In the case of Changesets CLI we can only reasonably commit to supporting the CLI itself this way (other subpackages would only get security updates for the versions that the CLI depends on)

Copy link
Copy Markdown
Member Author

@bluwy bluwy May 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to reword this differently, it felt weird with the wording before that when we release v3 than v2 would instantly not have security updates.

I think our subpackages are relatively simple or not-many-majors or security-sensitive to be a problem, we can also reduce the timeframe too.

But I'm ok with anything that makes it so that we still support v2 for a while. Would you suggest some words we can add here?


## Reporting a Vulnerability

To report a vulnerability, please open a private vulnerability report at the respective repository's security page, e.g. https://github.com/changesets/changesets/security. Please do not report upstream vulnerabilities unless the code is bundled in the package.

A maintainer will respond to your report as soon as possible. Please do not open a public issue for security vulnerabilities.

Thanks for helping us keep our project secure!