=== VulnLine ===
Contributors: jbsabit
Donate link: https://jbsabit.com/
Tags: security.txt, security.txt generator, rfc 9116, vulnerability disclosure, security contact
Requires at least: 5.5
Tested up to: 7.1
Stable tag: 1.1.3
Requires PHP: 7.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Security.txt generator for WordPress: add a valid RFC 9116 security.txt at /.well-known/security.txt so researchers can report bugs to you.

== Description ==

**When a security researcher finds a vulnerability in your site, how do they reach you?**

Most WordPress sites have no answer — so reports go to Twitter, get ignored, or never happen. **VulnLine is a security.txt generator for WordPress**: it creates and serves a valid `security.txt` file (RFC 9116, the internet standard for publishing security contact information) at `/.well-known/security.txt`, exactly where security researchers and bug bounty hunters look first.

**In short:** install VulnLine, and your WordPress site publishes a standard security contact file at `https://yoursite.com/.well-known/security.txt` — with your contact details, an expiry date, and your vulnerability disclosure policy — valid the moment you activate it, with zero configuration.

**What is a security.txt file?**

A security.txt file is a small plain-text file that tells anyone who finds a security problem on your website how to report it to you responsibly. It is defined by the IETF in RFC 9116 (published 2022) and lives at one fixed address: `/.well-known/security.txt`, served over HTTPS as `text/plain`. Think of it as robots.txt for security researchers: a machine-readable signpost that says "found a vulnerability? Here is how to tell us."

**What you get**

* A valid `security.txt` served automatically at `/.well-known/security.txt` with the correct `text/plain` content type — no file editing, no FTP, no server config
* **Zero-config start** — on activation VulnLine fills in ready-to-use defaults (your site admin email as the Contact, an Expires date one year ahead, your site language), so your file is valid and live immediately
* **Contact** (required) — one or more contact URIs: `mailto:`, `https://`, `tel:`
* **Expires** (required) — always a future date, with a dashboard warning before your file lapses
* Every optional RFC 9116 field: **Encryption** (PGP key link), **Acknowledgments**, **Preferred-Languages**, **Policy** (your vulnerability disclosure policy page), **Hiring**, **Canonical**
* **Live preview** — a syntax-highlighted preview with one-click copy; see exactly what researchers will see before you save
* **Built-in RFC 9116 validation** — catches bad contact URIs, past Expires dates and malformed fields, with clear error messages
* **Admin reminder** — a dashboard notice if your security.txt is missing or invalid, so it never silently rots

**What a valid security.txt looks like**

Contact: mailto:security@example.com
Expires: 2027-11-10T23:59:59Z
Preferred-Languages: en
Policy: https://example.com/security-policy
Canonical: https://example.com/.well-known/security.txt

Only `Contact` and `Expires` are required by RFC 9116. VulnLine generates this file for you, keeps the format correct, and updates it the moment you save your settings.

**Why your WordPress site needs a security.txt**

* Google, Facebook, the US CISA and thousands of bug-bounty programs publish a security.txt — it is the expected standard for responsible disclosure
* Security researchers, ethical hackers and vulnerability scanners (including internet.nl-style compliance checks) look for `/.well-known/security.txt` first; without one, many simply move on — or disclose publicly
* The EU Cyber Resilience Act pushes vendors toward coordinated vulnerability disclosure; a security.txt is the simplest way to publish yours
* A reachable security contact turns a potential public incident into a quiet, responsible report

**Why a plugin instead of uploading the file by hand?**

You can create a `.well-known` folder and upload a text file by FTP — if you have filesystem access and get every detail right. In practice, hand-made files break silently: the folder is lost in a site migration, the file is served as `text/html` instead of `text/plain`, the Expires date passes unnoticed, or the file is edited into an invalid format. VulnLine serves security.txt dynamically through WordPress, validates it against RFC 9116 every time you save, and warns you in the dashboard if anything is wrong — including an Expires date that is about to lapse.

**Privacy**

This plugin collects nothing, phones home nowhere, and adds zero front-end weight — it only serves one tiny text file when requested.

