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

security.txt does not conform with the current format #444

Open
werthen opened this issue Mar 16, 2021 · 1 comment
Open

security.txt does not conform with the current format #444

werthen opened this issue Mar 16, 2021 · 1 comment
Labels
level: easy Small/easy issue fixable in an evening

Comments

@werthen
Copy link
Member

werthen commented Mar 16, 2021

A required field is the "expires" field, which is currently not present. Description as follows, as found on https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.5:

   This field indicates the date and time after which the data contained
   in the "security.txt" file is considered stale and should not be used
   (as per Section 6.3).  The value of this field follows the format
   defined in section 3.3 of [RFC5322].  It is RECOMMENDED that the
   value of this field be less than a year into the future to avoid
   staleness.

   This field MUST always be present and MUST NOT appear more than once.

   Expires: Thu, 31 Dec 2021 18:37:07 -0800

Also see https://securitytxt.org/

@redfast00
Copy link
Member

redfast00 commented Mar 16, 2021

A good Expires date might be when the board is expected to change. This can then be put in the handover document; and gives the new board an opportunity to re-evaluate the responsible disclosure policy.

The reason why there was no Expires date yet, was that at the time we wrote it, the RFC draft did not yet include it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
level: easy Small/easy issue fixable in an evening
Projects
Status: No status
Development

No branches or pull requests

4 participants