Legacy Build Toolchain - Contact Info Parser

[toderash]

Note: This may be combined with or used by #30

Parse

• Publisher contact
• Support channel
• Security contact & VDP
  • Check supplied meta & available APIs, e.g., https://patchstack.com/database/api/v2/vdp/elementor
  • Check for security.txt file in website's root or .well-known/ directories
  • Check for security.txt file in package's root directory
  • Create security.md file if missing
• If there is a single contributor to the package, they become the security contact
  • Else if the publisher is an organization that we can parse a contact from use that
  • Else the security contact is wordpress.org
• Append contact info to package-meta & build-meta per spec

[chuckadams]

That patchstack url seems to require an api key. If there's useful data from it or other third-party services, I suggest giving them their own scope and limiting this just to supplied metadata files.

I don't recommend supporting too many different metadata locations, since that's how you end up with multiple copies that are out of sync. For this particular file, given how it ought to have equal booking with a README, looking for it in the root is probably a good idea, but for others I suggest something like a .fair directory in the root. .well-known is for websites, and perhaps ironically, not used much in code projects.

[namithj]

Should we be creating files in the packages, it will be opening a can of worms. Ideally we should ask the author to do it and if that's not possible, don't do anything.

[namithj]

This can be done by cloning the security header checker and updating regex.