diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4f329b83..7ab86f1e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,6 +8,7 @@ The following document is a rule set of guidelines for contributing. - [What and when to contribute](#what-and-when-to-contribute) - [Reporting bugs](#reporting-bugs) +- [Disclosing vulnerabilities](#disclosing-vulnerabilities) - [Code Contributions](#code-contributions) - [Step 1: Fork](#step-1-fork) - [Step 2: Branch](#step-2-branch) @@ -37,27 +38,27 @@ We appreciate bug reports! If you experience an issue with IF, you can report it 3. Click on `Create New Issue` and select the `Bug Report` template. 4. Fill out the requested information. -The more detailed information you provide in the bug report, the easier it will be for us to diagnose, triage and resolve your issue. We ask for some simple information about your issue, including a description of the error, the expected behaviour, the actual behaviour and the steps we can take to reproduce the error in our local environments. We also then prompt you to provide a link to [Stackblitz](https://stackblitz.com/) or a similar online environment where we can run your manifest and observe the error. If you prefer _not_ to send a link, we would appreciate a copy of the manifest file that you ran to produce the error, information about your runtime environment and any additional code that's required to reproduce the error. This is all designed to enable us to reproduce the same error and debug it for you as quickly as possible. +The more detailed information you provide in the bug report, the easier it will be for us to diagnose, triage, and resolve your issue. We ask for some simple information about your issue, including a description of the error, the expected behaviour, the actual behaviour and the steps we can take to reproduce the error in our local environments. We also then prompt you to provide a link to [Stackblitz](https://stackblitz.com/) or a similar online environment where we can run your manifest and observe the error. If you prefer *not* to send a link, we would appreciate a copy of the manifest file that you ran to produce the error, information about your runtime environment, and any additional code that's required to reproduce the error. This is all designed to enable us to reproduce the same error and debug it for you as quickly as possible. -Once a suitably detailed bug report exists, we will triage it. Triage means that the core team will examine the issue and assign an urgency label - either Low, Medium or High. +Once a suitably detailed bug report exists, we will triage it. We hold weekly triage calls on Tuesdays. In most cases, the triage call will be the core team's first interaction with the bug, although in some cases we may engage asynchronously in advance of the call. Triage means that the core team will examine the issue and assign an urgency label - either Low, Medium or High. The assessment rubric is as follows: -| | Consequence | Severity | -| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -------- | -| Bugs in IF core leading to incorrect calculations | unusable framework | 5 | -| Bugs in builtins leading to incorrect calculations | core pathways fail, IF very limited in functionality | 5 | -| Bugs in template | Harder to build plugins, ecosystem growth is impacted | 2 | -| Bugs in docs | product does not match expectation, hard to debug, frustration, loss of adoption | 2 | -| Security flaw: privacy related | leak user data, unlikely to achieve adoption in serious orgs | 5 | -| Security flaw: permissions escalation | expose user to malware | 5 | -| Code not addressing user needs | no product market fit, loss of adoption | 5 | -| Communication failures within team | Conflicting or duplicating work, frustration, morale damage | 4 | -| Communication failures with community | we lose product market fit, we do not have good community retention, reputational damage | 3 | -| Communication failures with leadership | product does not meet business goals | 3 | -| License compliance failures, including in supply chain (e.g. exposing privileged api responses for free via a plugin) | 4 | -| Bugs affecting releases | users stuck on old versions | 4 | -| Strategy failures | no product market fit | 2 | +| | Consequence | Severity | +| ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -------- | +| Bugs in IF core leading to incorrect calculations | unusable framework | 5 | +| Bugs in builtins leading to incorrect calculations | core pathways fail, IF very limited in functionality | 5 | +| Bugs in template | Harder to build plugins, ecosystem growth is impacted | 2 | +| Bugs in docs | product does not match expectation, hard to debug, frustration, loss of adoption | 2 | +| Security flaw: privacy related | leak user data, unlikely to achieve adoption in serious orgs | 5 | +| Security flaw: permissions escalation | expose user to malware | 5 | +| Code not addressing user needs | no product market fit, loss of adoption | 5 | +| Communication failures within team | Conflicting or duplicating work, frustration, morale damage | 4 | +| Communication failures with community | we lose product market fit, we do not have good community retention, reputational damage | 3 | +| Communication failures with leadership | product does not meet business goals | 3 | +| License compliance failures, including in supply chain (e.g. exposing privileged api responses for free via a plugin) | 4 | +| Bugs affecting releases | users stuck on old versions | 4 | +| Strategy failures | no product market fit | 2 | The mapping of severity to label is as follows: @@ -69,9 +70,9 @@ The mapping of severity to label is as follows: | 4 | H | | 5 | H | -For high urgency bugs, the fix will be implemented as soon as possible. Low priority bugs will be backlogged and addressed when there is developer time available. Low priority bugs will also be tagged `help-wanted` so that they can be addressed by community members. +During the bug triage we will also discuss a remediation plan for the bug. This will be communicated in the comments on the bug report. For high urgency bugs, the fix will be implemented as soon as possible, maybe reorganizing our current work to accommodate it. For medium priority bugs, we will schedule the fix in the next available sprint. Low priority bugs will be backlogged and addressed when there is developer time available. Low priority bugs will also be tagged `help-wanted` so that they can be addressed by community members. -Not every bug will be fixed. We may decide _not_ to fix a bug in cases such as: +Not every bug will be fixed. We may decide *not* to fix a bug in cases such as: - fixing the bug has some detrimental side effect elsewhere in the product - the bug has a fix coming soon as part of another upgrade @@ -80,17 +81,30 @@ Not every bug will be fixed. We may decide _not_ to fix a bug in cases such as: The bug will be labelled `fix-now`, `fix-later` or `wont-fix` to reflect our remediation plan and details will be provided in issue comments. +## Disclosing vulnerabilities + +If you discover a security vulnerability in IF, please report it to if-disclosures@greensoftware.foundation. + +Include the following information: + +- description of the issue +- steps to reproduce +- steps to fix, if known + +The IF team will respond as quickly as possible. Post-graduation there will be no full-time development team, but GSF staff will aim to get the vulnerability patched as quickly as possible, aiming for <=14 day response time. + + ## Code Contributions ### Step 1: Fork Fork the project on [GitHub](https://github.com/Green-Software-Foundation/if) -You then have your own copy of the repository that you can change. +You then have your own copy of the repository that you can change. ### Step 2: Branch -Create new branch in your forked copy of the `if` repository, which will contain your new feature, fix or change. +Create new branch in your forked copy of the `if` repository, which will contain your new feature, fix or change. ```bash $ git checkout -b @@ -108,7 +122,7 @@ $ git config --global user.email "user@example.com" Each commit should cover one change to one resource. You should not add multiple changes to a single commit. Commit message should clearly describe on which resource changes are made. For the commit message, we adhere to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. -Conventional commits are organized with a type, a scope and a description. The type can be one of: +Conventional commits are organized with a type, a scope and a description. The type can be one of: - 'feat', - 'fix', @@ -129,10 +143,10 @@ Here's an example of a valid commit message: feat(lib): initial commit for time-sync logic ``` -or +or ``` -test(lib): in teads-curve add unit test to check that error is raised on missing tdp param +test(lib): in teads-curve add unit test to check that error is raised on missing tdp param ``` Run `npm run fix` before commiting. If your commit message does not conform to the conventional commit specification or if you have not run `npm run fix` your commit will not satisfy the commitlint check. @@ -142,7 +156,7 @@ Add and commit with your commit message: ```bash $ git add my/changed/files $ git commit -m "(): " -``` +``` ### Step 5: Push @@ -154,7 +168,7 @@ $ git push origin ### Step 6: Pull Request -Open a Pull Request from your fork of the repository to the `main` branch of the IF repository with a clear title and description according to [template](.github/PULL_REQUEST_TEMPLATE.md). +Open a Pull Request from your fork of the repository to the `dev` branch of the IF repository with a clear title and description according to [template](.github/PULL_REQUEST_TEMPLATE.md). Pull requests will not be reviewed unless they pass all CI. This includes a lint check and running our unit tests. @@ -162,7 +176,7 @@ Pull requests will not be reviewed unless they pass all CI. This includes a lint ### Code structuring patterns -Avoid having functions which are responsible to do multiple things at the same time. Make sure one function/method does one thing, and does it well. +Avoid having functions which are responsible to do multiple things at the same time. Make sure one function/method does one thing, and does it well. ### Functional Programming @@ -170,13 +184,14 @@ We have a preference towards functional programming styles in the IF. This is be We recommend starting with these [basic principles and guidelines](https://dev.to/jamesrweb/principles-of-functional-programming-4b7c) for functional programming. + ### Naming conventions -We prefer not to use abbreviations of contractions in parameter names. +We prefer not to use abbreviations of contractions in parameter names. -Using fully descriptive names makes the code more readable, which in turn helps reviewers and anyone else aiming to understand how the plugin works. +Using fully descriptive names makes the code more readable, which in turn helps reviewers and anyone else aiming to understand how the plugin works. -It also helps to avoid ambiguity and naming collisions within and across plugins. Ensure that names clearly and precisely describe the purpose of an element to make its functionality immediately apparent. +It also helps to avoid ambiguity and naming collisions within and across plugins. Your name should describe what an element does as precisely as practically possible. For example, we prefer `functionalUnit` to `funcUnit`, `fUnit`, or any other abbreviation. @@ -189,6 +204,7 @@ In yaml files, we prefer to use kebab-case (`like-this`) for field names. For ex Global constants can be given capitalized names, such as `TIME_UNITS_IN_SECONDS`. + #### Documentation Every logical unit (`function, method`) should be covered with appropriate documentation. For documenting such, multi-line comment style is used. @@ -205,10 +221,9 @@ const logMessage = (message: string) => console.log(message) ### Writing tests -One test file should be responsible for one module. `describe` blocks should be used for module and function/method description. First `describe` should follow `resource/module: ` pattern. Second describe title should follow `method(): ` pattern. Test units can use `it` blocks whose title should exactly describe behaviour and input argument. - -See example: +One test file should be responsible for one module. `describe` blocks should be used for module and function/method description. First `describe` should follow `resource/module: ` pattern. Second describe title should follow `method(): ` pattern. Test units can use `it` blocks whose title should exactly describe behaviour and input argument. +See example: ```ts describe('util/args: ', () => { describe('parseProcessArgument(): ', () => { @@ -234,9 +249,11 @@ To help us to diagnose and debug your issue, please provide either a [Stackblitz - links to any code (e.g. your own plugin code), it must be available online, - runtime information such as OS, node version, package.json, IF version -High severity bugs will be fixed as soon as possible, whereas medium and low severity bug fixes will likely be backlogged for attention in the next available sprint. +Reported bugs will be discussed among the team in a weekly bug triage and be assigned a severity (low, medium or high). + +High severity bugs will be fixed as soon as possible, whereas medium and low severity bug fixes will likely be backlogged for attention in the next available sprint. In some cases, we might decide not to fix certain bugs if they are low severity, either because we anticipate fixes coming soon as part of already-scheduled upgrades or because we think the fixes make "good first issues" for community contributors. Community members are welcome to report any issue they face and also work on fixing the low priority bugs. -_[⬅️ back to the root](/README.md#ief)_ +*[⬅️ back to the root](/README.md#ief)* diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..da858443 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,100 @@ +# Security Policy + +## Reporting a Vulnerability + +To report a security issue, please email if-disclosures@greensoftware.foundation with a description of the issue, steps required to reproduce the issue, affected versions and, if known, mitigations for the issue. + +Our contributors are comprised of volunteers so we cannot guarantee a specific response time, but someone from our team will reply and address the issue as soon as possible. + +# Security Review + +We perform regular reviews inline with the information provided below. All releases go through these reviews but multiple people in the project team prior to release as part of our quality and security review. + +## Basics +### Basic Project Website Content +- Describe what the project does - ✅ in README and homepage at https://if.greensoftware.foundation +- Provide info how to obtain/provide feedback and contribute - ✅ https://if.greensoftware.foundation/community +- Explain contribution process - ✅ https://github.com/Green-Software-Foundation/if/blob/main/CONTRIBUTING.md + +### FLOSS license +- Must be released as FLOSS - ✅ MIT License https://github.com/Green-Software-Foundation/if/blob/main/LICENSE +- Must post the license - ✅ https://github.com/Green-Software-Foundation/if/blob/main/LICENSE +- Also approved by OSI - ✅ https://opensource.org/license/MIT/ + +### Documentation +- Provides basic documentation - ✅ https://if.greensoftware.foundation + +### Other +- Project site, downloads etc must support HTTPS with TLS - ✅ using GitHub to host which supports this https://github.com/Green-Software-Foundation/if +- Have mechanism for discussion - ✅ github issues https://github.com/Green-Software-Foundation/if/issues, discussion board https://github.com/Green-Software-Foundation/if/discussions and mailing list at if-community@greensoftware.foundaton +- Project must be maintained - ✅ actively maintaned by GSF and its members + +## Change control +### Public VCS repo +- Readable public VCS repo - ✅ yes, Github https://github.com/Green-Software-Foundation/if +- Track changes - ✅ yes, Git https://github.com/Green-Software-Foundation/if/commits/main +- Interim versions between releases available for review - ✅ yes, interim versions actively developed and availble on the `main` branch https://github.com/Green-Software-Foundation/if + +### Unique versioning numbering +- Unique indentifier for each release - ✅ https://github.com/Green-Software-Foundation/if/releases + +### Release notes +- Human readable release notes for each release (not git log) - ✅ https://github.com/Green-Software-Foundation/if/releases +- Address each publicly known vulnerability - ✅ N/A, no vulnerability reported yet + +## Reporting +### Bug reporting process +- Process to submit bugs - ✅ https://github.com/Green-Software-Foundation/if/blob/main/CONTRIBUTING.md#reporting-bugs +- Must acknowledge bugs (reply) submitted between 2-12 months - ✅ each bug has at least an acknowledgement or was opened by a maintainer (so acknowledged by a maintainer): https://github.com/Green-Software-Foundation/if/issues?q=is%3Aopen+is%3Aissue+label%3Abug +- Publicly available archive for reports and responses - ✅ github issues: https://github.com/Green-Software-Foundation/if/issues?q=is%3Aopen+is%3Aissue+label%3Abug + +## Vulnerability report process +- Have a vulnerability report process - ✅ Included in CONTRIBUTING.md +- Private vulnerability if supported must include info how to send - ✅ N/A (allowed) - no private vulnerability reporting set up but proposed +- Initial response time for vulnerability submitted in last 6 months must be <= 14 days - ✅ N/A (allowed) - no vulnerabilities have yet been reported. Response times for bugs and other issues have been <14 days, post-graduation development will be by volunteers and open source developer community, so we can't guarantee a time to resolution. + +## Quality +### Working build system +- Must provide a working build system - ✅ IF is a locally running NodeJS app. We do provide a devcontainer for eays environment setup. Installation is simply achieved using `npm i @grnsft/if`. + +### Automated test suite +- Have at least one automated test suite and documentation how to run it - ✅ We have a comprehensive set of unit tests and a library of becnhmark manifest files that act as integration tests. These can be run locally, and they are executed as part of our CI/CD on any PRs into `main`. + +## New functionaility testing +- Formal/informal policy for adding tests for new features - ✅ Test suite in CI/CD checks for breaking changes in PRs. Any new feature must include unit tests and an example manifest that demonstrates usage. +- Evidence of policy being adhered to - ✅ + +### Warning flags +- Compiler warning flags or linter tools for code quality/errors - ✅ CodeQL analysis in automated CI : https://github.com/Green-Software-Foundation/carbon-aware-sdk/blob/dev/.github/workflows/1-pr.yaml#L82 +- Address warnings from these tools - ✅ blocking PRs on fail + +## Security +### Secure development knowledge +- At least one primary developer who knows how to design secure software - ✅ Manushak and Narek are both primary developers and have broad experience. +- At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them - ✅ + +### Use basic good cryptographic practices +- https://www.bestpractices.dev/en/criteria/0#0.crypto_published - ✅ n/a +- https://www.bestpractices.dev/en/criteria/0#0.crypto_floss - ✅ n/a +- https://www.bestpractices.dev/en/criteria/0#0.crypto_keylength - ✅ n/a +- https://www.bestpractices.dev/en/criteria/0#0.crypto_working - ✅ n/a +- https://www.bestpractices.dev/en/criteria/0#0.crypto_password_storage - ✅ n/a +- https://www.bestpractices.dev/en/criteria/0#0.crypto_random - ✅ n/a + +### Secured delivery against man-in-the-middle (MITM) attacks +- Delivery mechanisms that counters MITM - ✅ n/a +- Cyrptographic hash NOT retrived over HTTP - ✅ n/a + +### Publicly known vulnerabilities fixed +- No unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 day - ✅ no such vulnerabilities + +### Other security issues +- Public repo doesnt leak private credential - ✅ does not do that. + +## Analysis +### Static code analysis +- At least one FLOSS static code analysis tool - ❌. +- All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed - ✅ We have not yet had any exploitable vulnerabilities reported, but the GSF team will respond promptly to any disclosed issues. + +### Dynamic code analysis +- All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. - ✅ We have not yet had any exploitable vulnerabilities reported, but the GSF team will respond promptly to any disclosed issues. diff --git a/package-lock.json b/package-lock.json index 55169657..92bff2da 100644 --- a/package-lock.json +++ b/package-lock.json @@ -3796,8 +3796,9 @@ } }, "node_modules/cross-spawn": { - "version": "7.0.3", - "license": "MIT", + "version": "7.0.6", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.6.tgz", + "integrity": "sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==", "dependencies": { "path-key": "^3.1.0", "shebang-command": "^2.0.0",