Dinero Labs · Security

Security policy

How to report vulnerabilities in Dinero (DIN), what's in scope, our response timeline, and what's already verifiable in the current release chain.

How to report a security issue

For sensitive security issues, email security@dinerolabs.org. Include enough detail to reproduce — proof-of-concept, affected version, expected vs observed behavior.

For non-sensitive bugs (no exploitation impact), file a GitHub issue on the dinero-v8 repository instead. Public issues are appropriate for crashes, UI bugs, build failures, and similar.

GitHub's private vulnerability reporting is also available if you prefer a GitHub-native disclosure surface.

PGP / signing key. Dinero Labs does not currently publish a PGP key for encrypted email disclosure. If your report requires encryption, say so in the first message and we will coordinate a key exchange before you send details. A formal release-signing key is on the roadmap (see What's not yet signed).

Response timeline

Phase	Commitment
Acknowledge receipt	Within 7 days
Triage critical issues	Within 14 days
Fix critical issues	No fixed deadline (varies with complexity); reporter kept informed
Coordinated public disclosure	Typically 60–90 days after fix lands; negotiable per case

Dinero Labs is currently a small team. These SLAs are conservative on purpose — we'd rather meet them than promise tighter and miss.

Scope

In scope (please report)

Consensus bugs that allow inflation, double-spend, or unauthorized fork creation
P2P bugs that allow remote denial-of-service, network partition, or eclipse attacks
Wallet bugs that expose private keys, seeds, or enable unauthorized spends
RPC authentication bypass, cookie or session hijack
Install pipeline tampering — anything that would let an attacker substitute the binary served by https://dinerolabs.org/install.sh or the GitHub release assets
macOS notarization / Apple Developer ID signing chain compromise
Cryptographic implementation flaws in consensus or wallet code
Memory corruption, type confusion, or other classes of bug exploitable for code execution

Out of scope

"I lost my password" / wallet recovery requests — user error, not a vulnerability
Denial-of-service via raw connection flooding — the P2P network is inherently exposed; rate limits are a hardening question, not a vulnerability
Bugs in third-party services (block explorers, exchanges, wrapped-DIN bridges) — report to the operator of that service
Theoretical attacks requiring nation-state-level resources — acknowledged but lower priority than practical exploits
Issues already documented in the public issue tracker
Pre-v8 versions (v7, v5, and earlier) — only v8 receives active security maintenance after the v7→v8 chain restart

What's signed today

This is the trust chain Dinero Labs actively maintains right now. Operators can verify these properties on their own machines without trusting Dinero Labs's word.

macOS

Apple Developer ID signing + Apple notarization, live since v2.1.22 (April 2026).

Signing identity: Mirsad Hajdarevic (Team ID JXJS6ZA5FJ)
Notarization: stapled to every released .dmg and .app bundle

Verify locally:

codesign --verify --deep --strict /Applications/Dinero.app
spctl -a -t exec -vv /Applications/Dinero.app

The spctl output should show source=Notarized Developer ID.

Linux .deb, standalone tarballs, Windows installers

Every release asset on GitHub has a SHA256 digest published by GitHub itself and exposed via the GitHub API (assets[].digest field). This is the property that install.sh verifies before installation, so any operator running the install script gets hash verification automatically.

Manual verification:

EXPECTED=$(gh api repos/DineroLabs/dinero-v8/releases/tags/v8.0.0-rc37 \
  --jq '.assets[] | select(.name | test("amd64.deb$")) | .digest')
echo "$EXPECTED"

sha256sum dinero-core_8.0.0~rc37-1_amd64.deb
# compare; should match the hex after sha256:

What's not yet signed

Honest disclosure of current gaps — these affect what an operator can verify today:

Windows Authenticode signature on the .exe installer — open item, planned. Until shipped, Windows users see SmartScreen warnings; verification falls back to the GitHub SHA256 digest above.
GPG / minisign signature on the Linux .deb directly — open item, planned. Today's integrity guarantee for Linux comes from GitHub's per-asset SHA256, which protects against transit corruption and asset-level substitution on GitHub, but not against a compromise of GitHub itself or the DineroLabs publishing account.
Detached GPG / minisign signature for SHA256SUMS — open item. Current releases publish checksum files for macOS and Linux assets, but the checksum files themselves are not yet signed independently of GitHub.
Reproducible builds — the new depends/ system (added 2026-05-16) is the foundation. Multi-builder bit-identical verification is future work.

When each gap closes, this page updates. The current state is documented honestly so operators can make their own trust tradeoffs.

Credit

We publicly credit security reporters by default — name, handle, or alias of your choice — unless you ask to remain anonymous. There is no monetary bug bounty at this time.

Hall of fame

None yet. We'd be honored to list you here.

Quick reference

Security email	`security@dinerolabs.org`
GitHub private vulnerability reporting	dinero-v8 advisories
RFC 9116 security.txt	`/.well-known/security.txt`
SECURITY.md (GitHub-rendered)	dinero-v8/security/policy