Skip to content

SECURITY.md points to an undeliverable address: security@digibyte.org bounces #450

Description

@BrasaStudios

SECURITY.md directs private disclosure to security@digibyte.org. Mail to that address is rejected, so the project's published security contact currently does not reach anyone.

An attempt on 2026-09-21 returned:

<security@digibyte.org>: host eforward1.registrar-servers.com[162.255.118.51] said:
554 5.1.1 <security@digibyte.org>: Recipient address rejected: undeliverable address:
Mailbox might be disabled, full, or may not exist on the server. Reason: JFE030050
(in reply to RCPT TO command)

The domain's MX records resolve normally (eforward2/3/4/5.registrar-servers.com), so this is the mailbox rather than DNS or a transient failure — the forwarder accepted the connection and then rejected the recipient.

GitHub's private vulnerability reporting is enabled on this repository and does work; we filed a report through it on 2026-09-16. So a working private channel exists, but anyone who follows SECURITY.md will find the one you publish bounces, and may conclude there is no way to reach you privately.

Two suggested fixes in the same file:

  1. Point SECURITY.md at GitHub private vulnerability reporting (Security → Report a vulnerability), or at an address that receives mail.
  2. The PGP key table in SECURITY.md lists Pieter Wuille, Michael Ford and Andrew Chow — Bitcoin Core maintainers, inherited from upstream. Those keys are presumably not the ones you want a DigiByte reporter to encrypt to.

Context: we ran into this while following up on a report filed through private vulnerability reporting. Our public testnet26 Thaw Day exercise report is #449.

Activity

  1. DigiSwarm commented on Oct 2, 2026

    @DigiSwarm

    Thank you for reporting the bounced address and spotting the inherited PGP keys. You are right that the policy on our default branch still needs updating.

    The correction is already included in v9.26.6rc2 and v9.26.6: SECURITY.md now lists security@digibyte.io, links directly to GitHub private vulnerability reporting, and removes the inherited key table. The correction is 041680a2ce. It is included in #452, which still needs to reach develop so the default policy displays the same guidance.

    Thank you also for using the private reporting channel. We will leave this issue open until the default-branch policy is corrected.

  2. BrasaStudios commented on Oct 3, 2026

    @BrasaStudios
    Author

    Thanks again. One more pointer: we have two reports waiting in the private channel (the first since 2026-09-16, the second filed today). Could someone take a look before Thaw Day?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions