-
Notifications
You must be signed in to change notification settings - Fork 915
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.
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
[Doc] Modify SECURITY.md nested dependency fix and add backport process #3497
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
@@ -1,27 +1,67 @@ | ||||||||
## Reporting a Vulnerability | ||||||||
|
||||||||
- If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue. | ||||||||
|
||||||||
- For Security-CVE related fix - | ||||||||
- For direct dependency - Use ```yarn upgrade package``` to update the package and in order to enforce as sub-deps please add nested-dep step2. | ||||||||
|
||||||||
- For nested dependency/sub-deps - In order to enforce package above Vx.y.z, we can add version in the resolutions [section](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/) for all the package sub-deps or specific package sub-dep. For more on version updates please see | ||||||||
[Why](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-why-would-you-want-to-do-this) and [How](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-how-to-use-it) to upgrade. | ||||||||
- To add the CVEs fix to previous versions, add label ex: backport 1.x. | ||||||||
|
||||||||
``` | ||||||||
Example: [email protected] vulnerable package and 1.y is the fix | ||||||||
step 1: | ||||||||
For direct dependency checks: | ||||||||
run: yarn upgrade [email protected] to update the package.json | ||||||||
and yarn install to update the yarn.lock file | ||||||||
Step 2. | ||||||||
Check for sub deps foobar in other package. | ||||||||
If [email protected] exists for subdeps in yarn.lock file | ||||||||
Then edit the package.json file and add **/[email protected] in resolution section as shown below to enforce the 1.y. | ||||||||
'resolutions': { "**/foobar": "^1.y", | ||||||||
"**/foo": "^2.x" , | ||||||||
"**/bar": "^3.k"} | ||||||||
Then run: yarn install for updating yarn.lock file | ||||||||
|
||||||||
|
||||||||
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue. | ||||||||
|
||||||||
## Fixing a Vulnerability | ||||||||
joshuarrrr marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's add a header to separate Reporting from Fixing
Suggested change
|
||||||||
- For direct dependencies (listed explicitly in `package.json`) - After identifying a version of the package that is both compatible with OpenSearch Dashboards and includes a fix for the vulnerability, update the dependency in `package.json` and run `yarn osd bootstrap` to build the project and update the `yarn.lock` file. | ||||||||
|
||||||||
- For nested dependencies (sub-dependencies) | ||||||||
|
||||||||
- Check the package range in package.json: Open the `package.json` file and locate the dependency entry for the package you're interested in. The version range is specified after the package name, using a combination of version numbers and symbols. Examples of version ranges are ^1.0.0, ~1.0.0, or >=1.0.0 <2.0.0. Ensure that the desired version falls within the specified range. | ||||||||
|
||||||||
- Check the desired version in `yarn.lock`: Open the `yarn.lock` file and search for the package name. If the package is listed, check the version number specified for the package. Compare this version number with the desired version. | ||||||||
|
||||||||
- If the package range is suitable but `yarn.lock` does not include the desired version, edit the `yarn.lock` file and remove the lines corresponding to the package. Then, run `yarn osd bootstrap` to have the latest version of the package, that satisfies the range from `package.json`, added to `yarn.lock`. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Add instructions on how to determine? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. will add instructions. |
||||||||
|
||||||||
- If the package range is not suitable and there is no resolutions or the package range in the resolutions is not correct, we can add or update version in the resolutions for all the package sub-deps or specific package sub-dep. For more on version updates please see [Why](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-why-would-you-want-to-do-this) and [How](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-how-to-use-it) to upgrade. | ||||||||
|
||||||||
``` | ||||||||
Example: If [email protected] exists for subdeps in yarn.lock file. But [email protected] is the target version. | ||||||||
|
||||||||
Step 1: remove the entry from lockfile and bootstrap; if a suitable version was installed, you can stop. | ||||||||
Step 2: use resolutions to require a specific range for the nested dependency in package.json: | ||||||||
'resolutions': { "**/foobar": "^1.y", | ||||||||
"**/foo": "^2.x" , | ||||||||
"**/bar": "^3.k"} | ||||||||
Step 3: repeat step 1 | ||||||||
|
||||||||
``` | ||||||||
|
||||||||
Please be aware of that fixing nested dependencies can be tricky. Sometimes, bumping a parent package of the nested dependency can upgrade several of the nested dependencies at once to solve multiple security vulnerabilities and provide a more maintainable code base. | ||||||||
|
||||||||
## Backport a Vulnerability Fix | ||||||||
|
||||||||
To backport a CVE fix to previous versions of OpenSearch Dashboards, add the desired backport labels (e.g., backport 1.x) to the PR. Upon merging the PR, a workflow will attempt to backport it. If this process fails, the PR will be updated with a comment detailing the failure, and you'll need to follow the provided instructions to manually backport the changes in a new PR. Keep in mind that some CVEs may require distinct resolutions for each branch, such as a major version bump in the main branch, a minor version bump in the 2.x branch, and a specific resolution in the 1.x branch. Refer to the following steps for guidance: | ||||||||
|
||||||||
1. Identify the pull request you want to backport and the target backport version. | ||||||||
2. Create a new local branch from the target version. | ||||||||
3. Cherry-pick the changes from the pull request into the new branch. To do this, you can use the `git cherry-pick` command followed by the hash of the pull request commit. For example: `git cherry-pick 123456`. | ||||||||
4. Resolve any conflicts. This step may require some manual intervention. | ||||||||
5. Run `yarn osd bootstrap` in the root directory. This will update the dependencies, install the latest version of the package that satisfies the range from `package.json`, and add the updated package information to the `yarn.lock` file. | ||||||||
5. Test the changes thoroughly. | ||||||||
6. Push the new branch to the appropriate remote repository. | ||||||||
7. Submit a new pull request to the target version for the backported changes. | ||||||||
|
||||||||
``` | ||||||||
Example: backport a pull request with hash 123 in main to 1.3 | ||||||||
|
||||||||
* Fetch the latest changes from upstream repo: | ||||||||
git pull upstream | ||||||||
|
||||||||
* Create a new local branch from the target version: | ||||||||
git checkout -b backport-cve upstream/1.3 | ||||||||
|
||||||||
* Cherry pick the changes: | ||||||||
git cherry-pick 123 | ||||||||
|
||||||||
* Resolve any conflicts. | ||||||||
|
||||||||
* Push to your origin forked repo: | ||||||||
git push -u origin backport-cve | ||||||||
|
||||||||
* Submit a new pull request to 1.3. | ||||||||
|
||||||||
``` | ||||||||
|
||||||||
It's worth noting that backporting a pull request can be a complex process and depending on the changes involved, additional steps might be required to resolve conflicts. It's important to carefully review and test the changes to ensure they are compatible with the version of OpenSearch Dashboards in the target branch and that the changes are applied correctly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this paragraph is using a standard template for all repos. For example, here is the SECURITY.md from OpenSearch: https://github.com/opensearch-project/OpenSearch/blob/main/SECURITY.md. Let's just use it as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure where they got that but the grammar errors are bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the missing comma after the first subordinate clause, the other suggestions are less black and white... and I wouldn't classify any of them as "bad grammar", but I'm not a native speaker so what do I know :)
@AMoo-Miki: If you feel strongly about the way the paragraph is stated, I'd recommend opening up a PR against the one @ananzh links above, so that we can all benefit from this feedback.