Skip to content

Commit c84590d

Browse files
kantordkantord
committed
copy documents form mcp optimizer
1 parent 89346ff commit c84590d

File tree

4 files changed

+361
-0
lines changed

4 files changed

+361
-0
lines changed

‎CODE_OF_CONDUCT.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# Code of Conduct
2+
3+
## Our Pledge
4+
5+
In the interest of fostering an open and welcoming environment, we as
6+
contributors and maintainers pledge to making participation in our project and
7+
our community a harassment-free experience for everyone, regardless of age, body
8+
size, disability, ethnicity, gender identity and expression, level of experience,
9+
nationality, personal appearance, race, religion, or sexual identity and
10+
orientation.
11+
12+
## Our Standards
13+
14+
Examples of behavior that contributes to creating a positive environment
15+
include:
16+
17+
* Using welcoming and inclusive language
18+
* Being respectful of differing viewpoints and experiences
19+
* Gracefully accepting constructive criticism
20+
* Focusing on what is best for the community
21+
* Showing empathy towards other community members
22+
23+
Examples of unacceptable behavior by participants include:
24+
25+
* The use of sexualized language or imagery and unwelcome sexual attention or
26+
advances
27+
* Trolling, insulting/derogatory comments, and personal or political attacks
28+
* Public or private harassment
29+
* Publishing others' private information, such as a physical or electronic
30+
address, without explicit permission
31+
* Other conduct which could reasonably be considered inappropriate in a
32+
professional setting
33+
34+
## Our Responsibilities
35+
36+
Project maintainers are responsible for clarifying the standards of acceptable
37+
behavior and are expected to take appropriate and fair corrective action in
38+
response to any instances of unacceptable behavior.
39+
40+
Project maintainers have the right and responsibility to remove, edit, or
41+
reject comments, commits, code, wiki edits, issues, and other contributions
42+
that are not aligned to this Code of Conduct, or to ban temporarily or
43+
permanently any contributor for other behaviors that they deem inappropriate,
44+
threatening, offensive, or harmful.
45+
46+
## Scope
47+
48+
This Code of Conduct applies both within project spaces and in public spaces
49+
when an individual is representing the project or its community. Examples of
50+
representing a project or community include using an official project e-mail
51+
address, posting via an official social media account, or acting as an appointed
52+
representative at an online or offline event. Representation of a project may be
53+
further defined and clarified by project maintainers.
54+
55+
## Enforcement
56+
57+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
58+
reported by contacting the project team at <code-of-conduct@stacklok.com>. All
59+
complaints will be reviewed and investigated and will result in a response that
60+
is deemed necessary and appropriate to the circumstances. The project team is
61+
obligated to maintain confidentiality with regard to the reporter of an incident.
62+
Further details of specific enforcement policies may be posted separately.
63+
64+
Project maintainers who do not follow or enforce the Code of Conduct in good
65+
faith may face temporary or permanent repercussions as determined by other
66+
members of the project's leadership.
67+
68+
## Attribution
69+
70+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
71+
available at [http://contributor-covenant.org/version/1/4][version]
72+
73+
[homepage]: http://contributor-covenant.org
74+
[version]: http://contributor-covenant.org/version/1/4/

‎CONTRIBUTING.md‎

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
# Contributing to `mcp-shell` <!-- omit from toc -->
2+
3+
First off, thank you for taking the time to contribute to MCP Shell! :+1: :tada: MCP Shell is released under the Apache 2.0 license.
4+
If you would like to contribute something or want to hack on the code, this
5+
document should help you get started. You can find some hints for starting
6+
development in mcp-shell's
7+
[README](https://github.com/StacklokLabs/mcp-shell/blob/main/README.md).
8+
9+
## Table of contents <!-- omit from toc -->
10+
11+
- [Code of conduct](#code-of-conduct)
12+
- [Reporting security vulnerabilities](#reporting-security-vulnerabilities)
13+
- [How to contribute](#how-to-contribute)
14+
- [Using GitHub Issues](#using-github-issues)
15+
- [Not sure how to start contributing?](#not-sure-how-to-start-contributing)
16+
- [Pull request process](#pull-request-process)
17+
- [Commit message guidelines](#commit-message-guidelines)
18+
19+
## Code of conduct
20+
21+
This project adheres to the
22+
[Contributor Covenant](https://github.com/StacklokLabs/mcp-shell/blob/main/CODE_OF_CONDUCT.md)
23+
code of conduct. By participating, you are expected to uphold this code. Please
24+
report unacceptable behavior to
25+
[code-of-conduct@stacklok.com](mailto:code-of-conduct@stacklok.com).
26+
27+
## Reporting security vulnerabilities
28+
29+
If you think you have found a security vulnerability in mcp-shell please DO
30+
NOT disclose it publicly until we've had a chance to fix it. Please don't report
31+
security vulnerabilities using GitHub issues; instead, please follow this
32+
[process](https://github.com/StacklokLabs/mcp-shell/blob/main/SECURITY.md)
33+
34+
## How to contribute
35+
36+
### Using GitHub Issues
37+
38+
We use GitHub issues to track bugs and enhancements. If you have a general usage
39+
question, please ask in the #mcp-servers channel of the
40+
[Stacklok Discord server](https://discord.gg/stacklok).
41+
42+
If you are reporting a bug, please help to speed up problem diagnosis by
43+
providing as much information as possible. Ideally, that would include a small
44+
sample project that reproduces the problem.
45+
46+
### Not sure how to start contributing?
47+
48+
PRs to resolve existing issues are greatly appreciated and issues labeled as
49+
["good first issue"](https://github.com/StacklokLabs/mcp-shell/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
50+
are a great place to start!
51+
52+
### Pull request process
53+
54+
- All commits must include a Signed-off-by trailer at the end of each commit
55+
message to indicate that the contributor agrees to the Developer Certificate
56+
of Origin. For additional details, check out the [DCO instructions](dco.md).
57+
58+
- Create an issue outlining the fix or feature.
59+
- Fork the mcp-shell repository to your own GitHub account and clone it
60+
locally.
61+
- Hack on your changes.
62+
- Correctly format your commit messages, see
63+
[Commit message guidelines](#commit-message-guidelines) below.
64+
- Open a PR by ensuring the title and its description reflect the content of the
65+
PR.
66+
- Ensure that CI passes, if it fails, fix the failures.
67+
- Every pull request requires a review from the core mcp-shell team before
68+
merging.
69+
- Once approved, all of your commits will be squashed into a single commit with
70+
your PR title.
71+
72+
### Commit message guidelines
73+
74+
We follow the commit formatting recommendations found on
75+
[Chris Beams' How to Write a Git Commit Message article](https://chris.beams.io/posts/git-commit/):
76+
77+
1. Separate subject from body with a blank line
78+
1. Limit the subject line to 50 characters
79+
1. Capitalize the subject line
80+
1. Do not end the subject line with a period
81+
1. Use the imperative mood in the subject line
82+
1. Use the body to explain what and why vs. how

‎SECURITY.md‎

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
# Security Policy
2+
3+
The StacklokLabs community take security seriously! We appreciate your efforts
4+
to disclose your findings responsibly and will make every effort to acknowledge
5+
your contributions.
6+
7+
## Reporting a vulnerability
8+
9+
To report a security issue, please use the GitHub Security Advisory
10+
["Report a Vulnerability"](https://github.com/StacklokLabs/mcp-shell/security/advisories/new)
11+
tab.
12+
13+
If you are unable to access GitHub you can also email us at
14+
[security@stacklok.com](mailto:security@stacklok.com).
15+
16+
Include steps to reproduce the vulnerability, the vulnerable versions, and any
17+
additional files to reproduce the vulnerability.
18+
19+
If you are only comfortable sharing under GPG, please start by sending an email
20+
requesting a public PGP key to use for encryption.
21+
22+
### Contacting the StacklokLabs security team
23+
24+
Contact the team by sending email to
25+
[security@stacklok.com](mailto:security@stacklok.com).
26+
27+
## Disclosures
28+
29+
### Private disclosure processes
30+
31+
The StacklokLabs community asks that all suspected vulnerabilities be handled in
32+
accordance with
33+
[Responsible Disclosure model](https://en.wikipedia.org/wiki/Responsible_disclosure).
34+
35+
### Public disclosure processes
36+
37+
If anyone knows of a publicly disclosed security vulnerability please
38+
IMMEDIATELY email [security@stacklok.com](mailto:security@stacklok.com) to
39+
inform us about the vulnerability so that we may start the patch, release, and
40+
communication process.
41+
42+
If a reporter contacts us to express intent to make an issue public before a
43+
fix is available, we will request if the issue can be handled via a private
44+
disclosure process. If the reporter denies the request, we will move swiftly
45+
with the fix and release process.
46+
47+
## Patch, release, and public communication
48+
49+
For each vulnerability, the StacklokLabs security team will coordinate to create
50+
the fix and release, and notify the rest of the community.
51+
52+
All of the timelines below are suggestions and assume a Private Disclosure.
53+
54+
- The security team drives the schedule using their best judgment based on
55+
severity, development time, and release work.
56+
- If the security team is dealing with a Public Disclosure all timelines become
57+
ASAP.
58+
- If the fix relies on another upstream project's disclosure timeline, that will
59+
adjust the process as well.
60+
- We will work with the upstream project to fit their timeline and best protect
61+
StacklokLabs users.
62+
- The Security team will give advance notice to the Private Distributors list
63+
before the fix is released.
64+
65+
### Fix team organization
66+
67+
These steps should be completed within the first 24 hours of Disclosure.
68+
69+
- The security team will work quickly to identify relevant engineers from the
70+
affected projects and packages and bring those engineers into the
71+
[security advisory](https://docs.github.com/en/code-security/security-advisories/)
72+
thread.
73+
- These selected developers become the "Fix Team" (the fix team is often drawn
74+
from the projects MAINTAINERS)
75+
76+
### Fix development process
77+
78+
These steps should be completed within the 1-7 days of Disclosure.
79+
80+
- Create a new
81+
[security advisory](https://docs.github.com/en/code-security/security-advisories/)
82+
in affected repository by visiting
83+
`https://github.com/StacklokLabs/mcp-shell/security/advisories/new`
84+
- As many details as possible should be entered such as versions affected, CVE
85+
(if available yet). As more information is discovered, edit and update the
86+
advisory accordingly.
87+
- Use the CVSS calculator to score a severity level.
88+
- Add collaborators from codeowners team only (outside members can only be added
89+
after approval from the security team)
90+
- The reporter may be added to the issue to assist with review, but **only
91+
reporters who have contacted the security team using a private channel**.
92+
- Select 'Request CVE'
93+
- The security team / Fix Team create a private temporary fork
94+
- The Fix team performs all work in a 'security advisory' within its temporary
95+
fork
96+
- CI can be checked locally using the [act](https://github.com/nektos/act)
97+
project
98+
- All communication happens within the security advisory, it is _not_ discussed
99+
in slack channels or non private issues.
100+
- The Fix Team will notify the security team that work on the fix branch is
101+
completed, this can be done by tagging names in the advisory
102+
- The Fix team and the security team will agree on fix release day
103+
- The recommended release time is 4pm UTC on a non-Friday weekday. This means
104+
the announcement will be seen morning Pacific, early evening Europe, and late
105+
evening Asia.
106+
107+
If the CVSS score is under ~4.0
108+
([a low severity score](https://www.first.org/cvss/specification-document#i5))
109+
or the assessed risk is low the Fix Team can decide to slow the release process
110+
down in the face of holidays, developer bandwidth, etc.
111+
112+
Note: CVSS is convenient but imperfect. Ultimately, the security team has
113+
discretion on classifying the severity of a vulnerability.
114+
115+
The severity of the bug and related handling decisions must be discussed in
116+
the security advisory, never in public repos.
117+
118+
### Fix disclosure process
119+
120+
With the Fix Development underway, the security team needs to come up with an
121+
overall communication plan for the wider community. This Disclosure process
122+
should begin after the Fix Team has developed a Fix or mitigation so that a
123+
realistic timeline can be communicated to users.
124+
125+
**Fix release day** (Completed within 1-21 days of Disclosure)
126+
127+
- The Fix Team will approve the related pull requests in the private temporary
128+
branch of the security advisory
129+
- The security team will merge the security advisory / temporary fork and its
130+
commits into the main branch of the affected repository
131+
- The security team will ensure all the binaries are built, signed, publicly
132+
available, and functional.
133+
- The security team will announce the new releases, the CVE number, severity,
134+
and impact, and the location of the binaries to get wide distribution and user
135+
action. As much as possible this announcement should be actionable, and
136+
include any mitigating steps users can take prior to upgrading to a fixed
137+
version. An announcement template is available below. The announcement will be
138+
sent to the following channels:
139+
- A link to fix will be posted to the
140+
[Stacklok Discord Server](https://discord.gg/stacklok) in the #mcp-servers
141+
channel.
142+
143+
## Retrospective
144+
145+
These steps should be completed 1-3 days after the Release Date. The
146+
retrospective process
147+
[should be blameless](https://landing.google.com/sre/book/chapters/postmortem-culture.html).
148+
149+
- The security team will send a retrospective of the process to the
150+
[Stacklok Discord Server](https://discord.gg/stacklok) including details on
151+
everyone involved, the timeline of the process, links to relevant PRs that
152+
introduced the issue, if relevant, and any critiques of the response and
153+
release process.

‎dco.md‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
# Developer Certificate of Origin (DCO)
2+
3+
In order to contribute to the project, you must agree to the Developer
4+
Certificate of Origin. A
5+
[Developer Certificate of Origin (DCO)](https://developercertificate.org/) is an
6+
affirmation that the developer contributing the proposed changes has the
7+
necessary rights to submit those changes. A DCO provides some additional legal
8+
protections while being relatively easy to do.
9+
10+
The entire DCO can be summarized as:
11+
12+
- Certify that the submitted code can be submitted under the open source license
13+
of the project (e.g. Apache 2.0)
14+
- I understand that what I am contributing is public and will be redistributed
15+
indefinitely
16+
17+
## How to Use Developer Certificate of Origin
18+
19+
In order to contribute to the project, you must agree to the Developer
20+
Certificate of Origin. To confirm that you agree, your commit message must
21+
include a Signed-off-by trailer at the bottom of the commit message.
22+
23+
For example, it might look like the following:
24+
25+
```bash
26+
A commit message
27+
28+
Closes gh-345
29+
30+
Signed-off-by: jane marmot <jmarmot@example.org>
31+
```
32+
33+
The Signed-off-by [trailer](https://git-scm.com/docs/git-interpret-trailers) can
34+
be added automatically by using the
35+
[-s or –signoff command line option](https://git-scm.com/docs/git-commit/2.13.7#Documentation/git-commit.txt--s)
36+
when specifying your commit message:
37+
38+
```bash
39+
git commit -s -m
40+
```
41+
42+
If you have chosen the
43+
[Keep my email address private](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#about-commit-email-addresses)
44+
option within GitHub, the Signed-off-by trailer might look something like:
45+
46+
```bash
47+
A commit message
48+
49+
Closes gh-345
50+
51+
Signed-off-by: jane marmot <462403+jmarmot@users.noreply.github.com>
52+
```

0 commit comments

Comments
 (0)