<!--
    This policy template was created using the HackerOne Policy Builder [1],
    with guidance from the National Telecommunications and Information
    Administration Coordinated Vulnerability Disclosure Template [2].
 -->

# Vulnerability Disclosure Policy (VDP)

## Brand Promise

<!--
    This is your brand promise. Its objective is to "demonstrate a clear, good
    faith commitment to customers and other stakeholders potentially impacted by
    security vulnerabilities" [2].
-->

Keeping user information safe and secure is a top priority, and we welcome the
contribution of external security researchers.

## Scope

<!--
    This is your initial scope. It tells vulnerability finders and reporters
    "which systems and capabilities are 'fair game' versus 'off limits'" [2].
    For software packages, this is often a list of currently maintained versions
    of the package.
-->

If you believe you've found a security issue in software that is maintained in
this repository, we encourage you to notify us.

| Version | In scope | Source code |
| ------- | :------: | ----------- |
| latest  | ✅        | https://github.com/ramsey/collection |

## How to Submit a Report

<!--
    This is your communication process. It tells security researchers how to
    contact you to report a vulnerability. It may be a link to a web form that
    uses HTTPS for secure communication, or it may be an email address.
    Optionally, you may choose to include a PGP public key, so that researchers
    may send you encrypted messages.
-->

To submit a vulnerability report, please contact us at security@ramsey.dev.
Your submission will be reviewed and validated by a member of our team.

## Safe Harbor

<!--
    This section assures vulnerability finders and reporters that they will
    receive good faith responses to their good faith acts. In other words,
    "we will not take legal action if..." [2].
-->

We support safe harbor for security researchers who:

* Make a good faith effort to avoid privacy violations, destruction of data, and
  interruption or degradation of our services.
* Only interact with accounts you own or with explicit permission of the account
  holder. If you do encounter Personally Identifiable Information (PII) contact
  us immediately, do not proceed with access, and immediately purge any local
  information.
* Provide us with a reasonable amount of time to resolve vulnerabilities prior
  to any disclosure to the public or a third party.

We will consider activities conducted consistent with this policy to constitute
"authorized" conduct and will not pursue civil action or initiate a complaint to
law enforcement. We will help to the extent we can if legal action is initiated
by a third party against you.

Please submit a report to us before engaging in conduct that may be inconsistent
with or unaddressed by this policy.

## Preferences

<!--
    The preferences section sets expectations based on priority and submission
    volume, rather than legal objection or restriction [2].

    According to the NTIA [2]:

        This section is a living document that sets expectations for preferences
        and priorities, typically maintained by the support and engineering
        team. This can outline classes of vulnerabilities, reporting style
        (crash dumps, CVSS scoring, proof-of-concept, etc.), tools, etc. Too
        many preferences can set the wrong tone or make reporting findings
        difficult to navigate. This section also sets expectations to the
        researcher community for what types of issues are considered important
        or not.
-->

* Please provide detailed reports with reproducible steps and a clearly defined
  impact.
* Include the version number of the vulnerable package in your report
* Social engineering (e.g. phishing, vishing, smishing) is prohibited.

<!--
    References

    [1] HackerOne. Policy builder. Retrieved from https://hackerone.com/policy-builder/

    [2] NTIA Safety Working Group. 2016. "Early stage" coordinated vulnerability
    disclosure template: Version 1.1. (15 December 2016). Retrieved from
    https://www.ntia.doc.gov/files/ntia/publications/ntia_vuln_disclosure_early_stage_template.pdf
-->

## Encryption Key for security@ramsey.dev

For increased privacy when reporting sensitive issues, you may encrypt your
message using the following public key:

```
-----BEGIN PGP PUBLIC KEY BLOCK-----


nmgawbBHA02D5xEqB5SU3WJu
=eJNx
-----END PGP PUBLIC KEY BLOCK-----
```
