8000 update processes to allow for coordinated vulnerability disclosure by TravisEz13 · Pull Request #6042 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

update processes to allow for coordinated vulnerability disclosure #6042

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

Merged
merged 2 commits into from
Jan 27, 2018
Merged

update processes to allow for coordinated vulnerability disclosure #6042

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6346c84
update processes for coordinated vulnerability disclosure
TravisEz13 Jan 26, 2018
f159942
address PR feedback
TravisEz13 Jan 26, 2018
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
3 changes: 3 additions & 0 deletions .github/CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,8 @@ Additional references:

#### Before submitting

* If your change would fix a security vulnerability,
first follow the [vulnerability issue reporting policy][vuln-reporting], before submitting a PR.
* To avoid merge conflicts, make sure your branch is rebased on the `master` branch of this repository.
* Many code changes will require new tests,
so make sure you've added a new test if existing tests do not effectively test the code changed.
Expand Down Expand Up @@ -299,6 +301,7 @@ Once you sign a CLA, all your existing and future pull requests will be labeled
[testing-guidelines]: ../docs/testing-guidelines/testing-guidelines.md
[running-tests-outside-of-ci]: ../docs/testing-guidelines/testing-guidelines.md#running-tests-outside-of-ci
[issue-management]: ../docs/maintainers/issue-management.md
[vuln-reporting]: ../docs/maintainers/issue-management.md#Security-Vulnerabilities
[governance]: ../docs/community/governance.md
[using-prs]: https://help.github.com/articles/using-pull-requests/
[fork-a-repo]: https://help.github.com/articles/fork-a-repo/
Expand Down
11 changes: 9 additions & 2 deletions docs/maintainers/issue-management.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,14 @@
# Issue Management

## Security Vulnerabilities

If you believe that there is a security vulnerability in PowerShell Core,
it **must** be reported to [secure@microsoft.com](https://technet.microsoft.com/en-us/security/ff852094.aspx) to allow for [Coordinated Vulnerability Disclosure](https://technet.microsoft.com/en-us/security/dn467923).
**Only** file an issue, if secure@microsoft.com has confirmed filing an issue is appropriate.
10000 Copy link
Collaborator

Choose a reason for hiding this comment

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

How can I find out that the approval is received? Should I delete messages that are not able to approve? Maybe the MSFT team would rather exclusively publish such Issues or even announcements?

Copy link
Member Author

Choose a reason for hiding this comment

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

How can I find out that the approval is received?

For someone else, you cannot. secure@microsoft.com would tell the person reporting the issue if it is appropriate to file an issue. If this comes up, please alert one of the Microsoft maintainers. We will report the vulnerability to secure@microsoft.com and take it from there.

Should I delete messages that are not able to approve?

Don't delete a message yourself.

Maybe the MSFT team would rather exclusively publish such Issues or even announcements?

Yes, if it is found to actually be a vulnerability, most likely the filing of the issue will be done or at least coordinated by someone at Microsoft. The only time I can see that secure@microsoft.com would say that they should file an issue, which is not coordinated with the release of the fix is when the issue is determined not to be a vulnerability.

I don't want to make these instructions too specific until we find a need. The only need I see right now is if someone does report a vulnerability issue on GitHub, then, we can point to this policy on why we are not responding using GitHub. Something to the effect of:

This is not the appropriate place to report this issue, please see Security Vulnerabilities and report this issue to secure@microsoft.com. I have reported this issue on your behalf in the meantime.

But, we will have to take it on a case by case basis and see what the most appropriate response is.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Clear. Thanks!

/cc @markekraus Please read the new policy.


## Long-living issue labels
=======
## Issue and PR Labels

### Issue and PR Labels

Issues are opened for many different reasons.
We use the following labels for issue classifications:
Expand Down Expand Up @@ -61,6 +67,7 @@ These labels describe what feature area of PowerShell that an issue affects:
### Operating Systems

These are for issues that are specific to certain Operating Systems:

* `OS-Linux`
* `OS-macOS`
* `OS-Windows`
Expand Down
4 changes: 2 additions & 2 deletions docs/maintainers/releasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ This is to help track the release preparation work.

> Note: Step 2, 3 and 4 can be done in parallel.

1. Create a branch named `release` in `PowerShell/PowerShell` repository.
1. Create a branch named `release-<Release Tag>` in our private repository.
All release related changes should happen in this branch.
1. Prepare packages
- [Build release packages](#building-packages).
Expand All @@ -28,7 +28,7 @@ This is to help track the release preparation work.
1. [Create NuGet packages](#nuget-packages) and publish them to [powershell-core feed][ps-core-feed].
1. [Create the release tag](#release-tag) and push the tag to `PowerShell/PowerShell` repository.
1. Create the draft and publish the release in Github.
1. Merge the `release` branch to `master` and delete the `release` branch.
1. Merge the `release-<Release Tag>` branch to `master` in `powershell/powershell` and delete the `release-<Release Tag>` branch.
1. Publish Linux packages to Microsoft YUM/APT repositories.
1. Trigger the release docker builds for Linux and Windows container images.
- Linux: push a branch named `docker` to `powershell/powershell` repository to trigger the build at [powershell docker hub](https://hub.docker.com/r/microsoft/powershell/builds/).
Expand Down
8 changes: 4 additions & 4 deletions test/common/markdown/markdown.tests.ps1
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,19 +72,19 @@ Describe 'Common Tests - Validate Markdown Files' -Tag 'CI' {
try
{
$docsToTest = @(
'./.github/CONTRIBUTING.md'
'./*.md'
'./demos/SSHRemoting/*.md'
'./docker/*.md'
'./docs/*.md'
'./docs/building/*.md'
'./docs/cmdlet-example/*.md'
'./docs/git/submodules.md'
'./docs/installation/*.md'
'./docs/maintainers/README.md'
'./docs/maintainers/*.md'
'./docs/testing-guidelines/testing-guidelines.md'
'./demos/SSHRemoting/*.md'
'./docker/*.md'
'./test/powershell/README.md'
'./tools/*.md'
'./.github/CONTRIBUTING.md'
)
$filter = ($docsToTest -join ',')
&"gulp" test-mdsyntax --silent `
Expand Down
0