Built by WordPress security specialist Md Jahid Bin Sabit — [jbsabit.com](https://jbsabit.com/)

== Installation ==

1. Upload the plugin files to `/wp-content/plugins/vulnline/`, or install through the WordPress plugins screen.
2. Activate the plugin — your security.txt is already valid and live with sensible defaults.
3. Go to **Settings → VulnLine** to review or change your contact info.
4. Visit `yoursite.com/.well-known/security.txt` to see it live.

== Frequently Asked Questions ==

= What is a security.txt file? =
A security.txt file is a plain-text file, defined by RFC 9116, that tells security researchers how to report a vulnerability in your website. It is published at `/.well-known/security.txt` and must contain at least a `Contact` field (where to send reports) and an `Expires` field (when the information goes stale).

= Where does security.txt go on a WordPress site? =
At `https://yoursite.com/.well-known/security.txt` — that is the only location RFC 9116 requires, served over HTTPS with the content type `text/plain`. VulnLine serves it at exactly that address automatically; you do not create folders or upload files.

= Does WordPress create a security.txt file automatically? =
No. WordPress core does not generate a security.txt file, and most hosts do not add one either. Without a plugin or a manually uploaded file, `/.well-known/security.txt` on a WordPress site returns a 404 — which is the gap VulnLine fills.

= How do I add security.txt to WordPress without FTP or server access? =
Install VulnLine and activate it. WordPress cannot write a real file to `/.well-known/` by itself, so the plugin serves security.txt dynamically at that exact URL with the correct `text/plain` content type — no FTP, cPanel, file manager or `.htaccess` edits needed.

= What should a security.txt file contain? =
Two fields are required by RFC 9116: `Contact` (a `mailto:`, `https://` or `tel:` URI that a human actually reads) and `Expires` (a future date, ideally less than a year ahead). Optional fields are `Encryption` (your PGP key), `Policy` (your disclosure policy page), `Preferred-Languages`, `Acknowledgments`, `Hiring` and `Canonical`. VulnLine's settings screen covers all of them.

= Is security.txt required by law? =
No — RFC 9116 is a voluntary standard, not a law. That said, it is mandatory for Dutch government organisations, recommended by security agencies such as the UK NCSC, and the direction of regulation (for example the EU Cyber Resilience Act's coordinated-disclosure requirements) is toward every product and site having a published security contact. Having one costs nothing and takes a minute.

= What is the difference between security.txt and robots.txt? =
Different audiences. `robots.txt` tells search-engine crawlers which pages they may index. `security.txt` tells security researchers how to contact you about vulnerabilities. They live in different places, too: robots.txt sits in the root, security.txt belongs at `/.well-known/security.txt`.

= Do I need to configure anything? =
No. On activation VulnLine fills in ready-to-use defaults — your site admin email as the Contact, an Expires date one year ahead, and your site language — so the file is valid and live immediately. Change anything you like under Settings → VulnLine.

= Can I add security.txt without a plugin? =
Yes, if you have FTP or file-manager access: create a `.well-known` folder in your web root and upload a correctly formatted `security.txt` file. The plugin route is safer for most sites — it guarantees the `text/plain` content type, validates the format, survives migrations and theme changes, and reminds you before the Expires date lapses.

= Do I need this if I already have a contact page or a disclosure policy? =
Yes. Researchers check `/.well-known/security.txt` first — it is machine-readable and unambiguous, unlike a contact form buried three clicks deep. VulnLine also links your existing policy page in the `Policy` field, so the two work together.

= How do I know my security.txt is valid? =
Open `yoursite.com/.well-known/security.txt` — you should see plain text, not a 404 or a web page. VulnLine goes further: it validates every save against RFC 9116, shows a live status (valid / action needed) on its settings screen, and warns you in the dashboard if the file ever becomes invalid.

= What happens when the Expires date passes? =
Researchers treat the file as stale and may not trust or use the contact details. VulnLine shows a countdown on its settings screen and warns you in the dashboard if your file is missing or invalid — set a calendar reminder to renew the date yearly.

= Why is it called VulnLine? =
Because that is what it is: a direct line for vulnerability reports. When a researcher finds a bug, VulnLine makes sure they can reach you — through the standard security.txt file (RFC 9116) at /.well-known/security.txt.

= Will this work with caching plugins / Cloudflare? =
The file is served dynamically through WordPress. If you use aggressive full-page caching, exclude the `/.well-known/security.txt` path so updates appear immediately.

= Does it slow down my site? =
No. Nothing loads on the front end; the plugin only responds when `/.well-known/security.txt` itself is requested.

== Screenshots ==

1. The VulnLine settings screen — live status, expiry countdown, and a live preview of your security.txt exactly as researchers will see it.
2. Your security.txt served at /.well-known/security.txt with the correct plain-text format.
3. The live preview card with syntax highlighting and one-click copy — what you save is exactly what researchers get.
4. Built-in validation warns you the moment something is wrong — here, an Expires date in the past.
5. A dashboard reminder appears across wp-admin if your security.txt is missing or invalid, so it never silently rots.

== Changelog ==

= 1.1.3 =
* Renamed to VulnLine (new slug) with a full internal re-prefix: every function, class, constant, option and handle now uses the unique vulnline_ prefix. Settings saved under either previous name (Bugline, Security.txt Generator) migrate automatically — your published security.txt does not change.

= 1.1.2 =
* Easy setup: the plugin now configures itself on first run — Contact is filled with the site admin email, Expires is set one year ahead, and Preferred-Languages follows the site language, so the file is valid and live the moment you activate. Sites upgrading with an empty Contact get it filled once, automatically.

= 1.1.1 =
* Fix: sanitize the request URI used by the plain-permalink fallback (Plugin Check warning). No behaviour change.

= 1.1.0 =
* Renamed to Bugline (new slug) with a full internal re-prefix: every function, class, constant, option and handle now uses the unique bugline_ prefix. Existing settings migrate automatically — your published security.txt does not change.


= 1.0.4 =
* Hardening and robustness: ABSPATH guards on all class files, plain-permalink fallback for serving the file, trailing-slash tolerance, dead-code cleanup. No behavior change.

= 1.0.3 =
* Premium settings UI: branded top bar, gradient status hero with stat tiles, icon-headed cards, terminal-style syntax-highlighted preview, and polished form styling.

= 1.0.2 =
* Improved settings UI: status hero card (live/valid state with expiry countdown), grouped Required/Optional field cards, and a copy button on the live preview.

= 1.0.1 =
* Code quality: inline escaping on all admin outputs (resolves Plugin Check EscapeOutput notices) and Tested up to 7.1. No behavior change.

= 1.0.0 =
* Initial release: RFC 9116 security.txt generation, validation, live preview, and automatic serving at /.well-known/security.txt.

== Upgrade Notice ==

= 1.1.3 =
* Renamed to VulnLine. Your settings migrate automatically; your published security.txt does not change.
