The installation and masternode pages instruct users to verify the release tarball with
gpg --verify dashcore-23.1.8-x86_64-linux-gnu.tar.gz.asc
Because dashcore-*.tar.gz.asc is a detached signature, the data file has to be passed explicitly:
gpg --verify dashcore-23.1.8-x86_64-linux-gnu.tar.gz.asc dashcore-23.1.8-x86_64-linux-gnu.tar.gz
With the single-argument form, gpg only infers the data file name by stripping .asc. If the .asc served to the user is instead an inline-signed message (any message legitimately signed by a release key, e.g. an old signed announcement), gpg still exits 0 and prints "Good signature"; the only indication is one WARNING: not a detached signature; file '...' was NOT verified! line, which is easy to miss and is dropped by any grep "Good signature" habit. Reproduced locally with gpg 2.4.8: single-argument form on such a file exits 0; the two-argument form exits 2 (Packet type 63 not allowed in detached signature).
The gpg manual (--verify) says: "Note: If the option --batch is not used, gpg may assume that a single argument is a file with a detached signature, and it will try to find a matching data file by stripping certain suffixes. Using this historical feature to verify a detached signature is strongly discouraged; you should always specify the data file explicitly."
Bitcoin Core fixed the same instruction on bitcoincore.org this week (bitcoin-core/bitcoincore.org#1277, merged 2026-09-08), after the report described in https://x.com/n1ckler/status/2097733929851564210.
Occurrences at commit 3aabf11 (8 lines, 6 files):
- docs/user/wallets/dashcore/installation-linux.rst:61, :77
- docs/user/wallets/dashcore/installation-macos.rst:52 (
dashcore-23.1.8-osx.dmg.asc), :69
- docs/user/masternodes/setup.rst:248
- docs/user/masternodes/maintenance.rst:64
- docs/user/mining/p2pool.rst:129
- docs/user/wallets/electrum/installation.rst:26 (
Dash-Electrum-4.1.7.7-x86_64.AppImage.asc)
Suggested change: pass the data file as the second argument in all eight places, and optionally add one sentence telling users to expect "Good signature" without a "NOT verified" warning. (SHA256SUMS.asc on the release page is inline-signed, so it is not affected by this.)
Posted with assistance from Claude (Anthropic).
The installation and masternode pages instruct users to verify the release tarball with
Because
dashcore-*.tar.gz.ascis a detached signature, the data file has to be passed explicitly:With the single-argument form, gpg only infers the data file name by stripping
.asc. If the.ascserved to the user is instead an inline-signed message (any message legitimately signed by a release key, e.g. an old signed announcement), gpg still exits 0 and prints "Good signature"; the only indication is oneWARNING: not a detached signature; file '...' was NOT verified!line, which is easy to miss and is dropped by anygrep "Good signature"habit. Reproduced locally with gpg 2.4.8: single-argument form on such a file exits 0; the two-argument form exits 2 (Packet type 63 not allowed in detached signature).The gpg manual (
--verify) says: "Note: If the option --batch is not used, gpg may assume that a single argument is a file with a detached signature, and it will try to find a matching data file by stripping certain suffixes. Using this historical feature to verify a detached signature is strongly discouraged; you should always specify the data file explicitly."Bitcoin Core fixed the same instruction on bitcoincore.org this week (bitcoin-core/bitcoincore.org#1277, merged 2026-09-08), after the report described in https://x.com/n1ckler/status/2097733929851564210.
Occurrences at commit 3aabf11 (8 lines, 6 files):
dashcore-23.1.8-osx.dmg.asc), :69Dash-Electrum-4.1.7.7-x86_64.AppImage.asc)Suggested change: pass the data file as the second argument in all eight places, and optionally add one sentence telling users to expect "Good signature" without a "NOT verified" warning. (
SHA256SUMS.ascon the release page is inline-signed, so it is not affected by this.)Posted with assistance from Claude (Anthropic).