Add admintoolkit.io security.txt validator

[GitHoubi]

Adds the admintoolkit.io security.txt Validator/Generator to the Projects table.

The hosted tool validates pasted content or a public security.txt URL and generates RFC 9116 drafts.

The existing Activity snapshot annotation (as of Aug 1, 2025) remains unchanged. The new row records its own live check date (Jul 20, 2026).

[oh2fih]

As a side note, I noticed a few areas for improvement in the validator:

• The error/securitytxt_encryption_invalid_uri check only accepts mailto: and https: URIs. However, RFC 9116, 2.5.4 demonstrates the use of dns: and openpgp4fpr: URIs in the Encryption field, so these should also be accepted. Additionally, mailto: does not seem to make sense in the context of the Encryption field.
• The warning/securitytxt_duplicate_field check reports duplicate Canonical fields, even though RFC 9116, 2.5.2 explicitly allows this field to appear multiple times. Here, "canonical" does not refer to a single canonical URL in the usual sense. It's common to sign a single security.txt file for multiple domains, and repeating the Canonical field is the only way to make it match each domain.
• It could also be useful to add a warning if the date in the Expires field is more than one year ahead, as RFC 9116, 2.5.5 recommends that the value be less than one year into the future.
• More generally, it would be helpful if errors and warnings included line number references.

[GitHoubi]

As a side note, I noticed a few areas for improvement in the validator:

* The `error/securitytxt_encryption_invalid_uri` check only accepts `mailto:` and `https:` URIs. However, [RFC 9116, 2.5.4](https://www.rfc-editor.org/info/rfc9116/#section-2.5.4) demonstrates the use of `dns:` and `openpgp4fpr:` URIs in the `Encryption` field, so these should also be accepted. Additionally, `mailto:` does not seem to make sense in the context of the `Encryption` field.

* The `warning/securitytxt_duplicate_field` check reports duplicate `Canonical` fields, even though [RFC 9116, 2.5.2](https://www.rfc-editor.org/info/rfc9116/#section-2.5.2) explicitly allows this field to appear multiple times. Here, "canonical" does not refer to a single canonical URL in the usual sense. It's common to sign a single `security.txt` file for multiple domains, and repeating the `Canonical` field is the only way to make it match each domain.

* It could also be useful to add a warning if the date in the `Expires` field is more than one year ahead, as [RFC 9116, 2.5.5](https://www.rfc-editor.org/info/rfc9116/#section-2.5.5) recommends that the value be less than one year into the future.

* More generally, it would be helpful if errors and warnings included line number references.

Hi @oh2fih

Thanks a lot for your suggestions. Will check and implement untill tonight.

Many thanks,
GitHoubi

[GitHoubi]

Dear @oh2fih

Thanks for the detailed validator feedback. All four items are now implemented and live:

• Encryption accepts https:, dns:, and openpgp4fpr:; mailto: is rejected.
• Multiple Canonical fields are accepted and do not trigger securitytxt_duplicate_field. If an expected URL is known, any matching Canonical value satisfies the check.
• Expires values one calendar year or more into the future trigger warning/securitytxt_expires_too_far.
• Findings tied to source input include Line N / Zeile N; findings for missing fields intentionally have no fabricated line number.

Regression tests cover each case, including the one-year boundary and leap-day behavior.

Best,
GitHoubi