Fixes verification badge text appearing in search engine title tags when Yoast SEO or other SEO plugins are active. Recommended for all users. No configuration changes required.<\/p>","1.19.0":"
Fixes custom markdown files returning 404 ( Fixes a version mismatch where the plugin header and MDSM_VERSION constant were not updated from 1.16.0. No functional changes; no configuration changes required.<\/p>","1.17.0":" Adds DANE \/ DNS Key Corroboration. Flush permalinks after upgrading to activate Adds RSA, CMS\/PKCS#7, and JSON-LD\/W3C Data Integrity signing methods. All opt-in, disabled by default. Flush permalinks after upgrading to activate Adds ECDSA P-256 signing (Enterprise \/ Compliance Mode). Opt-in, disabled by default. Flush permalinks after upgrading to activate Security hardening for Canary Tokens: SSRF fix, rate limiter bypass fix, evidence receipt integrity fix, ReDoS fix, and removal of This post was hashed and signed automatically on publish by ArchivioMD.<\\\/p>\\n The SHA-256 hash below is a deterministic fingerprint of this content. If even a single character were changed after publishing, the hash would no longer match and the verification badge would display \\\\u2717 Unverified.<\\\/p>\\n Navigate to Meta Docs & SEO<\\\/strong> in the sidebar to manage compliance documents, or visit Tools → ArchivioMD<\\\/strong> to run compliance exports and view the audit log.<\\\/p>\\n You can also enable Ed25519 document signing, RFC 3161 trusted timestamps, Sigstore\\\/Rekor transparency log anchoring, DANE\\\/DNS key corroboration, and steganographic Canary Token fingerprinting from the plugin settings.<\\\/p>',\\n 'post_status' => 'publish',\\n 'post_author' => 1,\\n]);\\n\\n\\\/\\\/ Create a demo page\\nwp_insert_post([\\n 'post_title' => 'About This Demo',\\n 'post_content' => ' This is a live WordPress Playground running ArchivioMD. Everything here is temporary and isolated to your browser session.<\\\/p>\\n ArchivioMD gives WordPress sites a cryptographic proof layer. Every post, page, and document gets a verifiable integrity record \u2014 independently checkable without trusting the platform, the host, or the database.<\/p>\n\n Built for journalists, compliance teams, legal publishers, and anyone for whom the question \"was this changed after it was published?\" has a real answer.<\/p>\n\n Every post and page is hashed deterministically on publish and update. A verification badge (\u2713 Verified \/ \u2717 Unverified \/ \u2212 Not Signed) appears on every post. Verification files are downloadable for offline confirmation. Shortcode: Supported algorithms include SHA-256\/384\/512 family, SHA-3, BLAKE2b\/2s, BLAKE3, SHAKE, RIPEMD-160, Whirlpool, and GOST variants.<\/p>\n\n HMAC Integrity Mode<\/strong> adds a shared-secret layer on top of hashing. The key lives in All signing methods sign the same canonical message and run independently. Any combination can be active simultaneously.<\/p>\n\n Ed25519<\/strong> (recommended for most sites) \u2014 uses PHP sodium ( SLH-DSA \/ SPHINCS+ (post-quantum)<\/strong> \u2014 pure-PHP implementation of NIST FIPS 205. No extensions, no Composer dependencies; works on any shared host running PHP 7.4+. Security rests on SHA-256 alone \u2014 not on factoring or discrete logarithms. Four parameter sets: SLH-DSA-SHA2-128s (default, 7,856-byte signatures), -128f (faster, 17,088 bytes), -192s, -256s. Signing takes 200\u2013600 ms on shared hosting per publish event \u2014 front-end rendering is not affected. Running Ed25519 and SLH-DSA together (hybrid mode) provides both classical and quantum verifiability from a single DSSE envelope.<\/p>\n\n ECDSA P-256<\/strong> \u26a0\ufe0f Enterprise\/compliance mode only. Enable when an external framework (eIDAS, SOC 2, HIPAA, government PKI) explicitly requires X.509 certificate-backed ECDSA. For all other sites, Ed25519 is recommended. Nonce generation is 100% delegated to OpenSSL.<\/p>\n\n RSA<\/strong> \u26a0\ufe0f Legacy compatibility only. Enable when a downstream system cannot accept Ed25519, ECDSA, or SLH-DSA keys.<\/p>\n\n CMS \/ PKCS#7<\/strong> \u2014 Detached DER signatures importable into Adobe Acrobat, Windows Explorer, and enterprise DMS platforms. Reuses your ECDSA or RSA key.<\/p>\n\n JSON-LD \/ W3C Data Integrity<\/strong> \u2014 Produces All private keys are stored in Publishes every active signing key as a DNSSEC-protected DNS TXT record, giving verifiers a trust path entirely independent of your web server and TLS certificate. An attacker must compromise both your web host and your DNS zone simultaneously to forge a key.<\/p>\n\n Records use the When ECDSA P-256 is configured, an optional TLSA record (RFC 6698, DANE-EE, Selector=1) binds the leaf certificate to your HTTPS service. A machine-readable discovery endpoint at Weekly passive health checks via wp-cron surface failures as dismissible admin notices. Key rotation mode suppresses false-positive mismatch warnings during DNS TTL expiry. Full WP-CLI support: DNSSEC is required for DANE to provide actual security. Most registrars offer it with a single toggle.<\/p>\n\n RFC 3161 Trusted Timestamps<\/strong> \u2014 Sends content hashes to a Time Stamp Authority on every anchor job. The signed Sigstore \/ Rekor Transparency Log<\/strong> \u2014 Submits a Git Repository Anchoring<\/strong> \u2014 Commits integrity records to GitHub or GitLab (public, private, or self-hosted) on every anchor job, creating an independent audit trail in commit history.<\/p>\n\n All three anchoring methods can run simultaneously on every job.<\/p>\n\n Browser-based editing (no FTP) for Markdown meta-documentation (security.txt, privacy policy, terms of service, etc.) and SEO\/compliance files: robots.txt, llms.txt, ads.txt, app-ads.txt, sellers.json, ai.txt. Documents get automatic UUID assignment, SHA-256 checksum tracking, and an append-only changelog. Standard and comprehensive XML sitemaps included.<\/p>\n\n Metadata CSV, Compliance JSON, and Backup ZIP exports each generate a companion Manual checksum verification (read-only; does not modify anything). Backup & Restore with mandatory dry-run before any restore operation.<\/p>\n\n WP-CLI: Entirely opt-in. Nothing is injected unless you explicitly enable it.<\/strong><\/p>\n\n Embeds an invisible, HMAC-authenticated fingerprint (post ID + timestamp + 48-bit MAC) into published content at render time \u2014 stored content is never modified. Fingerprints survive copy-paste and can identify the source of scraped content. A built-in decoder and DMCA Notice Generator are included. Signed evidence packages ( Encoding operates across up to 14 channels in three layers:<\/p>\n\n Unicode layer<\/em> (survives copy-paste; stripped by OCR): zero-width characters, thin-space variants, apostrophe variants, soft hyphens.<\/p>\n\n Semantic layer<\/em> (survives OCR and Unicode normalisation; each opt-in): contraction encoding, synonym substitution, punctuation choice, spelling variants, hyphenation choices, number\/date style, punctuation style II, citation\/title style.<\/p>\n\n Structural layer<\/em> (CDN-proof): sentence-count parity, word-count parity.<\/p>\n\n Each bit is encoded three times per active channel with majority-vote redundancy. A cache compatibility layer ensures fingerprints survive HTML minification by WP Super Cache, W3 Total Cache, LiteSpeed Cache, WP Rocket, and similar plugins. The Canary Coverage meta box on the post edit screen shows per-channel slot availability before you publish.<\/p>\n\n All metadata is stored in the WordPress database. Regular database backups are required. All verification, export, and backup operations are admin-triggered and read-only \u2014 the plugin does not prevent or block modifications. Markdown and SEO files are stored in Flush Permalinks<\/strong> \u2014 Settings \u2192 Permalinks \u2192 Save Changes. Required for all Create your first document<\/strong> \u2014 Go to Meta Docs & SEO, pick a predefined file (e.g. security.txt.md), enter content, save. UUID and first changelog entry are created automatically.<\/p><\/li>\n Enable content hashing<\/strong> \u2014 Go to Cryptographic Verification \u2192 Settings, choose a hash algorithm (SHA-256 default), save. New and updated posts are hashed automatically from that point.<\/p><\/li>\n Configure Ed25519 signing<\/strong> (optional) \u2014 Use the in-browser keypair generator, add both constants to Configure SLH-DSA<\/strong> (optional) \u2014 Navigate to Cryptographic Verification \u2192 Settings \u2192 SLH-DSA. Select a parameter set, generate a keypair server-side, add the three constants to Enable Rekor \/ RFC 3161 \/ Git anchoring<\/strong> (optional) \u2014 Each is configured independently under the ArchivioMD Tools menu. All three can run simultaneously on every anchor job.<\/p><\/li>\n Configure DANE<\/strong> (optional) \u2014 Requires at least one signing key. Publish the DNS TXT records shown in the admin panel, enable DNSSEC on your zone, then enable DANE Corroboration and run the health check.<\/p><\/li>\n<\/ol>\n\n\n After activation you will see Meta Docs & SEO<\/strong> in the admin sidebar and ArchivioMD<\/strong> under the Tools menu.<\/p>\n\n\n Markdown and SEO files are stored in Yes. All metadata is stored in the database. The plugin's Backup & Restore tool provides portable archives, but standard database backups are still required.<\/p><\/dd>\n All files remain in the uploads directory. Database options are only deleted if you explicitly enable metadata cleanup before uninstalling.<\/p><\/dd>\n No. It tracks integrity and provides manual verification tools. Verification is admin-triggered and read-only \u2014 it does not prevent or block modifications.<\/p><\/dd>\n Yes. All signing methods are independently verifiable with standard tooling \u2014 no WordPress dependency required.<\/p>\n\n Only when an external compliance framework explicitly requires X.509 certificate-backed ECDSA \u2014 for example, eIDAS qualified signatures, certain government PKI mandates, SOC 2 audit requirements specifying certificate-bound signatures, or HIPAA requirements from a specific assessor. For all other sites, Ed25519 is recommended: simpler to configure, no certificate expiry to manage, and equally secure.<\/p><\/dd>\n Use RSA<\/strong> only when a downstream system cannot accept Ed25519, ECDSA, or SLH-DSA keys \u2014 for example, older HSMs or legacy enterprise toolchains hardcoded to RSA. Use CMS\/PKCS#7<\/strong> when a DMS, Adobe Acrobat workflow, or regulated-industry audit tool specifically requires SLH-DSA (SPHINCS+) builds a Merkle tree of hundreds of hash computations per signature. Because this implementation is pure PHP rather than a native C extension, expect 200\u2013600 ms on shared hosting for the default SHA2-128s parameter set. To reduce it, switch to SHA2-128f \u2014 same NIST Category 1 security, 5\u201310\u00d7 faster signing, larger signatures. This overhead occurs once per publish event and has no effect on front-end page rendering.<\/p><\/dd>\n Yes, if you need verifiability today and quantum resilience for the future. In hybrid mode the DSSE envelope carries both signatures. Existing verifiers that only understand Ed25519 continue to work unchanged.<\/p><\/dd>\n No. The public good instance (rekor.sigstore.dev) is a free, unauthenticated API operated by the Linux Foundation's Sigstore project.<\/p><\/dd>\n Yes. Without DNSSEC, DNS responses are unauthenticated and the TXT records provide no additional trust over the web server alone. Most registrars now offer DNSSEC with a single toggle.<\/p><\/dd>\n The plugin does not collect, store, or process personal data from visitors. It stores administrative metadata associated with WordPress user accounts. Compliance with GDPR depends on how you use the plugin \u2014 consult your legal team.<\/p><\/dd>\n No. All features require the .well-known\/meta-docs\/<\/code> routing), unreliable rewrite flush after AJAX file creation, and REST endpoint security hardening. Recommended for all users. No configuration changes required.<\/p>","1.17.4":"\/.well-known\/archiviomd-dns.json<\/code>.<\/p>","1.16.0":"\/.well-known\/did.json<\/code> and \/.well-known\/rsa-pubkey.pem<\/code>.<\/p>","1.15.0":"\/.well-known\/ecdsa-cert.pem<\/code>.<\/p>","1.13.1":"sslverify => false<\/code>. Upgrade recommended for all sites using Canary Tokens.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3466506,"resolution":"128x128","location":"assets","locale":""},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3466506,"resolution":"256x256","location":"assets","locale":""},"icon-32x32.png":{"filename":"icon-32x32.png","revision":3466506,"resolution":"32x32","location":"assets","locale":""},"icon-64x64.png":{"filename":"icon-64x64.png","revision":3466506,"resolution":"64x64","location":"assets","locale":""}},"assets_banners":{"banner-1600x800.png":{"filename":"banner-1600x800.png","revision":3466506,"resolution":"1600x800","location":"assets","locale":""}},"assets_blueprints":{"blueprint.json":{"filename":"blueprint.json","revision":3485897,"resolution":false,"location":"assets","locale":"","contents":"{\"$schema\":\"https:\\\/\\\/playground.wordpress.net\\\/blueprint-schema.json\",\"meta\":{\"title\":\"ArchivioMD \\u2014 Cryptographic Content Integrity\",\"description\":\"Live preview of ArchivioMD: content hashing, Ed25519 document signing, RFC 3161 timestamps, Canary Token fingerprinting, and compliance exports for WordPress.\",\"author\":\"mountainviewprovisions\",\"categories\":[\"security\",\"compliance\",\"cryptography\"]},\"landingPage\":\"\\\/wp-admin\\\/admin.php?page=archiviomd-verification\",\"preferredVersions\":{\"php\":\"8.2\",\"wp\":\"latest\"},\"features\":{\"networking\":true},\"login\":true,\"siteOptions\":{\"blogname\":\"ArchivioMD Demo Site\",\"blogdescription\":\"Cryptographic content integrity for WordPress\"},\"plugins\":[\"archiviomd\"],\"steps\":[{\"step\":\"login\",\"username\":\"admin\",\"password\":\"password\"},{\"step\":\"installPlugin\",\"options\":{\"activate\":true},\"pluginData\":{\"resource\":\"wordpress.org\\\/plugins\",\"slug\":\"archiviomd\"}},{\"step\":\"setSiteOptions\",\"options\":{\"blogname\":\"ArchivioMD Demo Site\",\"blogdescription\":\"Cryptographic content integrity for WordPress\",\"permalink_structure\":\"\\\/%postname%\\\/\"}},{\"step\":\"runPHP\",\"code\":\" 'Demo: Cryptographic Integrity in Action',\\n 'post_content' => 'What to explore<\\\/h2>\\n
\\n
Content Hashing<\/h4>\n\n
[hash_verify]<\/code>.<\/p>\n\nwp-config.php<\/code> \u2014 never the database \u2014 so an adversary with database access alone cannot silently update a hash.<\/p>\n\ndefine('ARCHIVIOMD_HMAC_KEY', 'your-secret-key');\n<\/code><\/pre>\n\nDocument Signing<\/h4>\n\n
ext-sodium<\/code>). Private key in wp-config.php<\/code>; public key published at \/.well-known\/ed25519-pubkey.txt<\/code>. In-browser keypair generator included. Supports DSSE envelope mode (Sigstore spec) with PAE binding to prevent cross-protocol replay.<\/p>\n\neddsa-rdfc-2022<\/code> and ecdsa-rdfc-2019<\/code> proof blocks per post and publishes a did:web<\/code> DID document at \/.well-known\/did.json<\/code>. Compatible with ActivityPub, W3C Verifiable Credentials, and decentralised identity wallets.<\/p>\n\nwp-config.php<\/code> \u2014 never in the database. PEM files uploaded via the admin UI are stored outside DOCUMENT_ROOT<\/code>, chmod 0600, with an .htaccess<\/code> Deny guard.<\/p>\n\nDANE \/ DNS Key Corroboration<\/h4>\n\n
amd1<\/code> tag-value format (modelled on DKIM):<\/p>\n\n_archiviomd._domainkey.example.com. IN TXT \"v=amd1; k=ed25519; p=<base64-pubkey>\"\n<\/code><\/pre>\n\n\/.well-known\/archiviomd-dns.json<\/code> lists all active records and expected values. A self-describing format specification is served at \/.well-known\/archiviomd-dns-spec.json<\/code> regardless of whether DANE is enabled.<\/p>\n\nwp archiviomd dane-check<\/code>.<\/p>\n\nExternal Anchoring<\/h4>\n\n
.tsr<\/code> token binds the hash to a specific time and is independently verifiable offline with OpenSSL. Built-in providers: FreeTSA.org, DigiCert, GlobalSign, Sectigo. Custom endpoint supported.<\/p>\n\nhashedrekord<\/code> entry to the public Rekor append-only log (rekor.sigstore.dev) on every anchor job. Entries are immutable and publicly verifiable without an account or API key. When Ed25519 keys are configured, entries are signed with the site key; otherwise an ephemeral keypair is generated automatically.<\/p>\n\nDocument Management<\/h4>\n\n
Compliance & Audit Tools<\/h4>\n\n
.sig.json<\/code> integrity receipt (SHA-256 hash + optional cryptographic signature). The Compliance JSON export preserves full relationships between posts, hash history, anchor log entries, and RFC 3161 TSR manifests \u2014 suitable for legal evidence packages and SIEM ingestion.<\/p>\n\nwp archiviomd process-queue<\/code>, anchor-post <id><\/code>, verify <id><\/code>, prune-log<\/code>.<\/p>\n\nCanary Tokens (Steganographic Fingerprinting)<\/h4>\n\n
.sig.json<\/code>) can be generated after a successful decode for use in legal proceedings.<\/p>\n\nIdeal For<\/h4>\n\n
\n
Important Notes<\/h4>\n\n
uploads\/meta-docs\/<\/code> and are preserved on uninstall.<\/p>\n\nGetting Started<\/h3>\n\n
\n
.well-known\/<\/code> endpoints.<\/p><\/li>\nwp-config.php<\/code>, enable signing. Posts, pages, and media are signed automatically on save.<\/p><\/li>\nwp-config.php<\/code>, enable. Can run alongside Ed25519 (hybrid mode) or standalone.<\/p><\/li>\nAutomatic Installation<\/h4>\n\n
\n
.well-known\/<\/code> file serving)<\/li>\n<\/ol>\n\nManual Installation<\/h4>\n\n
\n
\n
Where are my files stored?<\/h3><\/dt>\n
uploads\/meta-docs\/<\/code>. Metadata (UUIDs, checksums, changelogs) is stored in wp_options<\/code> with the prefix mdsm_doc_meta_<\/code>.<\/p><\/dd>\nDo I need to back up the database?<\/h3><\/dt>\n
What happens if I uninstall the plugin?<\/h3><\/dt>\n
Does this plugin enforce file integrity?<\/h3><\/dt>\n
Can I verify signatures without WordPress?<\/h3><\/dt>\n
\n
\/.well-known\/ed25519-pubkey.txt<\/code> and verify with any sodium-compatible tool.<\/li>\n\/.well-known\/slhdsa-pubkey.txt<\/code> and verify with any FIPS 205-compatible library (e.g. pyspx).<\/li>\n\/.well-known\/ecdsa-cert.pem<\/code> and verify with OpenSSL or the Python cryptography<\/code> library.<\/li>\n\/.well-known\/rsa-pubkey.pem<\/code> and verify with OpenSSL.<\/li>\n\/.well-known\/did.json<\/code> and verify with @digitalbazaar\/jsonld-signatures<\/code> (JS) or pyld<\/code> + cryptography<\/code> (Python).<\/li>\n.tsr<\/code> and .tsq<\/code> files from the compliance tools page and run openssl ts -verify -in response.tsr -queryfile request.tsq -CAfile tsa.crt<\/code>.<\/li>\nrekor-cli verify --artifact-hash sha256:<HASH> --log-index <INDEX><\/code> or look up the entry at https:\/\/search.sigstore.dev\/?logIndex=<INDEX><\/code>.<\/li>\n<\/ul><\/dd>\nWhen should I use ECDSA P-256 instead of Ed25519?<\/h3><\/dt>\n
When should I use the extended signing formats (RSA, CMS, JSON-LD)?<\/h3><\/dt>\n
.p7s<\/code> format. Use JSON-LD \/ W3C Data Integrity<\/strong> when building interoperability with ActivityPub implementations, W3C Verifiable Credential ecosystems, or decentralised identity wallets. For general integrity verification, Ed25519 covers all common use cases with far less operational overhead.<\/p><\/dd>\nWhy is SLH-DSA signing slow?<\/h3><\/dt>\n
Should I run Ed25519 and SLH-DSA together?<\/h3><\/dt>\n
Does Rekor require an API key?<\/h3><\/dt>\n
Does DANE Corroboration require DNSSEC?<\/h3><\/dt>\n
Is this plugin GDPR compliant?<\/h3><\/dt>\n
Can non-admin users access these features?<\/h3><\/dt>\n
manage_options<\/code> capability (administrator role).<\/p><\/dd>\n\n<\/dl>\n\n\n1.19.2<\/h4>\n\n
\n
1.19.1<\/h4>\n\n
\n
get_the_title()<\/code> while building the <title><\/code> tag before wp_head<\/code> completes; the badge HTML was being appended, stripped of its tags, and indexed as part of the post title. Badge now only injects after wp_head<\/code> has fired, ensuring it renders in the page body only and is never seen by search engines.<\/li>\n<\/ul>\n\n1.19.0<\/h4>\n\n
\n
\/.well-known\/meta-docs\/<\/code> path, which is where the file manager stores custom files by default. Previously only the root-level route was registered, so any request to the .well-known<\/code> path fell through to a 404.<\/li>\nflush_rewrite_rules()<\/code> called inside an AJAX handler does not always persist reliably; the fix schedules a guaranteed follow-up flush on the next real page load via a transient flag.<\/li>\n\/wp-json\/archivio-id\/v1\/posts\/{id}\/signatures<\/code>), retrieves all PGP signature records, fetches public keys from keys.openpgp.org<\/code> by fingerprint, and performs client-side cryptographic verification using OpenPGP.js (Ed25519, RSA, ECDSA supported). Results are surfaced as Step 8 in the full verification report.<\/li>\nCache-Control<\/code> on \/verify<\/code> from public<\/code> to private<\/code> to prevent shared-proxy caching of verification status, and reduced \/status<\/code> cache TTL to prevent stale feature-flag disclosure.<\/li>\n<\/ul>\n\n1.17.4<\/h4>\n\n
\n
Version<\/code> and MDSM_VERSION<\/code> constant were stuck at 1.16.0 across the 1.17.x release series. Both now correctly read 1.17.4 and match the readme Stable tag<\/code>.<\/li>\n<\/ul>\n\n1.17.3<\/h4>\n\n
\n
\/.well-known\/archiviomd-dns-spec.json<\/code> \u2014 a machine-readable, self-contained specification for the amd1<\/code> TXT record format, the TLSA profile, the canonical message format, and the end-to-end verification flow.<\/li>\narchiviomd-dns.json<\/code> now includes a spec_url<\/code> field pointing to the spec endpoint.<\/li>\n<\/ul>\n\n1.17.2<\/h4>\n\n
\n
ARCHIVIOMD_DANE_TTL<\/code> constant; TTL now configurable and used consistently across rotation threshold, admin UI, and Cache-Control<\/code> headers.<\/li>\nIf-None-Match<\/code> \/ 304 conditional response support to the discovery endpoint.<\/li>\n{\"enabled\":false}<\/code> so verifiers can distinguish module-off from a wrong URL.<\/li>\n1.17.1<\/h4>\n\n
\n