From 00384eaa1a9a59227b1e370c59a6adb9b4d0b4da Mon Sep 17 00:00:00 2001 From: Duncan McClean Date: Fri, 2 Feb 2024 12:01:28 +0000 Subject: [PATCH] Community Health Files (#6) --- .github/FUNDING.yml | 3 --- CONTRIBUTING.md | 32 ------------------------------- SECURITY.md | 46 --------------------------------------------- 3 files changed, 81 deletions(-) delete mode 100644 .github/FUNDING.yml delete mode 100644 CONTRIBUTING.md delete mode 100644 SECURITY.md diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml deleted file mode 100644 index 05864e3..0000000 --- a/.github/FUNDING.yml +++ /dev/null @@ -1,3 +0,0 @@ -# These are supported funding model platforms - -github: statamic diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 69e69f9..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,32 +0,0 @@ -# Contributing - -Contributions are **welcome** and will be fully **credited**. - -We accept contributions via Pull Requests on [Github](https://github.com/statamic-rad-pack/mailchimp). - - -## Pull Requests - -- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - The easiest way to apply the conventions is to install [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer). - -- **Add tests!** - Your patch won't be accepted if it doesn't have tests. - -- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. - -- **Consider our release cycle** - I try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. - -- **Create feature branches** - Don't ask me to pull from your master branch. - -- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. - -- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. - - -## Running Tests - -``` bash -vendor/bin/phpunit -``` - - -**Happy coding**! diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index 64e6713..0000000 --- a/SECURITY.md +++ /dev/null @@ -1,46 +0,0 @@ -If you discover a security vulnerability in Statamic, please review the following guidelines before submitting a report. We take security very seriously, and we do our best to resolve security issues as quickly as possible. - -## Guidelines -While working to identify potential security vulnerabilities in Statamic, we ask that you: - -- **Privately** share any issues that you discover with us via statamic.com/support as soon as possible. -- Give us a reasonable amount of time to address any reported issues before publicizing them. -- Only report issues that are in scope. -- Provide a quality report with precise explanations and concrete attack scenarios. - -## Scope -We are only interested in vulnerabilities that affect Statamic itself, tested against **your own local installation** of the software, running the latest version. You can install a local copy of Statamic by following these [installation instructions](https://statamic.dev/installing). Do not test against any Statamic installation that you don’t own, including [statamic.com](https:/statamic.com) or [statamic.dev](https://statamic.dev). - -### Qualifying Vulnerabilities - -- [Cross-Site Scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) -- [Cross-Site Request Forgery (CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery) -- [Arbitrary Code Execution](https://en.wikipedia.org/wiki/Arbitrary_code_execution) -- [Privilege Escalation](https://en.wikipedia.org/wiki/Privilege_escalation) -- [SQL Injection](https://en.wikipedia.org/wiki/SQL_injection) -- [Session Hijacking](https://en.wikipedia.org/wiki/Session_hijacking) - -### Non-Qualifying Vulnerabilities - -- Reports from automated tools or scanners -- Theoretical attacks without actual proof of exploitability -- Attacks that can be guarded against by following our security recommendations. -- Server configuration issues outside of Statamic’s control -- [Denial of Service](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks -- [Brute force attacks](https://en.wikipedia.org/wiki/Brute-force_attack) (e.g. on password or -- Username or email address enumeration -- Social engineering of Wilderborn staff or users of Statamic installations -- Physical attacks against Statamic installations -- Attacks involving physical access to a user’s device, or involving a device or network that is already seriously compromised (e.g. [man-in-the-middle attacks](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)) -- Attacks that are the result of a 3rd party Statamic addon should be reported to the addon’s author -- Attacks that are the result of a 3rd party library should be reported to the library maintainers -- Bugs that rely on an unlikely user interaction (i.e. the user effectively attacking themselves) -- Disclosure of tools or libraries used by Statamic and/or their versions -- Issues that are the result of a user doing something silly (like sharing their password publicly) -- Missing security headers which do not lead directly to a vulnerability via proof of concept -- Vulnerabilities affecting users of outdated/unsupported browsers or platforms -- Vulnerabilities affecting outdated versions of Statamic -- Any behavior that is clearly documented. -- Issues discovered while scanning a site you don’t own without permission -- Missing CSRF tokens on forms (unless you have a proof of concept, many forms either don't need CSRF or are mitigated in other ways) and "logout" CSRF attacks -- [Open redirects](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)