Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add security.txt file #5359

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

daniel-beck
Copy link
Contributor

@daniel-beck daniel-beck commented Aug 10, 2022

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.

@StackScribe
Copy link
Contributor

This looks something we might be able to finish off and merge.

Copy link
Contributor

@Wadeck Wadeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the initiative


Expires: 2026-01-01T00:00:00.000Z
Canonical: https://www.jenkins.io/.well-known/security.txt
Policy: https://www.jenkins.io/security/reporting/
Copy link
Contributor

@Wadeck Wadeck Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Policy: https://www.jenkins.io/security/reporting/
Policy: https://www.jenkins.io/security/reporting/
Policy: https://github.com/jenkinsci/docker/blob/master/SECURITY.md

adding the policy specific to CVEs reporting

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actual link is

Suggested change
Policy: https://www.jenkins.io/security/reporting/
Policy: https://www.jenkins.io/security/reporting/
Policy: https://github.com/jenkinsci/docker/security/policy

@gounthar
Copy link
Contributor

gounthar commented Dec 4, 2024

Just as a precaution, I have an updatecli manifest designed to keep the expiration date current. As we approach the final month before expiration, it will automatically create a PR to extend the date by one year into the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants