# Coordinated Vulnerability Disclosure Policy

This policy describes how MacWinlink handles security vulnerability
reports.  It complements `SECURITY.md` (which tells reporters *how*
to reach us) by describing *what happens next* once a report is
received: how we triage, how we coordinate a fix, how we credit
reporters, and how we publish advisories.

MacWinlink is developed and distributed by the [Amateur Radio Safety
Foundation, Inc. (ARSFI)](https://www.winlink.org/) as part of the
Winlink Global Radio Email service.  This policy applies to the
MacWinlink main app (bundle identifier `org.arsfi.macwinlink`) and
the MacWinlink Helper app (bundle identifier
`org.arsfi.macwinlink-helper`).

## Our commitments

- We treat every good-faith security report as a priority.
- We acknowledge reports quickly, respond substantively within
  weeks not months, and ship fixes on a timeline that matches
  severity.
- We work with reporters, not around them.  You control your name
  and the disclosure narrative.
- We tell users what happened after the fix ships, so operators can
  make informed decisions about their stations.

## Guidance for reporters

If you believe you have found a security vulnerability in MacWinlink
or MacWinlink Helper, please:

- **Report privately first.**  See `SECURITY.md` for the current
  reporting channels.
- **Give us reasonable time to fix it before disclosing publicly.**
  Our default coordination window is 90 days from initial report;
  we will negotiate a different window based on severity, complexity,
  and whether the vulnerability is being actively exploited.
- **Do not exploit the vulnerability beyond what is necessary to
  demonstrate it.**  Testing against your own MacWinlink installation
  or a station under your control is welcome; testing against other
  operators' stations or the Winlink CMS network is not.
- **Do not access, modify, or exfiltrate other users' data or
  messages.**  If your proof-of-concept incidentally exposes such
  data, tell us and delete what you have.
- **Do not disrupt the Winlink network.**  Vulnerabilities that
  affect availability of Winlink CMS servers, RMS relays, or other
  operators' equipment should be reported without demonstration
  against production infrastructure.

Research conducted in good faith in accordance with this policy is
authorized: we will not initiate legal action, we will work with
you to resolve the issue, and we will credit you appropriately.
Research that violates this policy — or that violates applicable
law, or the FCC Part 97 rules governing amateur radio, or the terms
of ARSFI's provision of Winlink services — is not covered by this
authorization.

## Our process

### 1. Acknowledgement (within 7 days)

You will receive a human acknowledgement that your report has been
received, from a person named or identifiable to ARSFI or MacWinlink
maintenance.  If you have not heard back within 7 days, please
resend — email delivery to specialized aliases occasionally fails
silently.

### 2. Triage (within 30 days)

We assign a severity level (Critical, High, Medium, Low) based on
[FIRST CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document)
scoring adapted for MacWinlink's context.  Amateur-radio-specific
scoring considerations:

- **Unauthorized station operation** — any vulnerability that can
  cause a station to transmit without operator authorization is
  treated as Critical regardless of the technical exploit path,
  because unauthorized transmission is an FCC Part 97 violation
  with legal consequences for the licensee.
- **Callsign credential compromise** — Winlink credential exposure
  affects the operator's identity across the entire Winlink
  network and is treated as High or Critical depending on scope.
- **Message confidentiality** — Winlink messages are transmitted in
  plaintext over amateur radio bands and are inherently public in
  transit; vulnerabilities affecting *stored* message
  confidentiality (Keychain leaks, mailbox exfiltration, etc.) are
  treated on their own merits.

We will tell you our severity assessment and confirm we can
reproduce the issue.  If we cannot reproduce, we will ask for
additional detail before dropping the report; we will not close
reports as "cannot reproduce" without dialogue.

### 3. Fix development

Fix timelines target:

- **Critical**: patch under development immediately; out-of-cycle
  release if warranted, coordinated with the reporter.
- **High**: next scheduled release for the affected application
  (main app or Helper, per the two-train release model).
- **Medium**: next scheduled release or the one after, based on
  scope of the fix.
- **Low**: rolled into a future scheduled release; may be
  batched with related quality improvements.

We will keep you informed of progress at reasonable intervals.  If
the fix turns out to be more complex than initially assessed, we
will tell you and revise the timeline together.

### 4. Coordination window

Default: 90 days from initial report to public disclosure.

We may shorten the window if:

- The vulnerability is being actively exploited and public
  disclosure is the safer course.
- The reporter needs a shorter timeline for their own disclosure
  obligations.
- We can ship a fix substantially faster than 90 days.

We may lengthen the window if:

- The fix is genuinely complex (e.g., requires a protocol change
  coordinated with upstream Winlink Development Team).
- The reporter agrees to a longer window in exchange for a more
  complete fix or additional recognition.

We will not extend the window unilaterally without discussing it
with you.

### 5. Release + advisory publication

When the fix ships, we publish a security advisory at
<https://downloads.winlink.org/User%20Programs/MacWinlink/> containing:

- A description of the vulnerability at a level of detail
  appropriate to the severity and the age of the fix.
- Affected versions and the version containing the fix.
- Credit to the reporter (by their preferred name / handle, or
  anonymously if requested).
- A CVE identifier if one has been assigned (see below).

The advisory is dated and appears in the security section's index
so operators can review the full history of advisories issued
against their installed version.

### 6. CVE assignment

If a CVE identifier is warranted for the vulnerability — typically
for Critical or High-severity issues, or for any issue where
downstream vulnerability databases would benefit from a stable
reference — ARSFI will request one from
[MITRE](https://cveform.mitre.org) at the time the advisory is
published.  We do not have a CVE Numbering Authority (CNA)
arrangement of our own; MITRE-issued identifiers are the current
path.

Not every advisory gets a CVE.  Low-severity issues, or issues that
affect only unreleased beta versions and are fixed before the next
public release, may be documented without CVE assignment.

## What we will not do

- We will not sue, prosecute, or otherwise take legal action against
  researchers acting in good faith under this policy.
- We will not publicly identify you as the reporter without your
  consent.
- We will not disclose vulnerability details to third parties before
  the fix ships, except as required by law or by the CRA
  notification requirements described in `SECURITY.md`.
- We will not require a Non-Disclosure Agreement as a precondition
  for accepting a report.
- We will not offer or accept monetary bounty payments.  ARSFI is a
  non-profit foundation and public credit + timely fixes are the
  form of recognition we can offer.

## Multi-vendor coordination

Some vulnerabilities affect components beyond MacWinlink — the
Winlink CMS, RMS Relay software, other Winlink clients, upstream
open-source dependencies like Direwolf or Hamlib, or Apple system
components.  When this happens:

- We may need to loop in the appropriate upstream party (Winlink
  Development Team, upstream project maintainer, Apple).
- We will tell you before we do so, and we will coordinate on
  timing and messaging.
- We will not disclose your identity to those parties without your
  consent.
- We may recommend that you file a parallel report with the
  upstream — this is your choice, not our requirement.

## Applicable regulation

This policy is written to satisfy:

- The **coordinated-disclosure obligations** implied by the EU
  Cyber Resilience Act (Regulation (EU) 2024/2847), particularly
  Article 13 (essential requirements) and Article 14
  (vulnerability handling process).  For vulnerabilities that
  qualify as "actively exploited" or "severe incidents" under
  Article 14, ARSFI issues an early warning to ENISA within 24
  hours, a notification within 72 hours, and a final report within
  14 days.  This is handled internally by ARSFI; reporters do not
  need to notify ENISA themselves.
- **Industry-standard vulnerability handling** as described in
  [ISO/IEC 29147](https://www.iso.org/standard/72311.html)
  (Vulnerability Disclosure) and
  [ISO/IEC 30111](https://www.iso.org/standard/69725.html)
  (Vulnerability Handling Processes).
- **FCC Part 97** rules for amateur radio operations, which govern
  what a MacWinlink user can lawfully transmit and which shape our
  severity assessment for unauthorized-transmission vulnerabilities.

## Changes to this policy

We will publish material changes to this policy at
<https://downloads.winlink.org/User%20Programs/MacWinlink/> and note the
date of change.  Reports submitted before a policy change are
handled under the policy in effect at the time of the report.

**Last revised:** 2026-08-24.