diff --git a/.github/SECURITY.md b/.github/SECURITY.md index 066cf1a2e..d591bf2a8 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -9,12 +9,23 @@ identified a security vulnerability in this repository, please use the GitHub Se Until it is published, this draft security advisory will only be visible to the maintainers of this project. Other users and teams may be added once the advisory is created. -We will send a response indicating the next steps in handling your report. After the initial reply to your report, we -will keep you informed of the progress towards a fix and full announcement and may ask for additional information or -guidance. +We will send a first response within 14 days, indicating the next steps in handling your report. After the initial +reply to your report, we will keep you informed of the progress towards a fix and full announcement and may ask for +additional information or guidance. For vulnerabilities in third-party dependencies or modules, please report them directly to the respective maintainers. +## Disclosure and credit + +Once a fix is released, we publish the security advisory and list the fixed vulnerability in the release notes. We +credit the reporter in both, unless they ask not to be named. + +## Supported versions + +Security fixes are made on the `develop` branch and shipped with the next release. Only the latest release receives +security fixes; they are not backported to older releases. A release stops receiving security fixes when the next +release is published, so please update to the latest release to get them. + ## Unofficial packages This project does not publish an official npm package. The npm package diff --git a/README.md b/README.md index becce71a1..412d05fd4 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ [![GitHub Downloads](https://img.shields.io/github/downloads/nlohmann/json/total)](https://github.com/nlohmann/json/releases) [![GitHub Issues](https://img.shields.io/github/issues/nlohmann/json.svg)](https://github.com/nlohmann/json/issues) [![Average time to resolve an issue](https://isitmaintained.com/badge/resolution/nlohmann/json.svg)](https://isitmaintained.com/project/nlohmann/json "Average time to resolve an issue") -[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/289/badge)](https://bestpractices.coreinfrastructure.org/projects/289) +[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/289/badge)](https://www.bestpractices.dev/projects/289) [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/nlohmann/json/badge)](https://scorecard.dev/viewer/?uri=github.com/nlohmann/json) [![Backup Status](https://app.cloudback.it/badge/nlohmann/json)](https://cloudback.it) [![GitHub Sponsors](https://img.shields.io/badge/GitHub-Sponsors-ff69b4)](https://github.com/sponsors/nlohmann) @@ -63,7 +63,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings. The library is also included in all popular [package managers](https://json.nlohmann.me/integration/package_managers/). -- **Serious testing**. Our code is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](https://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289). See the [quality assurance](https://json.nlohmann.me/community/quality_assurance) overview documentation. +- **Serious testing**. Our code is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](https://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289). See the [quality assurance](https://json.nlohmann.me/community/quality_assurance) overview documentation. Other aspects were not so important to us: diff --git a/docs/mkdocs/docs/community/assurance_case.md b/docs/mkdocs/docs/community/assurance_case.md index 87d8d6f14..10f4689c1 100644 --- a/docs/mkdocs/docs/community/assurance_case.md +++ b/docs/mkdocs/docs/community/assurance_case.md @@ -43,8 +43,8 @@ that an attacker controls, passed to [`parse`](../api/basic_json/parse.md), [`ac user code. The destructor does not recurse, so destroying a deeply nested value does not exhaust the stack. - **Bounded recursion.** The JSON parser and the binary readers keep their state in explicit stacks instead of recursing per nesting level. Operations that walk a value, such as [`dump`](../api/basic_json/dump.md), copying, - hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and continue with an - explicit stack below it. Some operations, such as comparison, [`diff`](../api/basic_json/diff.md), + comparison, hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and + continue with an explicit stack below it. Some operations, such as [`diff`](../api/basic_json/diff.md), [`flatten`](../api/basic_json/flatten.md), and the binary writers, still recurse once per nesting level; work on them is in progress. Applications that process untrusted input can limit its nesting depth with a [parser callback](../features/parsing/parser_callbacks.md). diff --git a/docs/mkdocs/docs/community/governance.md b/docs/mkdocs/docs/community/governance.md index 7da85f3fe..f4127ccea 100644 --- a/docs/mkdocs/docs/community/governance.md +++ b/docs/mkdocs/docs/community/governance.md @@ -91,6 +91,31 @@ activities include (but are not limited to): Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above. +## Access to project resources + +The project's resources are the [GitHub repository](https://github.com/nlohmann/json) with its settings, CI workflows +and secrets, and the documentation at [json.nlohmann.me](https://json.nlohmann.me), which is built and deployed from +the repository. Currently, the project lead is the only person with write or admin access to them. + +### Granting access + +Write or admin access is only granted by the project lead, and only to a contributor whose track record in the project +the project lead has reviewed first. The role is assigned manually and is the lowest one that is needed for the task. +Access is removed when it is no longer needed. GitHub requires two-factor authentication for everyone who can modify the +repository. + +### Secrets + +The CI workflows mostly use the token that GitHub creates for each workflow run. It is read-only by default, and each +workflow requests only the additional permissions it needs. The few other credentials, such as the token for +[Semgrep](https://semgrep.dev), are stored as encrypted GitHub Actions secrets: + +- Only people with admin access can create, change, or delete them. Their values cannot be read back, not even by + admins. +- They are not passed to workflows that run for pull requests from forks. +- They must never be committed to the repository or printed in logs. +- They are rotated whenever someone with admin access leaves the project, and immediately if a leak is suspected. + ## Support All participants in the community are encouraged to provide support for new users within the project management diff --git a/docs/mkdocs/docs/community/quality_assurance.md b/docs/mkdocs/docs/community/quality_assurance.md index bd35516b8..f2404c77b 100644 --- a/docs/mkdocs/docs/community/quality_assurance.md +++ b/docs/mkdocs/docs/community/quality_assurance.md @@ -200,6 +200,25 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa - [x] The test suite is executed with [Sanitizers](https://github.com/google/sanitizers) (address sanitizer, undefined behavior sanitizer, integer overflow detection, nullability violations). +## Dependencies + +!!! success "Requirement: No vulnerable dependencies" + + The library has no dependencies besides the C++ standard library. The tools used to build, test, and document it + are kept free of known vulnerabilities. + +- [x] GitHub Actions are pinned to a commit hash, and the Python packages used by the documentation and the tools are + pinned to exact versions. +- [x] [Dependabot](https://docs.github.com/en/code-security/dependabot) checks these dependencies daily and proposes + updates as pull requests. +- [x] Every pull request is checked with the + [dependency review action](https://github.com/actions/dependency-review-action). A pull request that adds a + dependency with a known vulnerability of any severity fails this check and is not merged. +- [x] Vulnerability alerts for dependencies are fixed or dismissed with a documented reason before the next release. + No release is made while such an alert is open. +- [x] Third-party code included in the repository for testing, such as [doctest](https://github.com/doctest/doctest), + is updated manually. + ## Style check !!! success "Requirement: Common code style" diff --git a/docs/mkdocs/docs/home/design_goals.md b/docs/mkdocs/docs/home/design_goals.md index 0a0f77029..549ba9a1a 100644 --- a/docs/mkdocs/docs/home/design_goals.md +++ b/docs/mkdocs/docs/home/design_goals.md @@ -6,7 +6,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings. -- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289). +- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289). Other aspects were not so important to us: