Add a .well-known/security.txt file in xwiki.org

Development
,
1

Hello everyone,

I discovered today a new RFC (RFC 9116: A File Format to Aid in Security Vulnerability Disclosure) whose goal is to help properly reporting security issues: basically this RFC defines a format of a security.txt file that can be automatically parsed to give information about to whom to report a vulnerability and what is the policy regarding vulnerabilities.

I think it might be a good idea to put such file on xwiki.org, so I propose that we add a file containing the following content:

# Our security address
Contact: mailto:security@xwiki.org

# Our security policy
Policy: https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/

Expires: [1 year after publication]

About expiration date: the RFC strongly advise to put one, I propose that we modify the upgrade plan of XWiki.org to include checking the security.txt and updating the date when we do perform an upgrade.

The RFC also advises to sign this security.txt, I’m not sure if we already a public PGP key that we could use: if we have I guess we should use it.

WDYT?

2

Out of curiosity, do you know what’s the current adoption of this RFC? I’m mainly thinking of external tool that are indexing/scrapping security.txt files and doing something with them?

3

I don’t know but it says This document is not an Internet Standards Track specification; it is published for informational purposes..

4

We have one we are using to sign Debian repositories.

5

I haven’t looked but it’s really a young RFC so I don’t expect much adoption yet, it says:

Published: April 2022

6

I think it cannot hurt :wink:

One thing that we could improve too is to add a section in our release notes or on the hall of fame page on dev.xwiki.org, about thanking security reporters. And then put a link to it in the security.txt file. Now we’ll need a process if we were to do that or we will forget. Also it raises the question of why recognizing security reporters vs bug reporters… I don’t have the answer, just raising the topic :wink:

Note that the RFC says to put this file under https://xwiki.org/.well-known/security.txt.

Each committer has its own key ATM.

7

Thanks. I’m hesitant to do more paperwork for something that will not be useful to others in the end.
Then, if we derive this file from structured data (e.g., XObjects), then a least they can be reused for some other format later (or to continue/improve what we started during last hackathon).

8

Hi devs,

I’d like to revive this proposal: we all agreed back in 2022 but never did it, and https://www.xwiki.org/.well-known/security.txt still returns a 404. I asked Claude Code to check the current state and what a good file would look like. Here’s the result.

It’s become fairly common since then. Claude Code checked 49 well-known open source projects today: 27 publish one, e.g. Apache, Jenkins, Spring, Eclipse, Keycloak, Kubernetes, Mozilla, Debian, Django, Node.js, Rust, curl, OpenSSL, WordPress, Joomla, TYPO3, GitLab, MediaWiki, BookStack and OpenProject (https://www.openproject.org/.well-known/security.txt). Python, Go, PostgreSQL, Nextcloud, Grafana, Mastodon and DokuWiki don’t. GitHub, Atlassian and Red Hat have one too. About a third of them are signed.

One lesson from the survey: Matrix’s and Element’s files have expired (2024 and 2025), and a few have no Expires at all, which the RFC requires. So the yearly renewal is the part to not forget.

Proposed content

Contact: mailto:security@xwiki.org
Policy: https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/
Canonical: https://www.xwiki.org/.well-known/security.txt
Preferred-Languages: en
Expires: <less than 1 year ahead>

If we enable GitHub private vulnerability reporting (see the GHSA brainstorming), we’d add a second Contact: with the “Report a vulnerability” URL.

Signing and encryption key

  • Signing the file (OpenPGP cleartext signature) is recommended by the RFC, not required. Claude Code proposes to use the key we already use for the Debian repository, which the committers hold: XWiki Dev Team <committers@xwiki.org>, fingerprint E5A2 98A7 AF53 948C C6CF D633 F716 794B 93CC 9C13 (also published on keys.openpgp.org). The file must be re-signed each time Expires is bumped, which any committer can do.
  • Encryption: is a different field: it names the key reporters encrypt their report to. Claude Code proposes to leave it out: the Debian key is for committers@, not security@, and encrypted mail to a mailing list only works if every member shares the private key. GitHub private reporting gives a confidential channel anyway.

Keeping it valid

As suggested in the first post, we’d add a step to the xwiki.org upgrade plan to bump Expires and re-sign the file.

Questions

  • OK to add the file with the content above?
  • OK to sign it with the Debian repository key?

WDYT?

Thanks

9

+1

Thanks,
Marius

10

I’m wondering if we should keep 1 year. I don’t expect that content to change anytime soon, and it’s only a recommendation from the RFC to be less than 1 year:

It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness.

So we could decide to use a longer expiration date? On the other hand my original proposal was to:

We could keep 1 year, and have the check to ensure to renew / resign if the expiration is < 3 months.

11

+1