# Security Policy

## Reporting a Vulnerability

At GNU Wget2, we take security seriously and appreciate the efforts of security
researchers in identifying and disclosing vulnerabilities responsibly. If you
believe you've discovered a security vulnerability in GNU Wget2, we encourage you
to disclose it to us as confidential issues and work with us to ensure it is addressed
promptly and appropriately.

To report vulnerabilities, open confidential issues at
https://gitlab.com/gnuwget/wget2/issues .

In case, it can't be avoided to send an email: The names and contact details of the
current maintainers is always available via the AUTHORS file in this repository. In
order to send an encrypted email, please use the keyring available at the following URL:
https://savannah.gnu.org/project/release-gpgkeys.php?group=wget

Please include the following information in your report:

- A detailed description of the vulnerability
- The version(s) of GNU Wget2 that are affected.
- Steps to reproduce the vulnerability.
- Any proof-of-concept or exploit code, if applicable.
- Your contact information for coordination and follow-up.

Once we receive your report, we will acknowledge receipt and work with you to
investigate the issue. We work on GNU Wget2 on a volunteer basis and as such may
face delays in responding immediately. We aim to respond to initial reports
within 5 working days and will keep you informed of our progress throughout the
resolution process.

Please refrain from disclosing the vulnerability publicly until we have had an
opportunity to investigate and address it. We appreciate your cooperation in
helping to keep GNU Wget2 and its users secure.

## Vulnerability Disclosure Policy

Once a security vulnerability has been identified and confirmed, we will take
the following steps:

1. **Investigation**: We will promptly investigate the reported vulnerability to
   verify its authenticity and determine its scope and impact.

2. **Resolution**: Once validated, we will develop and test a fix for the
   vulnerability. We will strive to address the issue as quickly as possible and
   prepare a patch for release.

3. **Coordination**: We will work with the reporter to ensure that the
   vulnerability is disclosed responsibly and coordinated with the release of
   the fix.

4. **Release**: Upon completion of the fix and any necessary testing, we will
   release a new version of GNU Wget2 that addresses the vulnerability. We will
   provide appropriate credit to the reporter in the release notes, unless
   otherwise requested.

5. **Public Disclosure**: We will coordinate the public disclosure of the
   vulnerability with the reporter and other relevant stakeholders. Once the fix
   is widely available, we will publish an advisory detailing the vulnerability
   and its resolution.

We strive to follow these steps in a timely and transparent manner, while
prioritizing the security and stability of GNU Wget2 and its users.

## Responsible Disclosure Guidelines

In order to protect our users and systems, we ask that security researchers
adhere to the following guidelines when reporting vulnerabilities to GNU Wget2:

- **Responsible Disclosure**: Please disclose vulnerabilities to us privately
  and allow us a reasonable amount of time to investigate and address them
  before disclosing them publicly.

- **Cooperation**: We appreciate your cooperation and collaboration throughout
  the disclosure process. We will do our best to keep you informed of our
  progress and coordinate the release of information with you.

- **Respect**: Please respect our users' privacy and refrain from any actions
  that could cause harm or disrupt our systems. We ask that you do not exploit
  or disclose vulnerabilities before they have been resolved.

By following these guidelines, you can help us maintain the security and
integrity of GNU Wget2 for the benefit of all users. We thank you for your
contributions to our project and for helping to make the internet a safer place.

## LLM-Generated Security Reports

With the rise of AI-assisted vulnerability research, we receive an increasing
number of reports generated by Large Language Models (LLMs). While we appreciate
all security contributions, please note:

### Commodity Findings

Findings that can be trivially generated by anyone using public LLMs without
deep domain knowledge (e.g., generic "potential buffer overflow" patterns,
standard CWE listings without project-specific context, or automated SAST-style
output) are **not treated as confidential**. These may be disclosed or discussed
publicly at any time by the project maintainers.

### Quality Expectations

For LLM-assisted reports to receive confidential handling and coordinated
disclosure:

- The report must demonstrate **project-specific understanding** (code paths,
  configuration, threat model)
- Include **verified reproduction steps** on a supported version
- Show **impact analysis** beyond generic CWE descriptions
- False positives and unverified theoretical issues will be closed without
  coordinated disclosure

### Reporting Channel

LLM-generated reports should still be submitted via our confidential issue
tracker, but maintainers reserve the right to reclassify commodity findings as
non-confidential immediately upon triage.
