Add security.txt file

[daniel-beck]

See https://securitytxt.org/

The expiration date is mandatory and a bit annoying. Options:

• Currently implemented: Yearly expiration date we need to keep updating.
• Date far in the future so we don't need to care at the risk of keeping obsolete data "in caches"
• Automatically generate this field on site generation to be a few months into the future. Might be annoying given the workaround we're already applying to make .well-known/ work.

Thoughts?

[dduportal]

Make a lot of sense, thanks Daniel!

I got 2 questions (non blocking):

• About the date renewal, WDYT about a process that would open a PR with a new date once or twice a year (or more frequently?). That would act as an automatic and no-brainer reminder to ask ourselves "are these informations still up to date" ?
• Do you feel we should apply the same security.txt to other websites (such as updates.jenkins.io, get.jenkins.io, etc.)?

[MarkEWaite]

I like it. I don't mind updating the expiration date once a year with a pull request created by a human being. It shows that someone considered if the referenced pages are current and complete.

What if we extended the Jenkinsfile with a script that marks the build unstable when we are within a month of expiration? It currently checks for typos as one of the stages on ci.jenkins.io.

[dduportal]

with a pull request created by a human being

I though an automated PR (e.g. with updatecli or renovabot or even cron trigger) which does all the trick (to ensure that the date format is kept: I do not trust humans for date formats), but requires a human approval.