.well-known: import a tentative security.txt

[khorben_defora.org]

Summary

The information was gathered by myself, to the best of my knowledge, according to the public information available.

This was obtained with help from the official generator at https://securitytxt.org/.

Sponsored by: The FreeBSD Foundation

Test Plan

Browse to https://www.freebsd.org/.well-known/security.txt.

[carlavilla]

For me it's ok everything except the FreeBSD Foundations links.
This is for the FreeBSD website, not for the FreeBSD Foundation website

[khorben_defora.org]

Removed the (optional) links for "any security-related job openings in your organisation."

[ziaee]

I really like this concept.
Why are there two policy lines?

[ziaee]

website/static/.well-known/security.txt

9

Maybe? The example in the RFC includes the spec, and I think that's nice.

[khorben_defora.org]

website/static/.well-known/security.txt

9

Are you sure? According to https://www.rfc-editor.org/rfc/rfc9116#name-file-format-description-and it does not.
I think the examples you refer to are not related to the security.txt file itself, but to IANA's registry for the fields allowed in the file.

[khorben_defora.org]

In D47933#1092988, @concussious.bugzilla_runbox.com wrote:

I really like this concept.
Why are there two policy lines?

The "Policy" field is part of the fields with "optional repeated instances," allowing multiple alternatives to be specified.

[khorben_defora.org]

Add descriptions of the fields used, as per the example from securitytxt.org.

[khorben_defora.org]

Also note that the contents of this file can be signed with an OpenPGP clear-text signature by the security team, in order to clearly authenticate it as legitimate.

[ziaee]

Oops! You're right. I don't think the field descriptions help it though, the fields are very self explanatory but the comments adds bikeshedable language? This is really an architectural decision for secteam, will certainly result in increased spam, but maybe helpful. So, I'll bow out now.

[khorben_defora.org]

In D47933#1093012, @concussious.bugzilla_runbox.com wrote:

Oops! You're right. I don't think the field descriptions help it though, the fields are very self explanatory but the comments adds bikeshedable language? This is really an architectural decision for secteam, will certainly result in increased spam, but maybe helpful. So, I'll bow out now.

I was thinking about spam too, however I saw that https://www.freebsd.org/administration/#t-secteam has a whole list of e-mail addresses ready for the taking, so I suppose (or really hope) that every address on this page already has a solid spam filter.

It is true that having the security file makes it easier to locate this specific set of valid e-mail aliases.

On a related note, I wonder if I should add the aliases and policies relevant to security reports affecting the ports tree to the security.txt file.
Thoughts?